守护进程和正常进程之间的行为差异是什么？答案

【问题标题】：What are the behavioral differences between a daemon and a normal process?守护进程和正常进程之间的行为差异是什么？
【发布时间】：2011-04-06 11:38:42
【问题描述】：

我知道守护进程主要在后台运行，即它们需要的用户交互非常少。

Wikipedia lists一些常见的守护进程类型：

与控制终端分离
成为会议负责人
成为流程组组长
通过分叉和退出（一次或两次）留在后台。有时，该过程需要成为会话负责人。它还允许父进程继续其正常执行。这个成语有时可以用“fork off and die”来概括
将根目录 ("/") 设置为当前工作目录，这样进程就不会保留任何正在使用的目录，这些目录可能位于已挂载的文件系统上（允许将其卸载）。
将 umask 更改为 0 以允许 open()、creat() 等。调用以提供自己的权限掩码，而不依赖于调用者的 umask
在执行时关闭所有被父进程打开的继承打开文件，包括文件描述符 0、1 和 2（stdin、stdout、stderr）。稍后会打开所需的文件。
使用日志文件、控制台或 /dev/null 作为标准输入、标准输出和标准错误

我想知道除了我在第一行中提到的那个之外，守护进程的行为与正常进程是否存在差异。两种流程都各司其职，并根据用户完成工作所需的交互量与用户进行交互。

还有比这更多的守护进程吗？

【问题讨论】：

【解决方案1】：

不是真的。守护进程只是一个持续运行的进程的术语，通常不连接到终端。

守护进程不是一个单独的进程类，它们没有特殊的特权或属性。

有一个名为 daemon (man page) 的 BSD/Linux C 函数，但这只是将进程与其终端分离的一种简单方法。之所以如此命名，是因为这是守护进程通常会做的事情，而不是相反。

【讨论】：

所以如果我从像$ process & 这样的shell 执行一个进程，它是否有资格作为一个守护进程？
我会说不——这只是一个后台进程。它仍然与您的终端相关联，即使它的输出被暂时抑制，并且如果程序无限期运行，它很可能是在考虑到交互性的情况下编写的。守护进程会自动从它启动的终端中分离出来，并在编写时期望非交互性。
“与终端关联”是否意味着 stdin/stdout/stderr 描述符在进程中处于打开状态并可用？我认为，这些描述符也是“保留的”（按其目的）并且可供守护进程使用，对吗？换句话说，如果我从守护进程 printf() 会发生什么？因此，如果从守护进程进行 printf-ing 时没有发生任何错误（除了没有人看到输出），它似乎是区分进程和守护进程的弱标准。另外，是否可以将任何守护进程作为正常进程启动？

【解决方案2】：

进程和守护进程的主要区别在于守护进程的父进程是init em> - 在*Nix 引导期间启动的第一个进程。这就是为什么 Daemon 没有连接到终端的原因。因此，当您关闭终端时，它不会被操作系统杀死。但您仍然可以向您的守护进程发送信号。

【讨论】：

【解决方案3】：

这个问题有点模糊，但我还是会尝试：

从技术上讲，守护进程和其他进程一样。它们通常（但不是必须）关闭杂项文件描述符和其他适合长期存在的进程的行为。要深入了解大多数守护进程是如何设置的（在 Python 中），请查看： http://www.noah.org/wiki/Daemonize_Python

因此，差异真正归结为生命周期和用户。守护进程存在很长时间，通常与给定的运行级别一样长。它们通常还为其他系统范围的进程或高于普通用户运行进程的进程提供服务。

【讨论】：