Deron Meranda wrote:
On Mon, 21 Feb 2005 11:21:36 -0600, William WilsonThank you, gentlemen, for pursuing this thread. It has been both interesting and informative.
<williamwilson@xxxxxxxxxx> wrote:
Zombie processes are spawned by a parent process that terminates before
receiving the childs signal that they have completed. The Zombie is
waiting on acknowledgement from the parent process, thus they run
forever, or until the next reboot or someone kills them.
This is absolutely incorrect. I suggest you read any of Steven's UNIX programming books.
"...[the child] terminates first, when it calls exit .... It then becomes a zombie: a process that has terminated, but whose parent is still running but has not yet waited for the child."
You might also want to read this from the Unix FAQ: http://www.faqs.org/faqs/unix-faq/faq/part3/section-13.html
What you are talking about is called an "orphan" process: one whose parent has died first, but that is still alive. All orphans are adopted by process 1 (init). An orphan and a zombie are two different things.
A zombie process is already dead and not running. It can not run, be spawned, or be killed. It can not possibly wait on anything, including it's parent, or do anything. A zombie has no memory, no code, no process counter, no CPU time, nothing. The *kernel* on the other hand will remember the zombie until it's parent either 1) dies, or 2) calls one of the wait() system calls, or 3) the parent had previously told the kernel it doesn't care about dead children.
The signaling you talk about is done by the kernel; not the zombie process.
They [zombies] WILL NOT go away after the parent process dies.
This was incorrectly stated in a previous email.
Try to find one that doesn't go away! I've never seen one in 15 years of Unix programming. Yes, technically, what happens is that when the parent process dies it will be adopted by process number 1 (init). But init (aka the kernel) always reaps dead children immediately. So the end effect is that whenever a parent dies, all of it's zombie children are immediately reaped and disappear.
If you are programming this, you can turn off the signaling of the
parent/child process to make the child not wait until the parent
responds and the child will do it's thing, then cleanly exit. This also
frees up the parent to go about something else, rather than waiting on
the child, which may not complete.
Regardless of any signalling (SIGCHLD), the child *never* waits on anything before it is allowed to die. It just dies. The *only* things that can delay or keep a process from dying when it wants to are 1) it is being traced, 2) it is in the stopped state. (And technically a process in the stopped state by definition can not be dying). Neither of these conditions have anything to do with what a parent process may or may not be doing.
The parent of any non-lazily coded application can certainly do useful work at all times without being blocked while monitoring it's children. This is why the SIGCHLD asynchronous signal is sent, and also why there are the wait3() and wait4() system calls with the WNOHANG flag. (Or, if you're coding directly to the low-level clone() system call any other signal can be set up instead).
The cause of almost all zombies (that stay around more than a millisecond) is either incorrectly or lazily coded parent processes. But if you kill the parent, the zombies will disappear. If this is not the case then file a kernel bug immediately.
And the only bad effect of a zombie process is that it occupies one
of the process "slots" in the kernel table. It otherwise can not consume
any resources (memory, cpu, etc), nor can it hold locks, keep files
or sockets open, or block any other process in any way.
:-) In civil courtroom circles, I believe the exchanges would qualify as expert dueling!
