wait && child process && fork

为何要fork()两次来避免产生僵尸进程？

      当我们只fork()一次后，存在父进程和子进程。这时有两种方法来避免产生僵尸进程：

• 父进程调用waitpid()等函数来接收子进程退出状态。
• 父进程先结束，子进程则自动托管到Init进程（pid = 1）。

      目前先考虑子进程先于父进程结束的情况：     

• 若父进程未处理子进程退出状态，在父进程退出前，子进程一直处于僵尸进程状态。
• 若父进程调用waitpid()（这里使用阻塞调用确保子进程先于父进程结束）来等待子进程结束，将会使父进程在调用waitpid()后进入睡眠状态，只有子进程结束父进程的waitpid()才会返回。 如果存在子进程结束，但父进程还未执行到waitpid()的情况，那么这段时期子进程也将处于僵尸进程状态。

      由此，可以看出父进程与子进程有父子关系，除非保证父进程先于子进程结束或者保证父进程在子进程结束前执行waitpid()，子进程均有机会成为僵尸进程。那么如何使父进程更方便地创建不会成为僵尸进程的子进程呢？这就要用两次fork()了。

      父进程一次fork()后产生一个子进程随后立即执行waitpid(子进程pid, NULL, 0)来等待子进程结束，然后子进程fork()后产生孙子进程随后立即exit(0)。这样子进程顺利终止（父进程仅仅给子进程收尸，并不需要子进程的返回值），然后父进程继续执行。这时的孙子进程由于失去了它的父进程（即是父进程的子进程），将被转交给Init进程托管。于是父进程与孙子进程无继承关系了，它们的父进程均为Init，Init进程在其子进程结束时会自动收尸，这样也就不会产生僵尸进程了。

zzyong08 hightman cjaizss

父进程可以wait，子进程也算父进程的资源，它结束了，父进程有权力知道，更多的时候，是必须知道。如果父进程派生worker进程，worker进程意外终止，父进程可能需要重新fork子进程来干活。这时候wait是很有必要的。     linux 也提供了机制，父进程也可以不wait，通过signal(SIGCHLD, SIG_IGN)，子进程不会变成僵尸进程。

你死了能自己埋自己吗，还得别人给你善后。同一个道理～～

生了一个儿子,如果儿子先死,做爹的总是要想知道的嘛,所以UNIX就这么设计了. 但也会有狠心的爹. 于是有些版本的UNIX,比如linux就提供了用sigaction使得儿子们死了不用报告,不经过zombie

Zombie 产生

由于子进程的结束和父进程的运行是一个异步过程，即父进程永远无法预测子进程 到底什么时候结束. 那么会不会因为父进程太忙来不及wait子进程，或者说不知道 子进程什么时候结束，而丢失子进程结束时的状态信息呢? 不会。因为UNⅨ提供了一种机制可以保证只要 父进程想知道子进程结束时的状态信息， 就可以得到。这种机制就是： 在每个进程退出的时候， 内核释放该进程所有的资源，包括打开的文件，占用的内存等。但是仍然为其保留一定的信息（包括进程号the process ID，退出状态the termination status of the process，运行时间the amount of CPU time taken by the process等）。直到 父进程通过wait / waitpid来取时才释放. 但这样就导致了问题，如果进程不调用wait / waitpid的话，那么保留的那段信息就不会释放，其进程号就会一直被占用，但是系统所能使用的进程号是有限的，如果大量的产生 僵死进程，将因为没有可用的进程号而导致系统不能产生新的进程. 此即为僵尸进程的危害，应当避免。

僵尸进程的避免

⒈ 父进程通过wait和waitpid等函数等待子进程结束，这会导致父进程挂起。

⒉ 如果 父进程很忙，那么可以用signal函数为SIGCHLD安装handler，因为子进程结束后， 父进程会收到该信号，可以在handler中调用wait回收。

⒊ 如果 父进程不关心子进程什么时候结束，那么可以用signal（SIGCHLD,SIG_IGN） 通知 内核，自己对子进程的结束不感兴趣，那么子进程结束后，内核会回收， 并不再给父进程发送信号。

⒋ 还有一些技巧，就是fork两次， 父进程fork一个子进程，然后继续工作，子进程fork一 个孙进程后退出，那么孙进程被init接管，孙进程结束后，init会回收。不过子进程的回收 还要自己做。

SIGCHLD

FreeBSD 5.4上 man signal

     If a process explicitly specifies SIG_IGN as the action for the signal
     SIGCHLD, the system will not create zombie processes when children of the
     calling process exit.  As a consequence, the system will discard the exit
     status from the child processes.  If the calling process subsequently
     issues a call to wait(2) or equivalent, it will block until all of the
     calling process's children terminate, and then return a value of -1 with
     errno set to ECHILD.

linux上同样看了man signal,上面是这么写的:

QUOTE:
According  to  POSIX  (3.3.1.3)  it  is  unspecified  what happens when
       SIGCHLD is set to SIG_IGN.  Here the BSD and  SYSV  behaviours  differ,
       causing  BSD  software  that  sets the action for SIGCHLD to SIG_IGN to
       fail on Linux.

APUE2中是这么写的:

QUOTE:
SIGCHLD
Whenever a process terminates or stops, the SIGCHLD signal is sent to the parent. By default, this signal is ignored, so the parent must catch this signal if it wants to be notified whenever a child's status changes. The normal action in the signal-catching function is to call one of the wait functions to fetch the child's process ID and termination status.

而关于僵尸进程APUE2是这么写的(section8.5):

QUOTE:
In UNIX System terminology, a process that has terminated, but whose parent has not yet waited for it, is called a zombie.

总之：SIGCHLD设置为 SIG_IGN  是系统实现相关。有的直接就terminal child process , therefore no zombie process。

一般来说，需要wait处理SIGCHILD。