On Sun, 20 Feb 2005 23:00:15 -0500, Scot L. Harris <webid@xxxxxxxxxx> 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
