Fork and defunct (zombie) process

Fork () can be imagined as a symbol of power, and power can sometimes be imagined as a symbol of destruction. Therefore, be careful when your system is disorganized due to fork (). This is not to say never to Touch fork (), you just need to be cautious.

Fork () is how Unix starts a new process. Basically, it works like this: the parent process (the one that already exists) fork () A child process (the new one). A child process obtains a copy of the parent process data. Look at that. There was only one process before and now there are two.

Of course, you have to cope with a variety of situations when the fork () process, or your system administrator will glare at you because you fill the system's process table and they have to press the machine's restart key.

First, you need to know how some of the processes under Unix work. When a process dies, it is not completely gone. The process terminates, it is no longer running, but there are still some little things left to wait for the parent process to retract. These remnants include the return value of the child process and other things. After the parent process fork () a child process, it must wait for the child process to exit, either by Waiting () (or Waitpid ()). It is this wait () action that makes the residue of the child process disappear.

Naturally, there is an exception to the above rules: the parent process can ignore SIGCLD soft interrupts without the need for wait (). This can be done (on the system that supports it):

Main ()
{
Signal (SIGCLD, sig_ign); /* Now I don ' t have to wait ()! */
.
.
Fork (); fork (); fork (); * Rabbits, rabbits, rabbits! */

Now, the parent process does not have a wait () when the child process dies, and it is usually shown as "<defunct>" by PS. It will always stay this way only to the parent process wait (), or treat it as follows.

Here is another rule you must know: When the parent process dies before it wait () child process (assuming it does not ignore SIGCLD), the child process takes the init (PID 1) process as its parent process. This is not a problem if the child processes work well and are able to control. But if the sub process is already defunct, we have a little trouble. Look, the original parent process could not wait (), because it had died out. In this way, Init knows how to wait () these zombie processes.

The answer: unpredictable. On some systems, Init periodically destroys all of its defunct processes. In other systems, it simply refuses to be the parent process of any defunct process, but destroys them immediately. If you use one of these systems, you can write a simple loop that fills the process table with the defunct process that belongs to init. This is probably not going to make your system administrator happy.

Your task: Make sure your parent process does not ignore SIGCLD, and do not wait () for all processes that it fork (). However, you do it every time you need to (for example, you're going to have a daemon or something), but you have to be careful with programming if you're a fork () novice. In addition, do not have any psychological constraints.

Summary: The child process becomes defunct only to the parent process wait () unless the parent process ignores SIGCLD. Further, a subprocess (active or defunct) of the parent process (which still assumes that the parent process did not ignore SIGCLD) becomes the child process of INIT, and Init handles them with a heavy manipulation.