c - 为什么 fork() 在 setsid() 之前

Question

为什么在 setsid() 之前使用 fork() 来守护进程？

基本上，如果我想将一个进程与其控制终端分离并使其成为进程组领导:我使用 setsid()。

在没有 fork 的情况下这样做是行不通的。

为什么？

Answer 1

首先:setsid() 将使您的进程成为进程组的领导者，但它也会使您成为新 session 的领导者。如果您只是对获取自己的进程组感兴趣，请使用 setpgid(0,0)。

现在要了解如果您已经是进程组负责人或 session 负责人，setsid() 返回 EPERM 的实际原因，您必须了解进程组和 session id 是从创建它们的进程的进程 id 初始化的(因此领先它们，即 session 负责人 pid == sid 和进程组负责人 pid == pgid)。进程组也不能在 session 之间移动。

这意味着，如果您是进程组负责人，并且允许创建新 session ，则 sid 和 pgid 将设置为您的 pid，从而使旧进程组中的其他进程处于奇怪的状态:他们的进程组长突然与他们自己可能处于不同的 session 中。这是不允许的，因此内核使用了 EPERM。

现在如果你 fork() 一旦你既不是 session 也不是进程组负责人，因此将你的 sid 和 pgid 设置为你的 pid 是安全的，因为这样的组中没有其他进程。

所以，是的，想想看，这一切都说得通。