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

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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).

> * Can you recommend a secure way of sending a report from a FreeBSD
> system to the Central Collector machine?
> 

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

> * Which data do you want kcrashreporter to collect? At the moment I
> have considered the panic message, the backtrace, the version level
> of the release, the hardware platform (uname -vm) and the
> configuration file of the panicked kernel (config -x `sysctl -n
> kern.bootfile`).
> 

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.

> * Do you propose a different Web Server than the Apache HTTP Server?
> For example, on my initial planning I had included MySQL as the
> selected DBMS and after some discussions I changed to PostgreSQL.
> 

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.

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.

-- 
Mateusz Guzik <mjguzik gmail.com>



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