rjd@occrsh.ATT.COM (05/03/88)
::You ask about processes that refuse to die. (Calling them "immortal" ::confers a positive aura that is probably undeserved. Normally these ::processes are in a useless state, and might better be referred to as ::members of the "undead".) I think these are normally called "zombie" processes, are they not? Randy
rbj@icst-cmr.arpa (Root Boy Jim) (05/05/88)
From: rjd@occrsh.att.com
::You ask about processes that refuse to die. (Calling them "immortal"
::confers a positive aura that is probably undeserved. Normally these
::processes are in a useless state, and might better be referred to as
::members of the "undead".)
I think these are normally called "zombie" processes, are they not?
Technically, no. Zombies are already dead. These processes are on death row,
and will die when (if ever) they return from their uninterruptible sleep.
Killing a zombie has no effect, so they behave much the same way.
I believe that killing a process merely sets a bit in its signal mask, which
is not looked at until the affected process is rescheduled. Of course, if
the target process has higher priority and is otherwise ready to run, it
should preempt the killing process, no?
Randy
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688
The opinions expressed are solely my own
and do not reflect NBS policy or agreement
.. I don't know why but, suddenly, I want to discuss declining I.Q.
LEVELS with a blue ribbon SENATE SUB-COMMITTEE!bob@cloud9.UUCP (Bob Toxen) (05/06/88)
In article <13282@brl-adm.ARPA>, rbj@icst-cmr.arpa (Root Boy Jim) writes: > Technically, no. Zombies are already dead. > Killing a zombie has no effect... Correct. Zombies merely hold the PID until their parents do a wait() for them or until their respective parents die causing them to be inherited by init() (PID 1). They need to wait for the wait() so that the exit() status can be returned to the parent's wait(). > I believe that killing a process merely sets a bit in its signal mask, which > is not looked at until the affected process is rescheduled. Of course, if > the target process has higher priority and is otherwise ready to run, it > should preempt the killing process, no? Correct. Thus sending multiple signals to a process hung in a system call or otherwise not getting cycles doesn't do anything. > (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> > National Bureau of Standards -- Bob Toxen {ucbvax!ihnp4,harvard,cloud9!es}!anvil!cavu!bob Stratus Computer, Marlboro, MA Pilot to Copilot: What's a mountain goat doing way up here in a cloud bank?