[Sheepdog] [PATCH] logger: correct crash_handler output

[Christoph Hellwig]

On Sat, Apr 28, 2012 at 10:12:46AM -0700, Shevek wrote:
> On Sat, 2012-04-28 at 21:59 +0800, Liu Yuan wrote:
> > On 04/28/2012 09:54 PM, Christoph Hellwig wrote:
> > 
> > > We'd still like to print the pid of the died sheep pid - getppid()
> > > should do that work for that.
> > 
> > 
> > Yes, I tried use getppid() initially, but I found that getppid() always
> > return 1 in my distro (ubuntu) and I didn't try to trace why. So I
> > simply remove pid, given that some bug in other place or my dirstro goes
> > ill-configured.
> > 
> > Maybe I'd better call getppid() here and wait fixes from other place.
> 
> The reason getppid() returns 1 is that it was called in the sheep, and
> the parent is (correctly) init. If log_sigexit() is called in the sheep,
> you need getpid().

It wasn't, pleease read up on the semantics of fork().

The reason why it returns 1 is way more subtile, and hidden in Linux
specific extentions to the alredy subtile Unix process family tree.

prctl PR_SET_PDEATHSIG makes the kernel send a death signal _after_ the
parent die to the child.  Given that the parent has already died at this
point the child has been reparented to pid 1 which acts as a repear for
child processes of dead parents.  So getppid() returns 1 correct in this
case.

> Since it is possible for any signal, especially SEGV, to be delivered
> either to the sheep or the logger, we need a flag to tell the method
> which process received the signal.

Only the logger actually sets up signal handlers, so only signals
delivered to it will be handled in crash_handler.  The only real
problem is that a SIGUP that does not originated from the
PR_SET_PDEATHSIG machinery could be sent to the logger, in which case
the log output is incorrect, and the logger would die without taking the
sheep down.