为什么而fork（）的两次daemonizing？ [英] Why fork() twice while daemonizing?

问题描述

我wodering为什么人们呼吁叉（）两次，为什么在执行第一个呼叫的前的 setsid （）。

I'm wodering why people are calling fork() twice and why the 1st call is performed before setsid().

是的，如果主叫方已经是一个进程组长没有创建新的会话。但如果我只是不使（盛大）父进程组的领导者？谁愿意让这对我（不问我）？ （好吧，也许1llum1n4t1，Sc13nt0l0gy，国家安全局，...;））

Yes, no new session is created if the caller is already a process group leader. But what if I just don't make the (grand)parent a process group leader? Who would make it for me (without asking me)? (OK, maybe 1llum1n4t1, Sc13nt0l0gy, the NSA, ... ;) )

是的，第一个孩子应该退出的立即的不创建僵尸进程。但不能在（大）母公司刚退出后分叉？或将一个或两个 fprintf中（标准错误，... 或写（2，... 通话（如成功启动后台XY）是这样的大不了的？（和我能不能prevent僵尸另一种方式？）

Yes, the 1st child should exit immediately not to create a zombie process. But couldn't the (grand)parent just exit after forking? Or would one or two fprintf(stderr,... or write(2,... calls (like "successfully started daemon xy") be such a big deal? (And couldn't I prevent zombies another way?)

所有的一切，这是双 - 叉（） - 神奇真正的需要的（不要让麻烦）？
抑或只是传统或所谓的最佳实践（如转到的回避）？
或者它只是保证守护进程的历史（当然我的意思是太旧在生产环境中使用）的工作就像SVR4，BSD 3，RHEL 2还是有些蹩脚，32位嵌入式那些平台？

All in all, is this double-fork()-"magic" really required (not to get trouble)? Or is it just tradition or so-called "best practise" (like the avoiding of goto)? Or does it just guarantee the daemon to work on "historical" (of course I mean "far too old for usage in production environments") platforms like SVr4, BSD 3, RHEL 2 or some crappy, 32-bit embedded ones?

推荐答案

第一次调用叉（2）确保过程不是组长，使它有可能为这一进程创造一个新的会话，成为会话组长。还有其他原因，第一个叉（2）：如果守护进程开始作为一个shell命令，具有过程叉和家长退出使得外壳回到它的提示并等待更多的命令。

The first call to fork(2) ensures that the process is not a group leader, so that it is possible for that process to create a new session and become a session leader. There are other reasons for the first fork(2): if the daemon was started as a shell command, having the process fork and the parent exit makes the shell go back to its prompt and wait for more commands.

第二个叉（2）是有保证新进程不是会话组长，所以它不能够（不小心）分配一个控制终端，因为守护进程不应该曾经有一个控制终端。关于第二个岔路口，这里是从的 UNIX环境的第13章（守护进程）高级编程报价：

The second fork(2) is there to ensure that the new process is not a session leader, so it won't be able to (accidentally) allocate a controlling terminal, since daemons are not supposed to ever have a controlling terminal. About the 2nd fork, here's a quote from Advanced Programming in the UNIX Environment, Chapter 13 (Daemon Processes):

在基于System V的系统中，有些人建议再次调用fork
  在这点上，终止母体，并继续在后台
  这个孩子。这保证了守护进程不是会话组长，
  从下获取控制终端其中prevents它
  System V的规则。另外，为了避免收购控股
  终端，一定要指定O_NOCTTY只要打开终端
  设备。

Under System V-based systems, some people recommend calling fork again at this point, terminating the parent, and continuing the daemon in the child. This guarantees that the daemon is not a session leader, which prevents it from acquiring a controlling terminal under the System V rules. Alternatively, to avoid acquiring a controlling terminal, be sure to specify O_NOCTTY whenever opening a terminal device.

这本书的第13.3节描述了daemonizing的过程时使用了更多的规则和模式，这是非常值得的时间去阅读它，如果你能。

Section 13.3 of that book describes a lot more rules and patterns that are used when daemonizing a process, it is well worth the time to read it, if you can.

这篇关于为什么而fork（）的两次daemonizing？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！