
Introduction
A process is said to be a Zombie process that, even after completing its execution, still has an entry in the process table to report to its parent process. The article will discuss the Zombie process, reasons why we should prevent zombie processes, and different ways to avoid Zombie Processes.
“Also See Topic, procedure call in compiler design, Multiprogramming vs Multitasking"
Zombie Processes
A zombie process, also known as a defunct process, has completed execution but still enters the process table. This is true for child processes, where the entry is still required for the parent process to read the exit state of its child. Once the zombie's entry in the process table is removed, it is stated to be "reaped" once the exit status is obtained via the wait system function. Before being deleted from the resource table, a child process must first become a zombie.
In most cases, zombies are promptly cared for by their parents before being harvested by the system as part of routine system operation. Long-running zombie processes are usually mistakes and resource leaks, but they take up space in the process table.
The kid process has died but is not yet reaped. In addition, unlike normal operations, a zombie process is unaffected by the kill command.
Orphan processes are not to be confused with zombie processes. An orphan process is still running but has lost its parent. When a parent dies, init takes over the orphaned child procedure (process ID 1). Orphan processes do not become zombie processes when they die; instead, init wait for them. As a result, a process that is both a zombie and an orphan will immediately reap the benefits.
Working of Zombie Process
A zombie process in an operating system operates as follows:
- When a process exits, all associated memory and resources are deallocated so that other processes can use them.
- The process's entry in the process table, however, persists. The parent can get the exit status of their child by using the wait system call, which removes the zombie. The wait call can be used in sequential code, but it is most typically used as a handler for the SIGCHLD signal, sent to the parent when a child dies.
- After removing the zombie, the process identifier (PID) and entry in the process table can be reused. If a parent does not call the wait, the zombie will remain in the process table, resulting in a resource leak. In some circumstances, this may be good, and the parent process wishes to keep this resource. For example, if another child process is created by the parent, it will not be given the same PID.
- Modern UNIX-like systems are subject to the following particular situation. All child exit status information is destroyed, and no zombie processes are left if the parent expressly ignores SIGCHLD by setting its handler to SIG_IGN (rather than merely ignoring the signal by default) or has the SA_NOCLDWAIT option set.
- If a "Z" is present in the STAT column in the output of the UNIX "ps" program can be used to identify zombies. Zombies lasting longer than a few minutes are usually the result of a glitch in the parent software or an unusual decision not to reap the child processes.
- The KILL COMMAND can manually send the SIGCHLD signal to the parent to eliminate zombies from a system. If the zombie is still not reaped by the parent process, and if terminating the parent process is acceptable, the parent process can be removed. When a process's parent dies, init takes over as the new parent. Init uses the wait system function to regularly reap any zombies that have init as a parent.
#include <sys/wait.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
pid_t pids[10];
int i;
for (i = 9; i >= 0; --i) {
pids[i] = fork();
if (pids[i] == 0) {
printf("Child%d\n", i);
sleep(i+1);
_exit(0);
}
}
for (i = 9; i >= 0; --i) {
printf("parent%d\n", i);
waitpid(pids[i], NULL, 0);
}
return 0;
}
OUTPUT
