17th Feb 2017
UNIX Concepts: Zombies
UNIX: Zombies, and the Killing of Parents and Children
Zombies(5) UNIX System V (Concepts) Zombies(5)
NAME
Defunct, zombie and immortal processes
DESCRIPTION
When a process dies, it becomes a zombie (almost dead)
process whose only remaining purpose is to hold its death
certificate (the exit status data returned by the wait
family of system calls). When the death certificate has
been collected, the process is finally removed from
existence and from the systems's process table. Zombie
processes are marked as <defunct> in ps listings.
If the parent of a child has not disowned the child and the
parent dies before collecting the child's death certificate,
the child is sent to the state orphanage. As long as the
parent is alive and the child was not disowned, when a child
tries to die, the zombie child remains around until the
parent finally collects its death certificate. The state
orphanage, process 1 a.k.a. /etc/init, is the second process
created after the system is booted and has several principal
functions: starting and in some cases maintaining the system
daemons and waiting for its children to die. It is given
the job of waiting for the deaths of orphaned children as
well. This allows zombie children to be put to rest.
As an aside, when the system is booted, the boot loader
copies the kernel into memory, creates a stack and calls the
kernel's main procedure which, in turn, makes itself into
process 0, forks itself and that child, process 1, executes
/etc/init. In parallel to /etc/init starting the system and
the system daemons, process 0 may continue to fork and
execute portions of the kernel as asychronous precesses.
Process 1 is and other processes with process 0 as their
parent may be protected from being given a KILL signal.
Processes waiting at very high priorities can not be killed
because the signal is first posted to the process kernel
control data of the process; but the remaining processing
and possible jump to process termination only occurs at
lower priorities, that is, below PZERO. In fact, the final
processing of a signal within a process occurs just as the
process is being readied for return to user state. If the
system is a multiple CPU system, the signaling process and
the signaled processes are running on different CPUs and the
signaled process in running in user state, then the
signaling CPU interrupts the signaled CPU so that the signal
can be processed for the signaled process. If the process
execution does not reach this point of return to user state,
then the process can not be signaled (in the case of the
KILL signal, killed).
A zombie process, since it is already almost dead, can not
Page 1 (printed 12/13/97)
Zombies(5) UNIX System V (Concepts) Zombies(5)
be killed further.
Slightly more technical presentation of the above material:
If the parent of a forked (or sproced) child did not have
SIGCHLD set to the ignore signal condition and the parent
exits or is terminated by the system before the parent
process has issued one of the wait system calls and
retrieved the ending status of the child, the parentage of
the child process is reassigned to process 1 (/etc/init in
most cases). As long as the the parent is alive and SIGCHLD
is not set to ignore signal condition, the process struct of
the terminated process is retained in the kernel so that the
ending status of the child if and when a wait system call is
issued for the child process. Process 1 (/etc/init) after
it has initialized the non kernel functions of the operating
system, loops on the wait system call. When a orphan dies,
process 1 receives and ignores its ending status---this
releases the process struct of the terminated process.
/etc/init is also looking for the death of its own children
so that it can start other processes dependent of that
termination or so that it can restart another copy of the
process that just terminated. For example, the historical
login processing is: init forks itself and execs getty, the
getty program (in the child) waits for the communications
port to open, getty emits the ``login: '' prompt, getty
execs login on top of itself, login authenicates the user,
initializes the user uid, gid, current and root directories,
etc. and execs the user's login shell on top of itself.
When the login process terminates, /etc/init receives its
ending status (it is the parent) and it forks itself and
execs getty, ....
No, there is not a ``fix''. That is the way it is designed
to work. It has been this way back at least as far as
Release 3 UNIX (and Release 6 was the first version to
offically escape Bell Labs).
Immortal processes (except those specifically protected by
the kernel, that is, those processes whose parent is 0), are
caused by the processed waiting for an event (usually I/O
related) at a very high priority (typically described as
waiting above PZERO). Since such processes usually have
critical system resources locked, breaking the lock in a
manner that does not release those resource could become a
major disaster.
A zombie is immortal. An immortal process is not
necessarily a zombie. A zombie or defunct process is the
death certificate of a process that has already terminated.
The only system resource being consumed by it is the process
Page 2 (printed 12/13/97)
Zombies(5) UNIX System V (Concepts) Zombies(5)
block used to store its termination status until the parent
process asks for the exit status with a wait(2) family
system call.
When the parent finally dies, any surviving children,
including the zombies are reassigned to the system
orphanage---process 1. Process 1, /etc/init, is the system
reaper of orphaned children as well as its own. The other
purposes of init are system start up and shutdown and the
respawnning (restarting, if you wish) of system services
such as gettys.
The fact that zombied orphans survive long enough for you to
observe them is cause for concern about init's health.
Defunct processes are zombie processes; these can be deleted
by killing the parent program. Use the PPID value to locate
the parent; if the PPID is 1, then rebooting is the only
solution.
There are immortal processes which derive from another
source. For these, the only practical solution is rebooting.
If a process, while in the kernel locks system critical
resources, then the process raises its processing priority
above or at the PZERO level. Such processes will not be
interrupted by the kernel. If the event for which the
process is waiting will never occur, then the process
becomes immortal. For example, if a tape drive is unpowered
during an I/O operation, then it will never send an I/O
complete signal. The tape drive is a system critical
resource and therefore the process is waiting above or at
PZERO. For another example, in SGI IRIX, kernel mode NFS
network communications appears to be handle at or above
PZERO. Other examples are possible. An immortal process
results.
AUTHOR
Randolph J. Herber.
Page 3 (printed 12/13/97)
Invest in your career. Buy my Shell Scripting Tutorial today:
og:image credit: Unknown. Please contact me if source is known.
Steve Parker - Linux / DevOps Consultant
