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

摘自Bad CTK:

在某些类型的Unix上，为了进入守护进程模式，你不得不在启动时执行双叉操作。这是因为单分叉不能保证与控制终端分离。”

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

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的冗余…

如果daemon()调用成功，则有父调用_exit()。最初的动机可能是让父母在孩子守护的时候做一些额外的工作。

这也可能是基于一种错误的信念，认为这是必要的，以确保守护进程没有父进程，并被重新父化给init——但在单分叉的情况下，一旦父进程死亡，无论如何都会发生这种情况。

所以我认为这一切最终都归结为传统——只要父母在短时间内死亡，一个分叉就足够了。

严格地说，双分叉与将守护进程作为init的子进程重新养育无关。重父进程所需要的就是父进程必须退出。这只需要一个分叉就可以完成。另外，单独执行double-fork并不会将守护进程重新父化给init;守护进程的父进程必须退出。换句话说，当派生一个正确的守护进程时，父进程总是退出，以便守护进程被重新父化到init。

那么为什么要用双叉呢?POSIX.1-2008第11.1.3节，“控制终端”，有答案(强调添加):

The controlling terminal for a session is allocated by the session leader in an implementation-defined manner. If a session leader has no controlling terminal, and opens a terminal device file that is not already associated with a session without using the O_NOCTTY option (see open()), it is implementation-defined whether the terminal becomes the controlling terminal of the session leader. If a process which is not a session leader opens a terminal file, or the O_NOCTTY option is used on open(), then that terminal shall not become the controlling terminal of the calling process.

这告诉我们，如果一个守护进程做了这样的事情…

int fd = open("/dev/console", O_RDWR);

．.． 然后，守护进程可能会获取/dev/console作为其控制终端，这取决于守护进程是否是会话领导者，以及系统实现。如果程序首先确定控制终端不是会话领导终端，则程序可以保证上述调用不会获取控制终端。

Normally, when launching a daemon, setsid is called (from the child process after calling fork) to dissociate the daemon from its controlling terminal. However, calling setsid also means that the calling process will be the session leader of the new session, which leaves open the possibility that the daemon could reacquire a controlling terminal. The double-fork technique ensures that the daemon process is not the session leader, which then guarantees that a call to open, as in the example above, will not result in the daemon process reacquiring a controlling terminal.

The double-fork technique is a bit paranoid. It may not be necessary if you know that the daemon will never open a terminal device file. Also, on some systems it may not be necessary even if the daemon does open a terminal device file, since that behavior is implementation-defined. However, one thing that is not implementation-defined is that only a session leader can allocate the controlling terminal. If a process isn't a session leader, it can't allocate a controlling terminal. Therefore, if you want to be paranoid and be certain that the daemon process cannot inadvertently acquire a controlling terminal, regardless of any implementation-defined specifics, then the double-fork technique is essential.