Zombie process :
When a child process terminates, it becomes a zombie process, and continues to exist as an entry in the system process table even though it is no longer an actively executing program.
Resource Leak:
When a process ends via exit, 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 wait system call, whereupon the zombie is removed. The wait call may be executed in sequential code, but it is commonly executed in a handler for the SIGCHLD 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 wait, the zombie will be left in the process table, causing a resource leak.
How to handle Resource Leak ?
Such situations are typically handled with a special "reaper" process that locates zombies and retrieves their exit status, allowing the operating system to then deallocate their resources.
A child process always first becomes a zombie, why ?
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
Linux command to identify the Zombie Process :
ps -ef | grep Z
S : sleeping
R : running
D : waiting (over het algemeen voor IO)
T : gestopt (suspended) of getrasseerd
Z : zombie (defunct)
Zombies can be identified in the output from the Unix ps command by the presence of a "Z" in the "STAT" column.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. If the parent program is no longer running, zombie processes typically indicate a bug in the operating system.
Example :
Synchronously waiting for the specific child processes in a (specific) order may leave zombies present longer than the above-mentioned "short period of time". It is not necessarily a program bug.
#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) {
sleep(i+1);
_exit(0);
}
}
for (i = 9; i >= 0; --i)
waitpid(pids[i], NULL, 0);
return 0;
}
Orphan Process :
a child process whose parent process terminates before it does becomes an orphan process.
Handle with root or init process :
Such situations are typically handled with a special "root" (or "init") process, which is assigned as the new parent of a process when its parent process exits. This special process detects when an orphan process terminates and then retrieves its exit status, allowing the system to deallocate the terminated child process.
Sometime child process is not orphan what it seems to be :
If a child process receives a signal, a waiting parent will then continue execution leaving an orphan process behind. Hence it is sometimes needed to check the argument set by wait, waitpid or waitid and, in the case that WIFSIGNALED is true, wait for the child process again to deallocate resources.
When a child process terminates, it becomes a zombie process, and continues to exist as an entry in the system process table even though it is no longer an actively executing program.
Resource Leak:
When a process ends via exit, 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 wait system call, whereupon the zombie is removed. The wait call may be executed in sequential code, but it is commonly executed in a handler for the SIGCHLD 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 wait, the zombie will be left in the process table, causing a resource leak.
How to handle Resource Leak ?
Such situations are typically handled with a special "reaper" process that locates zombies and retrieves their exit status, allowing the operating system to then deallocate their resources.
A child process always first becomes a zombie, why ?
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
Linux command to identify the Zombie Process :
ps -ef | grep Z
S : sleeping
R : running
D : waiting (over het algemeen voor IO)
T : gestopt (suspended) of getrasseerd
Z : zombie (defunct)
Zombies can be identified in the output from the Unix ps command by the presence of a "Z" in the "STAT" column.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. If the parent program is no longer running, zombie processes typically indicate a bug in the operating system.
Example :
Synchronously waiting for the specific child processes in a (specific) order may leave zombies present longer than the above-mentioned "short period of time". It is not necessarily a program bug.
#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) {
sleep(i+1);
_exit(0);
}
}
for (i = 9; i >= 0; --i)
waitpid(pids[i], NULL, 0);
return 0;
}
Orphan Process :
a child process whose parent process terminates before it does becomes an orphan process.
Handle with root or init process :
Such situations are typically handled with a special "root" (or "init") process, which is assigned as the new parent of a process when its parent process exits. This special process detects when an orphan process terminates and then retrieves its exit status, allowing the system to deallocate the terminated child process.
Sometime child process is not orphan what it seems to be :
If a child process receives a signal, a waiting parent will then continue execution leaving an orphan process behind. Hence it is sometimes needed to check the argument set by wait, waitpid or waitid and, in the case that WIFSIGNALED is true, wait for the child process again to deallocate resources.
No comments:
Post a Comment