Editing Zombie process (section)

==Overview==
When a process ends via <code>exit</code>, all of the memory and resources associated with it are deallocated so they can be used by other processes. However, the process's entry in the process table remains. The parent can read the child's exit status by executing the <code>[[wait (system call)|wait]]</code> [[system call]], whereupon the zombie is removed. The <code>wait</code> call may be executed in sequential code, but it is commonly executed in a [[event handler|handler]] for the [[SIGCHLD]] [[signal (computing)|signal]], which the parent receives whenever a child has died.

After the zombie is removed, its [[process identifier]] (PID) and entry in the process table can then be reused. However, if a parent fails to call <code>wait</code>, the zombie will be left in the process table, causing a [[resource leak]]. In some situations this may be desirable – the parent process wishes to continue holding this resource – for example if the parent creates another child process it ensures that it will not be allocated the same PID.  On modern UNIX-like systems (that comply with [[SUSv3]] specification in this respect), the following special case applies: if the parent ''explicitly'' ignores SIGCHLD by setting its handler to <code>SIG_IGN</code> (rather than simply ignoring the signal by default) or has the <code>SA_NOCLDWAIT</code> flag set, all child exit status information will be discarded and no zombie processes will be left.<ref>{{cite web|url=https://www.mankier.com/2/wait#Notes|title=wait(2) Man Page|work=Linux Programmer's Manual}}</ref>

Zombies can be identified in the output from the Unix <code>[[ps (Unix)|ps]]</code> [[command (computing)|command]] by the presence of a "<code>Z</code>" in the "STAT" column.<ref>{{cite web|url=http://www-cdf.fnal.gov/offline/UNIX_Concepts/concepts.zombies.txt|title=Zombies(5) - UNIX System V (Concepts)|work=The Collider Detector at Fermilab}}</ref> Zombies that exist for more than a short period of time typically indicate a bug in the parent program, or just an uncommon decision to not reap children (see example). If the parent program is no longer running, zombie processes typically indicate a bug in the operating system.  As with other resource leaks, the presence of a few zombies is not worrisome in itself, but may indicate a problem that would grow serious under heavier loads. Since there is no memory allocated to zombie processes – the only system memory usage is for the process table entry itself – the primary concern with many zombies is not running out of memory, but rather running out of process table entries, concretely process ID numbers.  However, zombies can hold open buffers that are associated with file descriptors, and thereby cause memory to be consumed by the zombie.  Zombies can also hold a file descriptor to a file that has been deleted.  This prevents the file system from recovering the i-nodes for the deleted file.  Therefore, the command to show disk usage will not count the deleted files whose space cannot be reused due to the zombie holding the filedescriptor.

To remove zombies from a system, the SIGCHLD [[signal (computing)|signal]] can be sent to the parent manually, using the <code>kill</code> command. If the parent process still refuses to reap the zombie, and if it would be fine to terminate the parent process, the next step can be to remove the parent process. When a process loses its parent, <code>init</code> becomes its new parent. <code>init</code> periodically executes the <code>wait</code> system call to reap any zombies with <code>init</code> as parent.