prog@usceast.UUCP (System Programmer) (04/10/84)
<take that> Is there any way to get rid of processes on 4.2bsd that say (endlessly) "<exiting>" ? We run 4.2 on an 11/780 and we can't find any way to do it short of bringing down the system. Usually it's just a bother, but sometimes they seem to keep a getty from restarting at a terminal. Any suggestions will be appreciated -- -------------------------------------------------------------------------------- Ted Nolan usceast!ted 6536 Brookside Circle Columbia, SC 29206 (feather the rast!) --------------------------------------------------------------------------------
faustus@ucbvax.UUCP (Wayne Christopher) (04/11/84)
<exiting> processes are those that have already died or been killed, so you can't kill them again. They are waiting for init to wait for them so they can give it their resource usages, etc. It init isn't doing this then maybe there is a problem somewhere in your system... Wayne
tjt@kobold.UUCP (04/12/84)
Wayne Faustus (ucbvax!faustus) says:
<exiting> processes are those that have already died or been
killed, so you can't kill them again. They are waiting for init
to wait for them so they can give it their resource usages, etc.
It init isn't doing this then maybe there is a problem somewhere
in your system...
This is not quite true. <exiting> processes are waiting for their
parent to wait for them. However, if the original parent has exited,
process 1 (init) "adopts" the <exiting> process.
--
Tom Teixeira, Massachusetts Computer Corporation. Westford MA
...!{ihnp4,harpo,decvax}!masscomp!tjt (617) 692-6200 x275dave@uwvax.ARPA (04/12/84)
Remember, <exiting> processes are in the zombie state -- they died, but their
parent has decided to ignore them (if an <exiting> process's parent is
process 1, you have a problem). I see these all the time. The culprit?
comsat (that thing that tells you have mail when you do 'biff y'). I do
wish comsat would let its children die. If the hanging processes are not
comsat's children, you may have to look at messed up hardware (most commonly
tty stuff -- disk problems can also leave <exiting> processes around).
Dave Cohrs @ wisconsin
--
Dave Cohrs
...!{allegra,heurikon,ihnp4,seismo,uwm-evax}!dave
dave@wisc-rsch.arpajsq@ut-sally.UUCP (John Quarterman) (04/12/84)
If the zombies are comsat's children, killing comsat should cause
them to be adopted by init, which will clean them up.
--
John Quarterman, CS Dept., University of Texas, Austin, Texas
jsq@ut-sally.ARPA, jsq@ut-sally.UUCP, {ihnp4,seismo,ctvax}!ut-sally!jsqguy@rlgvax.UUCP (Guy Harris) (04/16/84)
The children of "comsat" seem to go away eventually; I suspect "comsat"
may periodically do a "wait" to pick up its children, but spends most of
its time waiting for a mail notification to come in on the MPX file (4.1)
or socket (4.2). (Unfortunately, the ability to have a descriptor which
refers to one's children wasn't implemented in 4.2; if it had been, one
could select() for either the socket or the child descriptor.)
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy