为什么要在分叉后调用 setsid?



这是一个关于回答Praveen Gollakota在另一个问题中的答案的问题(这是我应该绕过评论特权的方式吗?(。

他对为什么分叉两次这个问题的回答本质上是为了确保分叉进程不是会话领导者,因此无法获得 tty。他给出了这个分叉过程的例子,并表明第二个子级不是会话领导者(第二个分叉后的 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

但是,您还可以在这里看到,在第一个分叉之后和"解耦"步骤之前(我假设这是对setsid()的调用(,孩子不是会话领导者。因此,我的问题是为什么要打电话给setsid()?为什么不分叉一次然后退出?

我的猜测是,这与会话领导者是控制终端(或其他祖父母(有关。因此,后续问题是,如果一个组长退出,但其会话组长还活着的流程会发生什么?

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

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

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

此时,程序仍然具有控制终端。如果父级退出,则此子项将属于放弃的进程组。它可以setpgid()到同一会话中的另一个进程组。

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

现在,程序位于另一个会话中,无法setpgid()切换到原始会话中的进程组。

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

重新设置为init

相关内容

  • 没有找到相关文章

最新更新