Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.wizards
Subject: Re: Defunct process
Message-ID: <1990Mar10.161752.4700@virtech.uucp>
Date: 10 Mar 90 16:17:52 GMT
References: <1805@cygnet.UUCP> <6840005@hpcllcm.HP.COM>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 31

In article <6840005@hpcllcm.HP.COM> pratap@hpcllcm.HP.COM (Pratap Subrahmanyam) writes:
   [long story deleted]
>In any case, in this situation, the PID table, doesn't get updated. That is
>why you see <defunct> processes with ps -ef.

No.  <defunct> processes are simply processes that have died, but have not
yet been waited on by thier parent.  These processes have an entry in the
process table, but no associated data space,etc.  BTW- The reason that they
stay around in the process table is so that the process exit status, and other
such information can be reported to the parent.

Since the process do not really exist, there is no way to deliver a signal 
to them and therefore killing such a process has no effect.

The other "unkillable" processes, those that are stuck somewhere in the
kernel (usually,if not always, in device driver code) sleeping with a 
priority < PZERO, are usually stuck there due to some hardware problem,
or a device driver bug. 

/* Disclaimer - this next part may be me smoking some rope, I can't create
		the problem to test it */
 
I believe that once stuck there they may get changed to a <defunct> by
sending a kill -9. However, they still will not go away until the
condition that got them stuck is cleared.


-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170