（相关：大约1000个与守护进程相关的问题 . ）
我一直在基地"because Stevens says so"做双叉 .
当然，这有效，并且99.9％的时间没有明显的差别，但它的效率略低于守护进程应尽可能快地启动（和关闭/重启），并且停机时间很短在两者之间可以实现 .
不， fork 仍然不是一个轻量级的系统调用，所以如果没有两次绝对紧迫的原因，我会很乐意跳过它一次 .
我理解单个fork与中间父进程退出的目的（技术上，已经是两个forks，一个是由shell完成的），这个孤立守护进程，使init采用它，并允许假定的shell返回到提示符（或继续执行批处理文件，无论如何） .
setsid() 现在将守护进程放在新会话中，因此根据定义，它将在与终端使用的会话不同的会话中 . 你关心这一点，因为关闭shell /终端会杀死守护进程，否则这可能是不可取的 .
守护进程现在也是该新会话的会话负责人（以及进程负责人和唯一进程） .
现在......你要分叉第二个（实际上是第三个）时间来保证守护进程不是会话领导者，因为这显然是一件坏事 . 找到一个好的解释为什么它是一个坏事有点困难，但可能它允许意外打开终端并使其成为守护进程的控制终端 . 我想，这也意味着当终端关闭时它会被杀死 .
在这里，我们甚至不知道如何打开一个控制终端（打开 /dev/tty ？），也不知道为什么我想要这样做，也不知道它是如何意外发生的，甚至更多，因为 chroot 将会成功甚至故意在 /dev 打开随意文件有点困难，假设例如守护进程根据未经验证的用户请求天真地打开文件，并且您试图故意恶意攻击 .
那么，我究竟想用这个第二个叉子来防御它到底是什么？ Session 领导者实际上是一个实际的，不是完全理论的问题吗？