当前位置：文江博客话题详情

创建守护进程时执行双分叉的原因是什么？

发布于 2024-07-21 13:21:25 字数 268 浏览 7 评论 0原文

我正在尝试用 python 创建一个守护进程。我发现了以下问题，它有一些好处我目前正在关注其中的资源，但我很好奇为什么需要双叉。我在谷歌上搜索了一下，发现很多资源都声称这是必要的，但没有说明原因。

有人提到这是为了防止守护进程获取控制终端。如果没有第二个叉子，它将如何做到这一点？有何影响？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

给我一枪 2024-07-28 13:21:25

我试图理解双叉并在这里偶然发现了这个问题。经过大量研究后，这就是我的结论。希望它能帮助有同样问题的人更好地澄清问题。

在 Unix 中，每个进程都属于一个组，而该组又属于一个会话。这是层次结构…

会话（SID）→ 进程组（PGID）→ 进程（PID）

进程组中的第一个进程成为进程组领导者，会话中的第一个进程成为会话领导者。每个会话都可以有一个与其关联的 TTY。只有会话领导者才能控制 TTY。对于真正守护进程（在后台运行）的进程，我们应该确保会话领导者被杀死，以便会话不可能控制 TTY。

我在 Ubuntu 上从此站点运行了 Sander Marechal 的 python 示例守护程序程序。这是我的评论的结果。

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

请注意，该进程是 De Couple#1 之后的会话领导者，因为它是 PID = SID。它仍然可以控制 TTY。

请注意，Fork#2 不再是会话领导者 PID != SID。此进程永远无法控制 TTY。 真正的守护进程。

我个人认为术语 fork-twice 很令人困惑。更好的习惯用法可能是 fork-de Couple-fork。

其他感兴趣的链接：

Unix 进程 - http://www. win.tue.nl/~aeb/linux/lk/lk-10.html

I was trying to understand the double fork and stumbled upon this question here. After a lot of research this is what I figured out. Hopefully it will help clarify things better for anyone who has the same question.

In Unix every process belongs to a group which in turn belongs to a session. Here is the hierarchy…

Session (SID) → Process Group (PGID) → Process (PID)

The first process in the process group becomes the process group leader and the first process in the session becomes the session leader. Every session can have one TTY associated with it. Only a session leader can take control of a TTY. For a process to be truly daemonized (ran in the background) we should ensure that the session leader is killed so that there is no possibility of the session ever taking control of the TTY.

I ran Sander Marechal's python example daemon program from this site on my Ubuntu. Here are the results with my comments.

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

Note that the process is the session leader after Decouple#1, because it's PID = SID. It could still take control of a TTY.

Note that Fork#2 is no longer the session leader PID != SID. This process can never take control of a TTY. Truly daemonized.

I personally find terminology fork-twice to be confusing. A better idiom might be fork-decouple-fork.

Additional links of interest:

Unix processes - http://www.win.tue.nl/~aeb/linux/lk/lk-10.html

回复收藏 0 原文

审判长 2024-07-28 13:21:25

严格来说，双分叉与将守护进程重新设置为 init 的子进程无关。重新设置子进程的父级所需要的只是父级必须退出。只需使用一个叉子即可完成此操作。此外，单独执行双分叉不会将守护进程重新设置为 init；守护进程的父进程必须退出。换句话说，当分叉适当的守护进程时，父进程总是退出，以便守护进程重新成为 init 的父进程。

那么为什么要使用双叉呢？ POSIX.1-2008 第 11.1.3 节，“控制终端"，有答案（强调）：

会话的控制终端由会话领导者以实现定义的方式分配。如果会话领导者没有控制终端，并且在不使用 O_NOCTTY 选项（请参阅 open()）的情况下打开尚未与会话关联的终端设备文件，则它终端是否成为会话领导者的控制终端是实现定义的。如果不是会话领导者的进程打开终端文件，或者在open()上使用O_NOCTTY选项，则该终端不应成为调用进程的控制终端。

这告诉我们，如果守护进程执行类似这样的操作……

int fd = open("/dev/console", O_RDWR);

那么守护进程可能获取/dev/console作为其控制终端，具体取决于是否守护进程是一个会话领导者，并且取决于系统的实现。如果程序首先确保它不是会话领导者，则程序可以保证上述调用不会获取控制终端。

通常，当启动守护进程时，会调用setsid（在调用fork后从子进程调用）以将守护进程与其控制终端分离。然而，调用setsid也意味着调用进程将成为新会话的会话领导者，这使得守护进程有可能重新获取控制终端。双分叉技术确保守护进程不是会话领导者，从而保证对 open 的调用（如上例所示）不会导致守护进程重新获取控制终端。

双叉技术有点偏执。如果您知道守护进程永远不会打开终端设备文件，则可能没有必要。此外，在某些系统上，即使守护程序确实打开终端设备文件，也可能没有必要，因为该行为是实现定义的。然而，不是实现定义的一件事是只有会话领导者可以分配控制终端。 如果进程不是会话领导者，则它无法分配控制终端。因此，如果您想保持偏执并确保守护进程不会无意中获取控制终端，无论任何实现定义的细节，那么双分叉技术都是必不可少的。

Strictly speaking, the double-fork has nothing to do with re-parenting the daemon as a child of init. All that is necessary to re-parent the child is that the parent must exit. This can be done with only a single fork. Also, doing a double-fork by itself doesn't re-parent the daemon process to init; the daemon's parent must exit. In other words, the parent always exits when forking a proper daemon so that the daemon process is re-parented to init.

So why the double fork? POSIX.1-2008 Section 11.1.3, "The Controlling Terminal", has the answer (emphasis added):

The controlling terminal for a session is allocated by the session leader in an implementation-defined manner. If a session leader has no controlling terminal, and opens a terminal device file that is not already associated with a session without using the O_NOCTTY option (see open()), it is implementation-defined whether the terminal becomes the controlling terminal of the session leader. If a process which is not a session leader opens a terminal file, or the O_NOCTTY option is used on open(), then that terminal shall not become the controlling terminal of the calling process.

This tells us that if a daemon process does something like this ...

int fd = open("/dev/console", O_RDWR);

... then the daemon process might acquire /dev/console as its controlling terminal, depending on whether the daemon process is a session leader, and depending on the system implementation. The program can guarantee that the above call will not acquire a controlling terminal if the program first ensures that it is not a session leader.

Normally, when launching a daemon, setsid is called (from the child process after calling fork) to dissociate the daemon from its controlling terminal. However, calling setsid also means that the calling process will be the session leader of the new session, which leaves open the possibility that the daemon could reacquire a controlling terminal. The double-fork technique ensures that the daemon process is not the session leader, which then guarantees that a call to open, as in the example above, will not result in the daemon process reacquiring a controlling terminal.

The double-fork technique is a bit paranoid. It may not be necessary if you know that the daemon will never open a terminal device file. Also, on some systems it may not be necessary even if the daemon does open a terminal device file, since that behavior is implementation-defined. However, one thing that is not implementation-defined is that only a session leader can allocate the controlling terminal. If a process isn't a session leader, it can't allocate a controlling terminal. Therefore, if you want to be paranoid and be certain that the daemon process cannot inadvertently acquire a controlling terminal, regardless of any implementation-defined specifics, then the double-fork technique is essential.

回复收藏 0 原文

醉酒的小男人 2024-07-28 13:21:25

查看问题中引用的代码，理由是：

分叉第二个孩子并立即退出以防止僵尸。这
导致第二个子进程成为孤立进程，从而使 init
负责其清理的进程。而且，由于第一个孩子是
没有控制终端的会话领导者，可以
它可以通过在未来打开一个终端来获取一个（系统V-
为基础的系统）。这第二个叉子保证了孩子不会
延长会话领导者的时间，防止守护进程获取
控制终端。

因此，它是为了确保守护进程重新成为 init 的父级（以防启动守护进程的进程长期存在），并消除守护进程重新获取控制 tty 的任何机会。因此，如果这两种情况都不适用，那么一把叉子就足够了。 “Unix 网络编程 - Stevens”对此有很好的部分。