Messages in this thread | | | Date | Tue, 24 Nov 1998 08:35:51 GMT | From | Nick Holloway <> | Subject | Re: Possible bug in wait4(), 2.1.126-129 ? |
| |
> The real point is that what we see should never ever happen, regardless of > libc, cron or pretty much anything the userspace can do. Only the current > direct parent of a zombie can "wait" for it. Yet, in my test case the > zombie effectively disappears without the parent waiting for it and before > the parent itself finished. I checked that this is indeed the case by > inserting a longer sleep() in the parent, and then checking the process > table -- the child is gone for good! Needless to say, this completely > breaks UNIX process semantics...
Ping! Penny drops...
There is one condition that this can happen. If a process has set the SIGCHLD handler to SIG_IGN, then the kernel will perform the wait on the parent processes behalf (see arch/i386/kernel/signal.c:654). This is a quick way to avoid zombies without the pain of calling wait.
In addition, signal masks are inherited across exec, so the cron process is run with the signal mask from cron.
So, it is a bug in cron that it isn't reverting the default handler for SIGCHLD before forking the cron job. It may be that the different behaviour seen depends on the shell used -- it is possible that bash as /bin/sh resets SIGCHLD.
Anyway, you can see the same behaviour from the command line if you insert a "signal(SIGCHLD,SIG_IGN);" at the start of the C program. Similarly, inserting "signal(SIGCHLD,SIG_DFL);" should fix it.
Anyway, it doesn't look like a kernel problem to me.
-- `O O' | Home: Nick.Holloway@alfie.demon.co.uk http://www.alfie.demon.co.uk/ // ^ \\ | Work: Nick.Holloway@parallax.co.uk
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |