Why doesn't kill work?

[Deron Meranda]

On Sun, 20 Feb 2005 23:00:15 -0500, Scot L. Harris <webid at cfl.rr.com> wrote:
> Such [zombie] processes usually result from the parent being killed or exiting
> with out sending the exit code to the child process.
> 
> As far as  know these will hang around until you reboot the system.
> Would be good to try to identify the program that is generating the
> zombies and see if there is a fix.  It really should clean up after
> itself.

You've got the direction (parent->child) reversed.

A zombie is always the result of it's parent process, never it's
own fault.  Killing the parent process will always get rid of any
zombies; you don't need to reboot unless the parent itself can't
be killed.

What really happens is when a process dies (for whatever reason),
there is a small amount of status information that is saved so the
parent process later can tell why it's child died and if it was "successful"
or not.  This status information, which primarily includes an exit code,
is usually just a few bytes in size.  But the kernel saves it until the
parent process gets around to asking for it (which when it does so
is called "reaping" the child process).  As long as the kernel is
remembering those few status bytes, the zombie process entry stays
in the process listing.  Of course there is no real process (it has
since died and all it's memory/resources released back to the OS).
A zombie will stay as long as the parent process ignores it and fails
to ask for its exit status code, or until the parent itself dies, whichever
occurs first.

Whenever almost any process dies, zombies are created.  But most
parent processes (like bash for example) immediately reap the zombie,
so you'll almost never see them.  However, some parent processes are
not designed properly to react to dead children in a timely manner, so
you may see zombie processes.  Again, it's the parent process to blame.

-- 
Deron Meranda