Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 May 2012 23:37:44 +0300
From:      tzabal@it.teithe.gr
To:        Mateusz Guzik <mjguzik@gmail.com>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: GSoC Project: Automated Kernel Crash Reporting System - Discussion
Message-ID:  <20120516233744.1314398bowqaykuw@webmail.teithe.gr>
In-Reply-To: <20120516140033.GB2470@dft-labs.eu>
References:  <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> <20120516140033.GB2470@dft-labs.eu>

next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Mateusz Guzik <mjguzik@gmail.com>:

> On Wed, May 16, 2012 at 12:30:20AM +0300, tzabal@it.teithe.gr wrote:
>> Hello Community,
>>
>> I have the project "Automated Kernel Crash Reporting System" for
>> this GSoC and I would like to discuss my plans about it before
>> starting the coding on May 21.
>>
>
> Cogratulations. :)
>
>> I have created a page in the FreeBSD Wiki  
>> (http://wiki.freebsd.org/SummerOfCode2012/AutomatedKernelCrashReportingSystem)
>> where I describe in details the architecture of the system.
>>
>> Here are some points that I would like to be discussed:
>>
>> * The implementation of the kcrashreporter is planned to be done in
>> two shell scripts. The first shell script is a rc.d script and the
>> second is the actual program. I choose to code it in shell because
>> kcrashreporter invokes the kgdb to collect the necessary debugging
>> information. I think that using the shell instead of traditional
>> programming language for this kind of job is more straightforward
>> and natural. Do you have a different opinion?
>>
>
> Are you going to support textdumps?
>
> I would like to note that some machines have swap space only for
> textdumps, so I think you should support these.

Support for textdumps is already on the list.

> ddb is equiped with a lot of cool commands that show various important
> debugging information(e.g. show alllocks). AFAIK kgdb doesn't have such
> facilities so you will have to implement those first if you decide to
> use it (btw I think these would be useful even without this project).
> Take a look at tools/debugscripts.
> That being said, I would give a priority to support for textdumps (and
> in case kgdb support cannot be finished in time, I would make sure that
> the project is expendable enough to support information obtained from
> kgdb and possibly other sources).

Indeed, DDB is equipped with features that kgdb does not provide but  
only kgdb has access to the full debug information whenever we want  
because of its operation on the core dump. As far as I understand, if  
we want to use DDB to collect the debugging information, we have to do  
it *immediately* after the kernel panic and before the first reboot.  
Also consider that DDB is not included in the generic FreeBSD kernel  
of -STABLE and -RELEASE. You have to compile a custom kernel with the  
options KDB and DDB. I think that the nature of DDB as an on-line  
debugger is a restriction mainly for the manual behavior of  
kcrashreporter.
I do not think that I could update the kgdb with the features that DDB  
provides, but if it is mandatory to collect these information and kgdb  
cannot, I will do my best.

> I don't know if these are good ideas (no clue about cryptography), but I
> would either:
> - HTTP POST data over SSL
> or
> - HTTP POST data encrypted with some public key

Nice. What about curl over the HTTPS protocol?


> hardware information, dmesg, locks, locked vnodes, mount points, ps,
> backtraces of all threads
>
> Basically if ddb can show something easly enough (or you will be able to
> make it do so), the report should contain it.

First I will try to search if and how we can obtain these information  
using kgdb.


> I guess this site won't be very busy, so whatever popular httpd you will
> choose it should be fine (although I would stick with either apache or
> nginx). No clue about databases.

One more vote for nginx.

> Also it would be nice to have a way to contact the owner of machine that
> submitted the report. One way I can think of is the ability to specify
> e-mail address (say in rc.conf?) that will be included in the report.

This is a feature that is included from the initial planning and with  
the way that you proposed :)


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120516233744.1314398bowqaykuw>