一个原因是父进程可以立即为子进程wait_pid()，然后忘记它。当孙子孙女死亡时，它的父节点是init，它将wait()等待它——并将它从僵尸状态中取出。

结果是，父进程不需要知道被分叉的子进程，这也使得从库等中分叉长时间运行的进程成为可能。

查看问题中引用的代码，理由是:

Fork a second child and exit immediately to prevent zombies. This causes the second child process to be orphaned, making the init process responsible for its cleanup. And, since the first child is a session leader without a controlling terminal, it's possible for it to acquire one by opening a terminal in the future (System V- based systems). This second fork guarantees that the child is no longer a session leader, preventing the daemon from ever acquiring a controlling terminal.

因此，这是为了确保守护进程被重新父化到init上(以防启动守护进程的进程是长期存在的)，并消除守护进程重新获得控制tty的任何机会。因此，如果这两种情况都不适用，那么一个分叉就足够了。“Unix网络编程- Stevens”在这方面有一个很好的章节。

关于它的一个像样的讨论似乎在http://www.developerweb.net/forum/showthread.php?t=3025上

引用mlampkin的话:

.．.将setsid()调用视为做事的“新”方式(与终端分离)，而[第二个]fork()调用作为处理SVr4的冗余…

根据Stephens和Rago的“Unix环境中的高级编程”，第二个fork更多的是一个建议，它是为了保证守护进程不会在基于System v的系统上获得控制终端。

一个原因是父进程可以立即为子进程wait_pid()，然后忘记它。当孙子孙女死亡时，它的父节点是init，它将wait()等待它——并将它从僵尸状态中取出。

结果是，父进程不需要知道被分叉的子进程，这也使得从库等中分叉长时间运行的进程成为可能。

这样也许更容易理解:

第一个fork和setsid将创建一个新的会话(但是进程ID ==会话ID)。 第二个fork确保进程ID !=会话ID。