Zombie processes

Question

I'v some questions about zombie processes

• what the benefits from zombie process concept?
• know that the kernel keeps (PID,termination status, resource usage information) for zombie process
  what's the meaning of "resource usage information"
• how zombie's PPID() = 1 and it still zombie , (init reaps Zombies because it wait() by default)
  can any one write some C code to make a zombie it's parent is Init?
• can zombies refusing to release some lock on memory??

thanks in advance

Answer 1

Zombie processes are not a living thing, so they cannot be killed. Their purpose is for three main reasons:

1. To maintain the pid number allocated while the parent process stays alive and doesn't execute a wait() system call, to prevent other fork() to allocate it and avoid pid clashes. This allocation also avoids (indirectly) to create process groups and sessions with that id number. PID allocation requires a walk through the process table to check that the candidate pid is not already in use, so maintaining process table entries for walking dead processes is a good idea.
2. To store the exit() value, or the status info (if killed) to the parent process that makes a wait() system call.
3. To store temporarily the accounting information about the running time (system/user time accumulated by the process) Today's operating systems have not just this accounting info stored here, but more (swaps, number of system calls, etc)

The solution is so ingenious that nobody has thought it should be changed since its first implementation in AT&T unix. By the way, no system resources other than the process table entry are allocated to them, as all this information is stored there, so no memory or file descriptor implications are due to these processes. They are also excluded from the scheduling tables, so they cannot stand up and walk again.

how zombie's PPID() = 1 and it still zombie , (init reaps Zombies because it wait() by default) can any one write some C code to make a zombie it's parent is Init?

there's a chance that init() has not yet took time to make the wait() system call, and it's still processing the last wait() it accounted for. Another reason is that you have specified another catchall process (linux allows this) instead of init. A Zombie process gets reparented to the process that is waiting for it, only when it makes an exit() system call or is killed by a signal. In a heavy loaded system you can see zombie processes whose PPID is 1, but is not common.

can zombies refusing to release some lock on memory??

zombies are just process table entries. All resources belonging to a zombie have already been returned to the system (the process only enters the zombie state once it has finished releasing all its resources) so no resource lock can be held by a zombie process (the reason is easy, it is dead, so it cannot release it)

Imagine a complex scenario in which a process has acquired a tcpip socket and the socket is in a connected state. Then that process gets killed by a signal becoming a zombie, while the socket is still alive (and releasing that socket requires still running the protocol exchange to close the connection) In this case, the process resources are actually released (this means the file descriptors associated to the socket) but the socket closing is passed to the TCP kernel thread that will continue the work started by the implicit close() call that was made by the kernel when releasing the zombie's resources. If there's no kernel thread dedicated to this purpose, then the process will still be in the process of releasing the resources ---and appears as alive--- until the releasing is done. Once all resources are untied/released from the dying process, it will be marked as a zombie (a corpse would have been a better term) The task of releasing the resources is done in system time, so there's no control that the process can do to it, neither attaching a signal handler or whatever.... once the process is to die, it will die.

Answer 2

-- what the benefits from zombie process concept?

A zombie process is just a pid, an exit status, and some accounting information that stays around until a parent uses one of the wait family of system calls to get its final status. Until a parent calls wait the child's process ID must stay marked as used so that no other process can be assigned it. If another process were to get assigned a recycled pid it would be difficult to tell the difference between it and previous processes that had that same pid. Once wait is called by the parent and returns a final exit status it can be assumed that no one will go looking for the child at that pid again, so the pid may now be reused. (I think on Linux if a parent leaves SIGCHLD as SIG_IGN the kernel will not keep zombies around, but that re-registering SIGCHLD's disposition as SIG_IGN does not have the same effect)

-- know that the kernel keeps (PID,termination status, resource usage information) for zombie process what's the meaning of "resource usage information"

Some of this information is what running a program as:

time my_program

will report. These values are usually reported in the siginfo structure for SIGCHLD (which isn't exactly a call to wait) but also available from a call to the waitid form of systme call (on some systems). Look at man sigaction for info about this structure.

-- how zombie's PPID() = 1 and it still zombie , (init reaps Zombies because it wait() by default)

A zombie whose ppid = 1 should not stay a zombie for very long because init should reap it pretty quickly. A process will remain a zombie from a point soon after it dies (either via exit or by an unhanded signal that kills it) until its parent calls wait and gets it's final status. This means that even if init does nothing but call init over and over there could be a small amount of time where a process may show up as a zombie. If processes show up as children of init (0=ppid) for long amounts of time (seconds) then something is probably wrong.

-- can any one write some C code to make a zombie it's parent is Init?

This isn't clear, but I think you want:

pid_t f = fork();
if (f > 0) {
    exit(0); // this is the parent dying, so the child will be an orphan
             // and get adopted by init
} else if (f == 0) {
    sleep(100); // This is the child doing something that takes enough time for
                // its parent to commit suicide (exit(0)) and then for you to
                // observe that it has now been adopted by init
    exit(0);    // And now it dies as well, so init should reap its status, but
                // it may be a zombie for a short amount of time first.
} else /* error condition would be handled here */

-- can zombies refusing to release some lock on memory??

Zombies can't hold onto much of anything. They lose all of their memory pages, open file handles, ...etc. Pretty much everything the operating system can figure out how to free up should get freed. It would be a bug not to, but remember that the OS has to know that it is something that is supposed to be freed. It is very easy to create resources in user space that should be freed when a program dies that the OS doesn't know are supposed to be freed.

Answer 3

Zombie processes are processes that have stopped running but their process table entry still exists because the parent process hasn't retrieved it via the wait syscall. Technically each process that terminates is a zombie for a very short period of time but they could live for longer.

Longer lived zombie processes occur when parent processes don't call the wait syscall after the child process has finished. One situation where this occurs is when the parent process is poorly written and simply omits the wait call or when the parent process dies before the child and the new parent process does not call wait on it. When a process' parent dies before the child, the OS assigns the child process to the "init" process or PID 1. i.e. The init process "adopts" the child process and becomes its parent. This means that now when the child process exits the new parent (init) must call waitto get its exit code or its process table entry remains forever and it becomes a zombie

Answer 4

If you are interested in seeing the zombie process within a list of running processes use this:

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>

int main(void)
{
    pid_t p = fork();   // creates child process and stores the returned PID

    if (p != 0)         // executed by parent process
    {   sleep(1);       /* the child process terminates while the parent process sleeps,
                           the child then becomes a zombie process because the returned status
                           of the terminated child process isn't checked via a wait() */

        system("ps -eo pid,ppid,stat,cmd");  // prints a list of processes in your terminal

    }
    else        // executed by child process
    {
        exit(0);        // the child process terminates immediately
    }

    return 0;
}

You can identify the zombie process by the Z+ in the list:

NOTE: you will have to modify the code if you are using windows.

Answer 5

A zombie process is purely a pid and exit status value. The pid cannot be released because the resource (the pid) "belongs to" the parent. If it were released, another process might get assigned the same pid, and then the parent could end up sending signals to an unrelated process; even if the parent first waited to determine if the child had exited, there would be no way to avoid race conditions.