首页 文章

为什么在fork之后调用setsid?

提问于
浏览
1

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

他解决为什么fork两次的问题的答案实质上是确保分叉进程不是会话领导者因此无法获得tty . 他给出了这个分叉过程的例子,并显示第二个子节点不是会话负责人(第二个分支不是第二个子节点的PID后的SID) .

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之后和"decouple"步骤之前(我假设这是对 setsid() 的调用),孩子不是会话领导者 . 因此我的问题是为什么叫 setsid() ?为什么不分叉一次并退出?

我的猜测是,这与会话领导者是控制终端(或其他祖父母)有关 . 那么一个后续问题就是,一个团队领导退出的过程会发生什么,但其会话领导者还活着?

1 回答

  • 0
    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 .

相关问题