Defunct process

Brandon S. Allbery allbery at NCoast.ORG
Mon Mar 12 09:48:11 AEST 1990


As quoted from <6840005 at hpcllcm.HP.COM> by pratap at hpcllcm.HP.COM (Pratap Subrahmanyam):
+---------------
| When a child dies it send a signal to its parent (I think it's called a 
| "death_of_child_signal"). When the parent recieves this signal, it resets the
| process PID table, after doing several other cleanup operations (like closing
| opne files, pipes etc.. ). Now the PID table, will not contain an entry for 
| the child process. (This is why ps -ef will not show it).
+---------------

The parent process does not do this; the kernel does.

+---------------
| However, if there is a race condition, like this .. The child dies soon after
| the parent is "killed", that is the child dies before it can be reparented.
+---------------

It will still be reparented, to 1 (init).  I don't believe the race condition
you describe exists.

In any case, this does not explain <defunct>; those processes are trapped in
process tear-down because an open file (usually a device, sometimes a socket
in buggy TCP/IP implementations) can't be closed.  It usually indicates a
buggy device driver.

And SIGCLD/SIGCHLD (depending on religious affiliation ;-) is not the trigger
for process cleanup; it's part of that cleanup.  The kernel sends it, on
behalf of the process, to its parent.  In System V, it is sent *only if the
parent is expecting to receive it*; I suspect BSD is similar, since most
processes could care less about child-death signals whatever the system.

+---------------
| If any one has better (or if this is a bogus ) answers, please post. I'll
| be interested.
+---------------

Done.  Although I expect Chris Torek will have some words to say on the
subject as well.  ;-)

++Brandon
-- 
Brandon S. Allbery (human), allbery at NCoast.ORG (Inet), BALLBERY (MCI Mail)
ALLBERY (Delphi), uunet!cwjcc.cwru.edu!ncoast!allbery (UUCP), B.ALLBERY (GEnie)
BrandonA (A-Online) ("...and a partridge in a pear tree!" ;-)



More information about the Comp.unix.wizards mailing list