In this tutorial, we’ll learn what a zombie process is in modern-day operating systems.
2. Process Lifecycle
Each operating system (OS) has its process lifecycle model. The states and the ways the processes change states vary from one OS to another. For example, here’s a five-state model:
Each state has a specific meaning, and the transitions between the states are clearly defined.
2.1. Zombie State
We see there’s a zombie state in the five-state diagram above. What does this state mean?
Once a process completes its execution or gets terminated, it’ll send a signal (SIGCHLD in Linux systems) to its parent process. The signal will inform the parent that the child process has finished its execution. Afterward, the child process will immediately enter into the zombie state until the parent process reaps it. Reaping refers to the parent reading the information (exit status, usage statistics, process identifier, etc.) of the zombie child process.
To summarize, we can say that a zombie process is a terminated or completed process that remains in the process table. It will be there until its parent process clears it off. And it does this by calling wait() call on its child and reading the exit value and other accounting information.
3. Zombie Processes
A process becomes a zombie after finishing its execution and is in that state until its parent process reaps it. After the parent acknowledges the zombie child’s execution, the OS removes the child’s entry in the process table:
Thus, every process becomes a zombie after its execution.
3.1. Problems with the Zombie State
One major problem with a zombie is that it wastes system resources. The OS can’t release the process identifier of the zombie process (e.g., pid in Linux). This is so because the identifier cannot be reallocated until it’s officially released. Hence, we cannot reuse it while the corresponding process is in the zombie state. If we released it without proper housekeeping and assigned it to another process, the zombie’s parent process would send signals to the new and unrelated process. As a result, we might get unexpected results.
Secondly, zombie processes take up space in the system process table, which has a finite size. So, too many zombie processes can fill the process table. As a result, the operating system won’t be able to generate any new processes and will stop working.
3.2. Benefit of the Zombie State
However, the zombie state offers some benefits to the models with it.
The OS uses the zombie state to make the parent check the child process exit status and resource usage (CPU time, memory usage, IO cycles, etc.). Without the zombie state, the operating system would remove the information about the child processes from the table the moment they finish. But, that would cause problems with the corresponding parent processes since they need to be made aware of their children’s exit statuses and return values.
3.3. Zombie vs. Orphan Process
A zombie process is different from an orphan process.
An orphan process is a process that is still running but whose parent process no longer exists (either killed or exited).
The OS reparents an orphan process when its parent process dies. This means that another running process that got started before the orphan process adopts the orphan process. In most cases, it’s the first process in the operating system. For example, in the Linux system, the init process (the first process, pid = 1) adopts all orphan processes.
Further, an orphan process usually doesn’t become a zombie after it has run. This is so because its new parent process waits for it. For instance, the Linux init process is always waiting for its child processes. So, even if any process exit without cleaning its child processes, all child processes will be adopted and thus will not become zombies.
4. Zombie Process Cleanup
A zombie process is unaffected by the operating system command to forcefully end it. Long-running zombie processes are the results of unintentional mistakes and resource leaks and they take up a lot of space in the process table. Hence, we need to avoid zombie build-up.
We can prevent that by calling the wait call immediately after a child process is executed so that it’s cleaned up from the process table as soon as possible.
In this article, we described the zombie process state. A process enters a zombie state after it stops running and is in it until we remove its entry from the process table.