Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 May 2012 14:53:48 +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:  <20120517125348.GA26081@dft-labs.eu>
In-Reply-To: <20120516233744.1314398bowqaykuw@webmail.teithe.gr>
References:  <20120516003020.82068pr8h9dyqjfw@webmail.teithe.gr> <20120516140033.GB2470@dft-labs.eu> <20120516233744.1314398bowqaykuw@webmail.teithe.gr>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 16, 2012 at 11:37:44PM +0300, tzabal@it.teithe.gr wrote:
> 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.

Maybe this is a gross misunderstanting on my side, but I'm pretty sure
that:

DDB supports simple form of scripting that allows series of commands to
be run on certain events, e.g. kernel panic. Output can be captured
("capture on").

textdump is a part of DDB that saves aforementioned output.

In other words, there are no textdumps without DDB and there is no
problem with running DDB commands automatically after panic. Also it
looks like you will have to actually add DDB to GENERIC in order to obtain
textdumps in default installations.

> 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?
> 

curl would be ok, except it's not in the base system.

Actually I just now checked for tools in base that support HTTP POST and
couldn't find any. Should've checked before proposing such solution,
sorry.

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

-- 
Mateusz Guzik <mjguzik gmail.com>



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