为什么在fork()
之前先用setsid()
守护进程?
基本上,如果我想从进程的控制终端中分离出一个进程并使其成为进程组负责人:我使用setsid()
。
在不 fork 的情况下执行此操作不起作用。
为什么?
最佳答案
首先:setsid()将使您的流程成为流程组的负责人,但也将使您成为新 session 的负责人。如果您只想获取自己的进程组,请使用setpgid(0,0)。
现在,为了了解如果您已经是流程组负责人或 session 负责人的话,setsid()返回EPERM的实际原因,您必须了解,流程组和 session ID是从创建它们的流程的流程ID中初始化的(因此导致它们,即 session 负责人pid == sid和进程组负责人pid == pgid)。同样,进程组不能在 session 之间移动。
这意味着,如果您是流程组组长,并且允许创建新 session ,则sid和pgid将被设置为您的pid,而旧流程组中的其他进程则处于一种奇怪的状态:它们的流程组组长突然在不同的 session 中,那么他们本人可能就在。而且这是不允许的,因此是内核的EPERM。
现在,如果您既不是 session 组也不是进程组组长,则只要fork()即可,因此将sid和pgid设置为pid是安全的,因为该组中没有其他进程。
所以,是的,考虑一下,这一切都是有道理的。
关于c - 为什么在setsid()之前使用fork(),我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/2613104/