Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!apple!motcsd!hpda!hpcuhb!hpcllla!hpcllcm!pratap
From: pratap@hpcllcm.HP.COM (Pratap Subrahmanyam)
Newsgroups: comp.unix.wizards
Subject: Re: Defunct process
Message-ID: <6840005@hpcllcm.HP.COM>
Date: 9 Mar 90 17:14:28 GMT
References: <1805@cygnet.UUCP>
Organization: Hewlett Packard Calif. Language Lab
Lines: 31




Here's my 2 cents worth on this topic. When an process that has a lot of 
children (like a shell) dies for some reason (like due a kill signal), the
OS takes it upon itself to walk down the list of children and reparent them
to the root process ( or the init process ). This works fine in most cases.

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

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.
Then the signal that the child sends out, will be lost in space. No process 
exists to recieve it. Hence it will be there, an orphan. I don't believe that
such orphan processes cause a overhead, because evan the OS will not know of
their existance. This means that the process never gets scheduled again, etc.
I'm not sure what happens to that space allocated to the process image.

In any case, in this situation, the PID table, doesn't get updated. That is
why you see <defunct> processes with ps -ef.


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

- Pratap
  pratap@hpcllcm.hp.hplabs.com.