[lkml]   [2009]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] exec: Make do_coredump more robust and safer when using pipes in core_pattern
On Sat, Aug 01, 2009 at 07:28:52PM +0100, Scott James Remnant wrote:
> On Sat, 2009-08-01 at 09:41 -0400, Neil Horman wrote:
> > > > Not without additional work. If init crashed in the initramfs, I don't think
> > > > theres a way to handle that. If it crashes at some later time, I think it just
> > > > gets restarted IIRC. I'm sure you can change that behavior, but this patch
> > > > doesn't address that.
> > > >
> > > When the system init daemon crashes, the kernel PANICs. When not using
> > > core_pattern, this is ok, we get a core file - when using apport, as far
> > > as I can tell it never waits for apport to finish so we don't get the
> > > crash.
> > >
> > This is non-sensical. If init crashes, and the kernel panics, you'll only get a
> > core by sheer luck and good fortune.
> >
> Or by being a bit clever. Upstart catches the SIGSEGV and the signal
> handler forks a child process, unmasking the signal in that child
> process with no signal handler installed.
I don't see how this works. How is upstart (which by definition is a child of
init (pid 1)) going to catch a SIGSEGV from its parent? How would any process
catch a signal targeted to its parent?

> So it's really a child of init that core dumps, just ignore the signal
> handler off the top of the stack trace and it's just as good as a core
> dump from the init daemon itself.
Ok, setting asside that I don't see how you can do what your describing above,
if you're forking a crashing process so that it crashes in exactly the same way,
that makes a bit of sense.

> Meanwhile the real init daemon (pid 1) wait()s on its child, and then
> once it's reaped it exits itself - and then the kernel PANICs.
> This works just fine with ordinary core files, because the kernel does
> at least write out the core file beforehand. With apport we don't get
> this wait, thus I was hoping your patch would have that effect.
Well, again setting asside that I don't see how you're doing what you say above,
my patch does what you're hoping it does. It can be configured to wait on the
crashing processes until its the pipe reader is exited.


> Scott
> --
> Scott James Remnant

 \ /
  Last update: 2009-08-02 02:25    [W:0.106 / U:0.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site