Quoting Mateusz Guzik <mjgu...@gmail.com>:
On Wed, May 16, 2012 at 12:30:20AM +0300, tza...@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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
