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