Linux 守护进程 [英] Linux daemonize

问题描述

我正在编写一个 Linux 守护进程.我找到了两种方法.

1. 通过调用 fork() 并设置 sid 来守护进程.
2. 使用 & 运行您的程序.

正确的做法是什么?

解决方案

来自 http://www.steve.org.uk/Reference/Unix/faq_2.html#SEC16

<块引用>

以下是成为守护进程的步骤:

1. fork() 以便父级可以退出，这会将控制权返回给调用您的程序的命令行或 shell.此步骤是必需的，以便保证新进程不是进程组组长.如果您是流程组负责人，则下一步 setsid() 将失败.
2. setsid() 成为进程组和会话组的领导者.由于控制终端与会话相关联，而这个新会话还没有获得控制终端，我们的进程现在没有控制终端，这对守护进程来说是件好事.
3. fork() 再次让父节点(会话组组长)可以退出.这意味着我们作为非会话组长，永远无法重新获得控制终端.
4. chdir("/") 以确保我们的进程不会保留任何目录在使用中.不这样做可能会使管理员无法卸载文件系统，因为它是我们的当前目录.[等效地，我们可以更改到任何包含对守护程序操作很重要的文件的目录.]
5. umask(0) 以便我们可以完全控制我们编写的任何内容的权限.我们不知道我们可能继承了什么 umask.[这一步是可选的]
6. close() fds 0、1 和 2.这释放了我们从父进程继承的标准输入、输出和错误.我们无法知道这些 fd 可能被重定向到哪里.请注意，许多守护进程使用 sysconf() 来确定限制 _SC_OPEN_MAX._SC_OPEN_MAX 告诉您最大打开文件/进程.然后在一个循环中，守护进程可以关闭所有可能的文件描述符.您必须决定是否需要这样做.如果您认为可能有文件描述符打开，您应该关闭它们，因为并发文件描述符的数量是有限制的.
7. 为标准输入、标准输出和标准错误建立新的开放描述符.即使您不打算使用它们，将它们打开仍然是一个好主意.对这些的精确处理是一个品味问题；例如，如果您有一个日志文件，您可能希望将其作为 stdout 或 stderr 打开，并将/dev/null"作为 stdin 打开；或者，您可以将/dev/console"作为标准错误和/或标准输出打开，将/dev/null"作为标准输入打开，或任何其他对您的特定守护程序有意义的组合.

更好的是，只需调用 daemon() 函数(如果可用).>

I am writing a Linux daemon . I found two ways to do it.

1. Daemonize your process by calling fork() and setting sid.
2. Running your program with &.

Which is the right way to do it?

解决方案

From http://www.steve.org.uk/Reference/Unix/faq_2.html#SEC16

Here are the steps to become a daemon:

1. fork() so the parent can exit, this returns control to the command line or shell invoking your program. This step is required so that the new process is guaranteed not to be a process group leader. The next step, setsid(), fails if you're a process group leader.
2. setsid() to become a process group and session group leader. Since a controlling terminal is associated with a session, and this new session has not yet acquired a controlling terminal our process now has no controlling terminal, which is a Good Thing for daemons.
3. fork() again so the parent, (the session group leader), can exit. This means that we, as a non-session group leader, can never regain a controlling terminal.
4. chdir("/") to ensure that our process doesn't keep any directory in use. Failure to do this could make it so that an administrator couldn't unmount a filesystem, because it was our current directory. [Equivalently, we could change to any directory containing files important to the daemon's operation.]
5. umask(0) so that we have complete control over the permissions of anything we write. We don't know what umask we may have inherited. [This step is optional]
6. close() fds 0, 1, and 2. This releases the standard in, out, and error we inherited from our parent process. We have no way of knowing where these fds might have been redirected to. Note that many daemons use sysconf() to determine the limit _SC_OPEN_MAX. _SC_OPEN_MAX tells you the maximun open files/process. Then in a loop, the daemon can close all possible file descriptors. You have to decide if you need to do this or not. If you think that there might be file-descriptors open you should close them, since there's a limit on number of concurrent file descriptors.
7. Establish new open descriptors for stdin, stdout and stderr. Even if you don't plan to use them, it is still a good idea to have them open. The precise handling of these is a matter of taste; if you have a logfile, for example, you might wish to open it as stdout or stderr, and open '/dev/null' as stdin; alternatively, you could open '/dev/console' as stderr and/or stdout, and '/dev/null' as stdin, or any other combination that makes sense for your particular daemon.

Better yet, just call the daemon() function if it's available.

这篇关于Linux 守护进程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！