Re: [PATCH] [3/3] Support piping into commands in/proc/sys/kernel/core_pattern

From: Andi Kleen
Date: Wed Aug 16 2006 - 05:15:35 EST


On Wed, 16 Aug 2006 01:43:54 -0700
Greg KH <greg@xxxxxxxxx> wrote:

> On Mon, Aug 14, 2006 at 01:27:32PM +0200, Andi Kleen wrote:
> >
> > Using the infrastructure created in previous patches implement support
> > to pipe core dumps into programs.
> >
> > This is done by overloading the existing core_pattern sysctl
> > with a new syntax:
> >
> > |program
>
> Very nice, do you happen to have a program that can accept this kind of
> input for crash dumps? I'm guessing that the embedded people will
> really want this functionality.

I had a cheesy demo/prototype. Basically it wrote the dump to a file again,
ran gdb on it to get a backtrace and wrote the summary to a shared directory.
Then there was a simple CGI script to generate a "top 10" crashes
HTML listing.

Unfortunately this still had the disadvantage to needing full disk space
for a dump except for deleting it afterwards (in fact it was worse because
over the pipe holes didn't work so if you have a holey address map it would
require more space).

Fortunately gdb seems to be happy to handle /proc/pid/fd/xxx input pipes
as cores (at least it worked with zsh's =(cat core) syntax), so it would be
likely possible to do it without temporary space with a simple wrapper that
calls it in the right way. I ran out of time before doing that though.

The demo prototype scripts weren't very good. If there is really interest
I can dig them out (they are currently on a laptop disk on the desk
with the laptop itself being in service), but I would recommend to
rewrite them for any serious application of this and fix the disk space problem.

Also to be really useful it should probably find a way to automatically
fetch the debuginfos (I cheated and just installed them in advance)

If nobody else does it I can probably do the rewrite myself again at some point.

My hope at some point was that desktops would support it in their
builtin crash reporters, but at least the KDE people I talked
too seemed to be happy with their user space only solution.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/