On Unix and Unix-like computer operating systems, a zombie process or defunct process is a process that has completed execution but still has an entry in the process table. This entry is still needed to allow the process that started the (now zombie) process to read its exit status.
Definition
On Unix and Unix-like computer operating systems, a zombie process or defunct process is a process that has completed execution (via the
exitsystem call) but still has an entry in the process table: it is a process in the "Terminated state". This occurs for child processes, where the entry is still needed to allow the parent process to read its child's exit status: once the exit status is read via the wait system call, the zombie's entry is removed from the process table and it is said to be "reaped". A child process always first becomes a zombie before being removed from the resource table. In most cases, under normal system operation zombies are immediately waited on by their parent and then reaped by the system – processes that stay zombies for a long time are generally an error and cause a resource leak.The term zombie process derives from the common definition of zombie — an undead person. In the term's metaphor, the child process has "died" but has not yet been "reaped". Also, unlike normal processes, the
killcommand has no effect on a zombie process.Zombie processes should not be confused with orphan processes: an orphan process is a process that is still executing, but whose parent has died. These do not remain as zombie processes; instead, (like all orphaned processes) they are adopted by
init(processID 1), which waits on its children. The result is that a process that is both a zombie and an orphan will be reaped automatically. Wikipedia
How do I see if there are zombie processes on a system?
Run “ps aux” and look for a Z in the STAT column.
How do I remove zombie processes from a system?
Well, first you can wait. It’s possible that the parent process is intentionally leaving the process in a zombie state to ensure that future children that it may create will not receive the same pid. Or perhaps the parent is occupied, and will reap the child process momentarily.
Secondly, you can send a SIGCHLD signal to the parent (“kill -s SIGCHLD “). This will cause well-behaving parents to reap their zombie children.
Finally, you can kill the parent process of the zombie. At that point, all of the parent’s children will be adopted by the init process (pid 1), which periodically runs wait() to reap any zombie children.
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 wait, 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 SIG_IGN (rather than simply ignoring the signal by default) or has the SA_NOCLDWAIT flag set, all child exit status information will be discarded and no zombie processes will be left.
Dangers of Zombie Processes:
Zombie processes don't use up any system resources other than a tiny amount of system memory needed to store their process descriptors. However, each zombie process retains its process ID (PID). Linux systems have a finite number of process IDs (32767 by default on 32-bit systems). If zombies are accumulating at a very quick rate (e.g., if improperly programmed server software is creating zombie processes under load), then eventually no PIDs will be available for other processes, preventing them from launching.
While a few zombie processes hanging around are no problem, they do indicate a bug with the parent process that spawned them.
Related tags
