linux - 为什么在 fork 之后调用 setsid？

Question

这是一个关于 Praveen Gollakota's 的答案的问题在 another question 中回答(这是我应该绕过评论特权的方式吗？)。

他对为什么 fork 两次这个问题的回答本质上是为了确保 fork 进程不是 session leader，因此无法获得 tty。他举了这个fork过程的例子，说明老二不是session leader(第二次fork后的SID不是老二的PID)。

1. `Parent`    = PID: 28084, PGID: 28084, SID: 28046
2. `Fork#1`    = PID: 28085, PGID: 28084, SID: 28046
3. `Decouple#1`= PID: 28085, PGID: 28085, SID: 28085
4. `Fork#2`    = PID: 28086, PGID: 28085, SID: 28085

但是，您还可以在这里看到，在第一个 fork 之后和“分离”步骤之前(我假设这是对 setsid() 的调用)，子进程不是 session 领导者。因此我的问题是为什么要调用 setsid()？为什么不 fork 一次就退出？

我的猜测是，这与 session 领导者是控制终端(或其他祖 parent )有关。因此，后续问题是，组长退出但 session 组长仍然存在的进程会发生什么情况？

Answer 1

1. `Parent`    = PID: 28084, PGID: 28084, SID: 28046

程序此时有一个控制终端。

2. `Fork#1`    = PID: 28085, PGID: 28084, SID: 28046

此时程序仍然有一个控制终端。如果父进程退出，这个子进程将属于一个废弃的进程组。它可以setpgid()到同一 session 中的另一个进程组。

3. `Decouple#1`= PID: 28085, PGID: 28085, SID: 28085

现在程序在另一个 session 中，无法setpgid()切换到原 session 中的进程组。

4. `Fork#2`    = PID: 28086, PGID: 28085, SID: 28085

重新访问init。