Linux守护进程完全解析：从进程组织到setsid与systemd实践

1. 进程间关系：不只是父子这么简单

1.1 从PID到进程组：一次登录背后的进程组织方式

Linux里每一个进程都有一个PID，这是最基础的身份标识。但真正把进程组织起来的，并不仅仅是PID，而是进程组、会话和终端这三层结构。很多人在学习进程管理时只盯着PID和父进程PPID，导致后面理解守护进程时总是隔着一层纱。

我们用一个最常见的场景来拆解。你在终端里敲下一条命令，Shell接收到这个命令之后，会基于当前Shell进程创建一个子进程去执行它。这个子进程以及它后续再创建的所有子进程，会被分配到一个进程组里。进程组有一个领头进程，就是进程组ID（PGID）等于该进程PID的那个进程。进程组存在的意义在于，可以把一组相关的进程作为一个整体来统一控制，比如把信号一次性发给这一组进程。

再往上，一个或多个进程组构成了一个会话（Session）。会话通常对应一次用户登录，比如你通过SSH登录到服务器，SSH服务会为你创建一个会话，这个会话里至少有一个会话领头进程，通常是你的登录Shell。会话的意义更加重大，因为它把终端（TTY）和这些进程绑定在了一起。你的Shell、你在Shell里启动的前台命令和后台任务，都归属于同一个会话。

这里有一个非常关键的机制：前台进程组和后台进程组。一个会话里可以有很多个进程组，但同时只有一个进程组能够成为前台进程组，它独占终端输入，终端产生的键盘中断信号（比如Ctrl+C）只会发给当前的前台进程组。其他进程组都是后台进程组，它们不能读取终端输入。

我经常用一个比方来帮助理解，把会话当成一个公司，进程组是各个部门，终端是公司的大门。一个人（用户）登录进来，成立了一个公司（会话），公司里有多个部门（进程组），但同一个时间只有主办公区的人能跟前台（终端）直接对话。这种层层嵌套的结构，是Linux进程组织的基础，也是理解守护进程为什么必须脱离终端的前提。

1.2 控制终端和控制终端消失之后的连锁反应

控制终端这个名词值得多说两句。会话领头进程第一次打开一个终端设备（比如/dev/tty1或者伪终端pts/0），这个终端就成为了该会话的控制终端。控制终端是整个会话的信号中枢，很多关键信号都是通过控制终端触发的。

比如你按下Ctrl+C，内核会向前台进程组的所有进程发送SIGINT信号。按下Ctrl+Z会发送SIGTSTP，把前台进程组挂起。如果终端检测到连接断开（比如SSH会话意外断开），内核会向会话内的所有进程发送挂断信号SIGHUP。

这里就引出了进程间关系和守护进程之间最重要的连接点。当一个进程需要变成守护进程时，核心目标之一就是彻底摆脱控制终端的影响。因为如果进程还挂在某个终端会话下，那么这个终端一旦关闭、断连或重启，进程就有很大概率收到SIGHUP信号，默认动作是终止进程。这也是很多服务程序刚开始写的时候没有做守护化处理，一关终端进程就死掉的根本原因。

另外还有一个容易被忽略的机制：孤儿进程组。当一个进程组的领头进程退出，而组内还有其他进程没有结束时，这个进程组就会变成孤儿进程组。这时内核会在进程组内产生一个新的领头进程，一般是组内最靠近祖先的那个进程，并且每次这个孤儿进程组里有一个进程停止（比如收到SIGTSTP），内核就会向整个孤儿进程组发送SIGHUP和SIGCONT，强制通知它们没有控制终端了，别再依赖终端相关操作了。理解这一层，才能真正明白守护进程为什么要调用setsid创建新的会话，而不是仅仅fork一个子进程再让父进程退出那么简单。

2. 守护进程的本质特征与设计原则

2.1 守护进程到底是什么：后台、独立、长命

守护进程（Daemon）是Linux系统中一类特殊的进程。它们在系统启动时被拉起，在后台静默运行，不占用终端，不与用户直接交互，生命周期通常横跨整个系统运行时间。你日常接触的sshd、crond、nginx、docker，本质上都是守护进程。

但很多人对守护进程的第一个误解就是守护进程等于后台运行。在Shell里用一个&符号把命令丢到后台去，这不叫守护进程，它只是换到了当前会话里的后台进程组，本质上仍然挂在终端下面，终端关闭时还是可能收到SIGHUP，因为Shell退出时会向当前会话中的任务发送SIGHUP信号。守护进程和后台任务最核心的差别，在于是否独立于终端和会话存在。

守护进程一般具备以下几个特征：

• 是一个独立会话的领头进程，没有控制终端。
• 通常在系统启动阶段启动，或者由systemd等进程管理器拉起。
• 绝大部分时间处于阻塞或监听状态，资源占用平稳。
• 工作目录和文件描述符都与终端无关。
• 有明确的生命周期管理方式，比如PID文件、systemd单位文件。

举个例子，你通过SSH登录机器，手动执行了./app &，这个时候Shell返回提示符，看起来进程是在后台跑的。但如果你直接关闭SSH连接，再登录进去用ps -ef看一下，很多时候会发现这个进程已经不存在了。原因就是SSH断开时，会话收到了SIGHUP，Shell退出时又把这组进程一并带着结束了。而真正的守护进程，即使你从头到尾都不知道它的存在，它也能一直安稳地运行，因为它早已脱离了会话和终端的控制范围。

2.2 守护化要解决的关键问题清单

把一个普通进程变成守护进程，本质上是要解决四个问题：作业不受终端控制信号影响、不阻断文件系统卸载、不污染终端输出、以及避免进程被意外拉起后残留多个实例。

逐个说。第一个问题，脱离控制终端，是为了避免收到SIGHUP、SIGINT等终端相关信号。第二个问题，把当前工作目录切换到根目录或者其他固定目录，是为了防止进程占用某个挂载点导致umount时提示资源忙。第三个问题，标准输入输出和错误输出需要重定向到/dev/null或日志文件，否则进程往终端上打印内容，既不可控也可能把终端搞乱。第四个问题，多个实例同时运行往往会产生资源竞争，比如同时监听同一个端口，所以守护进程通常需要配合PID文件或systemd来保证单实例运行。

这四个问题不是互相独立的，它们之间有严格的先后关系。你不可能先把文件描述符重定向之后再去创建新会话，因为创建新会话需要进程不是进程组领头进程，而这一步又和fork操作的时机密切相关。这也是为什么标准守护进程的创建步骤有一个经典顺序，一步都不能乱。初学者最容易踩的坑就是认为守护化只是加个daemon函数就行，实际上每一行代码的顺序和位置都决定了守护进程最终是否可靠。

3. 经典守护进程创建步骤逐层拆解

3.1 第一步为什么要fork两次：会话领头的微妙规则

经典的守护进程创建流程长这样：

1. 调用fork，父进程退出。
2. 子进程调用setsid，创建新会话。
3. 再次fork，父进程（即第一次fork出来的子进程）退出，保留第二次fork产生的子进程。
4. 修改文件权限掩码umask。
5. 将当前工作目录chdir到/或其他稳定目录。
6. 关闭不需要的文件描述符，将标准输入、标准输出、标准错误重定向到/dev/null或日志文件。
7. 执行真正的业务逻辑。

我第一次接触这个流程时，最大的疑问就是为什么fork了还要再fork一次。单纯调用setsid之后，当前进程已经是新会话的领头进程了，已经没有了控制终端，那再来一次fork的目的是什么？

关键原因在于会话领头进程有一个特权：它可以重新获得控制终端。某些场景下，如果一个进程是会话领头进程，它后续如果主动打开一个终端设备，内核可能会把它设置为该终端的新控制终端。这显然违背了守护进程永远不跟终端扯上关系的初衷。第二次fork之后，子进程不再是会话领头进程，因此它永远无法获取控制终端，彻底断绝了将来意外和终端关联的可能性。

不过这里要说明一下，在实际开发中，是否二次fork取决于具体场景。某些现代守护进程实现并不需要二次fork，因为systemd里Type=simple的进程本来就不要求进程主动做守护化操作，交给systemd管理就好。但在纯手工实现守护进程、或者需要兼容SysV init风格启动方式的场景里，完整的双fork流程依然是最稳妥的经典方案。

3.2 setsid到底做了什么：一个新会话的诞生

setsid是Linux中让进程彻底独立的关键系统调用。它的行为可以概括为一句话：调用进程必须不是进程组领头进程，然后它会创建一个新的会话，调用进程成为新会话的领头进程。

具体的效果有以下几点。这个进程成为新会话的领头进程，进程ID等于新会话的ID。这个进程成为新进程组的领头进程，进程ID等于新进程组的ID。这个进程没有控制终端，之前如果有控制终端，也会被切断。

那怎么保证调用进程不是进程组领头进程？答案就是第一次fork。fork之前进程是父进程所在进程组的成员，fork之后子进程的PID是新值，而进程组ID仍然是父进程的PGID。因为PGID等于父进程PID，而子进程PID是新的，所以子进程的PID不等于自身的PGID，因此不是进程组领头进程。这保证了setsid调用一定会成功。

setsid成功之后，新会话里只有一个进程，这个进程既是会话领头进程，也是进程组领头进程。它不关联任何终端，和原来的Shell、终端的联系在这里被彻底切断。从这里开始，这个进程才算真正迈入了守护进程的领域。

3.3 umask、chdir和文件描述符重定向的操作逻辑

说完fork和setsid，剩下的三步虽然看起来简单，但在实际运维中踩坑率极高。

umask操作：调用umask(0)把文件权限掩码清空。为什么？因为守护进程后续可能会创建文件，比如日志文件、数据文件，而继承来的umask可能导致文件权限过紧或者不可预测。比如原本Shell里的umask是022，那么创建出来的文件默认权限就是644；如果umask是027，文件就是640。对守护进程来说，它不一定知道调用者原来设置过什么umask，所以最稳妥的做法是清零，让后续open、creat调用显式指定权限，避免继承带来的不确定性。

chdir操作：把工作目录切换到根目录。这一步的目的我在前面提过，是为了不占用文件系统挂载点。试想一个进程的工作目录在一个普通用户家目录下，如果系统管理员要umount这个家目录对应的分区，内核会返回EBUSY，原因就是有进程还停留在这个挂载点的目录上。切换到根目录之后，守护进程不会因为工作目录的原因导致文件系统卸载失败。

文件描述符重定向：标准做法是把0、1、2全部重定向到/dev/null，或者日志文件。为什么要连/dev/null都算重定向？因为有些程序库会隐式往stdout打印内容，如果不重定向，守护进程的stdout可能是指向终端设备或者某个已经关闭的文件描述符，一旦往里面写入数据就有可能导致EBADF错误或者产生意外的终端输出。把三个标准流都指向一个确定的目标，是守护进程最基本的洁癖要求。

这里我补充一句，很多老代码喜欢把stdin指向/dev/null，stdout和stderr指向一个日志文件。但在简单场景里三者全部指向/dev/null也没问题，具体日志可以通过后续的日志库或syslog机制输出，不必拘泥于标准错误流。

4. 从零实现一个守护进程：完整代码与细节校验

4.1 一个可直接参考的C语言实现

空谈理论没有意义，这里给出一份完整的C语言守护进程模板，可以当作以后写服务程序的基础骨架。代码遵循前面说的经典流程，并且做了一些边界处理。

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <signal.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <string.h> void daemonize() { pid_t pid; int fd; // 第一次fork，让父进程退出，保证子进程不是进程组领头进程 pid = fork(); if (pid < 0) exit(1); if (pid > 0) exit(0); // 子进程创建新会话 if (setsid() < 0) exit(1); // 第二次fork，确保进程永远不会重新获得控制终端 pid = fork(); if (pid < 0) exit(1); if (pid > 0) exit(0); // 清空文件权限掩码 umask(0); // 切换工作目录到根目录 if (chdir("/") < 0) exit(1); // 关闭所有继承下来的文件描述符 for (int i = 0; i < sysconf(_SC_OPEN_MAX); i++) close(i); // 将标准输入、输出、错误重定向到/dev/null fd = open("/dev/null", O_RDWR); if (fd >= 0) { dup2(fd, STDIN_FILENO); dup2(fd, STDOUT_FILENO); dup2(fd, STDERR_FILENO); if (fd > STDERR_FILENO) close(fd); } } int main() { daemonize(); // 模拟守护进程的核心工作：循环执行一个任务 while (1) { // 实际业务逻辑在这里 sleep(10); } return 0; }

这段代码看起来非常简单，但有几个细节值得单独拿出来讲。

第一个细节是close所有文件描述符这个循环。我见过不少简化版本只关闭0、1、2或者干脆跳过这步，这在绝大多数时候没问题，但不够严谨。因为父进程可能通过execve传入了某些随机合法的文件描述符，比如一些框架或Shell会额外打开fd 3、fd 4。守护进程如果继承它们，可能导致socket文件、配置文件被意外占用无法释放。用sysconf(_SC_OPEN_MAX)拿到上限，一次性全部关闭，是在不知道父进程到底遗留下来什么的最好策略。

第二个细节是dup2的用法。先open /dev/null拿到的fd可能不是0、1、2中的任何一个，然后通过dup2把这同一个fd复制到标准输入输出错误三个位置。复制完成后要判断一下fd是否大于2，如果是就关闭原始fd，避免多余的文件描述符残留。

第三个细节是fork失败的边界处理。如果你要写一个严谨的服务程序，fork失败时不能只是exit，最好记录一条错误日志再退出。对于生产级程序，还应该考虑如果调用daemonize时进程已经是守护进程的情况，不过这种场景通常极少出现，更多还是交给systemd管理。

4.2 编译运行和实测验证

把上述代码保存为demo_daemon.c，编译并运行观察它的表现。

gcc demo_daemon.c -o demo_daemon ./demo_daemon

命令执行后，终端会立即返回命令行提示符，看起来像什么都没发生一样。这时用ps命令查看进程状态。

ps -eo pid,ppid,pgid,sid,tty,stat,cmd | grep demo_daemon

正常情况下输出类似下面这样：

12345 1 12345 12345 ? Ss ./demo_daemon

观察几个重要字段。PPID是1，说明它的父进程已经退出，被init进程领养。PGID等于它自己的PID，SID也等于它自己的PID，说明它既是进程组领头进程，又是会话领头进程。TTY字段是问号，说明没有控制终端。STAT字段中的s表示它是会话领头进程。

这五个条件同时满足，才是一个标准的守护进程。如果跑完代码发现PPID不是1、SID有值但来自别的进程，或者TTY不是问号，那说明某个步骤出了问题，最可能的原因有两个：要么fork之后父进程没有正确退出，要么setsid调用失败。

我这里再强调一次，只要父进程正常退出了，子进程就会被系统PID 1领养，PPID变成1。如果发现PPID不是1，先确认你的代码里有没有加exit(0)，优先级再确认是不是因为父进程挂起在什么地方没有及时退出。

5. 守护进程的信号处理与生命周期管理

5.1 收到SIGHUP后的优雅退出策略

守护进程没有控制终端，按理说不会收到SIGHUP。但SIGHUP还有另一个来源，就是进程的父进程退出时，在某些条件下内核会向子进程发送SIGHUP。另外，systemd在reload或者stop服务时也会向进程发送SIGHUP，具体行为取决于Unit配置。所以守护进程不能对SIGHUP掉以轻心。

实际开发中一个常见的做法是，把SIGHUP作为重新加载配置文件的信号。比如nginx就是用SIGHUP来优雅重新加载配置。对于自己写的守护进程，可以考虑这样一个信号处理方案。

#include <signal.h> #include <stdio.h> #include <unistd.h> static volatile sig_atomic_t g_reload = 0; static volatile sig_atomic_t g_stop = 0; void handle_signal(int sig) { if (sig == SIGHUP) { g_reload = 1; } else if (sig == SIGTERM || sig == SIGINT) { g_stop = 1; } } int main() { daemonize(); signal(SIGCHLD, SIG_IGN); signal(SIGHUP, handle_signal); signal(SIGTERM, handle_signal); signal(SIGINT, handle_signal); while (!g_stop) { if (g_reload) { // 重新读取配置文件 g_reload = 0; } // 正常业务逻辑 sleep(10); } // 退出前完成清理工作 return 0; }

关于POSIX信号处理有几个禁忌一定要记住。不要在信号处理函数里调用printf、malloc、fprintf这类不是异步信号安全函数。信号处理函数里最安全的行为是修改一个volatile sig_atomic_t变量，然后在主循环里检测这个变量。上面代码就是这么做的，信号处理函数只负责置位标志位，真正的工作在主循环中完成。

另外，SIGCHLD信号的处理也值得一提。如果守护进程会创建子进程，需要在初始化阶段设置SIGCHLD为SIG_IGN，避免子进程退出后变成僵尸进程。如果子进程退出时父进程没有wait，僵尸进程会一直占据进程表项，积累多了会影响系统运行。

5.2 PID文件：为什么守护进程需要它

守护进程必须支持单实例运行，否则多个实例同时监听同一个端口、操作同一个数据文件，很容易造成数据损坏或者服务错乱。PID文件就是最经典的单实例控制手段。

实现思路不复杂。守护进程启动时，先检查指定路径下是否存在PID文件。如果不存在，把自己当前的PID写入文件。如果存在，读取文件到PID，然后向这个PID发送信号0来探测进程是否存在。kill(pid, 0)不会真的发送信号，但能检查目标进程是否存在以及是否有权限发送信号。

如果进程存在，说明已经有一个实例在运行，当前进程直接退出。如果进程不存在，说明PID文件是残留的僵尸文件，可以安全覆盖。这里有一个细节必须注意：检查PID和写入PID之间不是原子的，也就是说存在竞态条件，两个进程同时启动时可能都认为对方不存在，然后同时写入PID文件。生产级程序应该考虑用文件锁来解决。

经典的方案是先open PID文件，然后调用flock加排他锁。如果加锁失败说明其他实例已经持有锁。加锁成功后，再truncate并写入自己的PID。这样即使两个实例同时启动，也只有拿到文件锁的进程能继续运行。如果一个实例异常崩溃，操作系统会自动释放文件锁，其他实例就能正常接管。

5.3 systemd时代守护进程的新姿势

虽然手工写daemonize的过程很经典，但现在Linux服务器基本都用systemd来管理服务，情况已经发生了变化。systemd希望进程以前台方式运行，由systemd自身负责守护化。如果你的程序已经写好了daemonize逻辑，在systemd里反而可能出问题，因为它会让systemd认为进程已经退出，从而产生类型判断上的混乱。

现代推荐做法是写一个systemd Unit文件来管理守护进程。把Type设置成simple，ExecStart直接指向你的程序二进制，由systemd负责拉起、监控、崩溃重启、日志收集。

[Unit] Description=Demo Daemon Service After=network.target [Service] Type=simple ExecStart=/opt/demo/demo_daemon Restart=on-failure User=daemon Group=daemon UMask=0027 [Install] WantedBy=multi-user.target

使用systemd管理模式之后，程序本身就不需要再调用fork和setsid了，只要以前台方式运行，标准输出直接打到journald里就行。systemd会把进程放到独立cgroup里管理，崩溃自动重启，开机自动启动，比手工PID文件加/etc/rc.local的年代可靠得多。

不过有一个兼容性问题值得注意：如果你写的是通用程序，既想被systemd管理，又能在老系统上手动启动，就必须加一个参数控制是否执行daemonize逻辑。比如用--daemon参数开启传统守护化，不用则前台运行。这种兼容设计能让同一个二进制同时适配新旧两套体系。

6. 常见问题与排查技巧实录

6.1 终端关闭进程就消失的深挖过程

很多人第一次写守护进程时都会遇到一个现象：程序明明已经调用了一堆初始化代码，关掉终端后进程还是死了。我帮别人排查过类似问题不下十次，每次排查路径都差不多，这里分享一下。

第一反应是用ps验证进程状态。如果进程的TTY列还是pts/0之类的值，说明进程根本没有脱离终端。再看PGID和SID，如果SID不是自己创建的，说明setsid没有生效。大概率是fork之后父进程没退出，子进程还留在原来的进程组里，setsid返回了EPERM失败。

还有一种情况是代码里先做了工作目录切换、文件重定向，然后才执行setsid。顺序反了，setsid虽然也能成功，但因为文件描述符、目录等资源都是继承来的，可能仍然持有终端相关的引用。不要小看这一点，标准流程的顺序是无数次实践踩坑得出的最优解，改顺序之前先想清楚理由。

6.2 僵尸进程和孤儿进程在处理子任务时怎么规避

守护进程一旦开始处理并发任务，就很容易引出僵尸进程问题。僵尸进程不是真正死掉的进程，而是子进程已经退出，但父进程尚未调用wait收集退出状态，导致进程表项无法释放。

规避方法有两种。一种是对SIGCHLD设置SIG_IGN，表示对子进程退出状态不感兴趣，由内核自动回收。另一种是使用sigaction配合SA_NOCLDWAIT标志，效果一致。这种方式适合不关心子进程退出码的场景。

如果子进程的退出结果很重要，就不能简单忽略SIGCHLD，需要在信号处理函数里调用waitpid。但问题来了，信号处理函数里调用waitpid是安全操作吗？答案是，waitpid属于异步信号安全函数，可以在信号处理函数里调用。但要注意一个边角情况：信号处理函数理论上可能被其他信号中断，waitpid也有可能出现EINTR错误，需要判断errno并重试。

还有一个简单的做法，主循环里定一个时间点统一收割所有子进程。配合WNOHANG选项，waitpid不会阻塞主循环，在循环里按周期轮询即可。这种方案逻辑最直观，出错的概率也最小。

6.3 如何准确判断一个进程是不是真的守护进程

很多资浅工程师判断守护进程只看两点：后台运行、没有终端输出。但实际上真正专业的判断标准应该是这几个特征同时成立。

使用ps -eo pid,ppid,pgid,sid,tty,stat,cmd，对照以下表格逐项核对，任何一项不满足都说明进程并未真正守护化。

这里顺手补充一个查看技巧。如果想确认某个守护进程没有意外持有终端文件描述符，直接看进程的fd目录。

ls -l /proc/12345/fd/0 ls -l /proc/12345/fd/1 ls -l /proc/12345/fd/2

如果是标准的守护进程，这三个输出都应该指向/dev/null，或者指向你重定向的日志文件。如果看到它们指向某个pts设备，那说明程序守护化不彻底。

再补充一个极端情况：如果程序在守护化之前就已经打开了一个终端设备文件，那么即使setsid之后，进程依然持有这个文件描述符，终端设备可能退不完全。这也是我上面代码会在setsid之后统一close所有继承文件描述符的原因。

6.4 踩坑记录：守护进程总是退出却没有日志怎么办

守护进程因为脱离了终端，一旦运行中崩溃，你会立刻陷入什么信息都看不到的困境。这是新手最容易束手无策的情况。程序Crash信息本来会打在stderr上，可stderr已经被重定向到/dev/null，syslog里也没有任何记录，看起来就像程序莫名其妙消失了。

我的建议是，在开发调试阶段，千万不要把stderr直接指向/dev/null。一个更合适的做法是把stderr重定向到一个独立日志文件里，并且确认所有关键路径上都有日志输出。比如main函数入口打印一行，daemonize完成后打印一行，每次信号处理触发时也打印一行。这样可以快速定位问题发生在哪个阶段。

另一个实用技巧是临时在前台模式运行。很多守护程序都支持一个命令行参数让程序以前台方式运行，这在调试时特别方便。如果一个程序不支持，可以临时注释掉daemonize调用，直接在终端里跑，配合gdb定位崩溃点。定位完再把代码恢复回去。

还有一点需要知道，如果进程是被OOM Killer杀掉的，不会留下任何崩溃痕迹。排查方向可以看看内核日志，dmesg或者journalctl -k的输出中，是否有Out of memory相关记录。OOM Killer会优先杀掉占用内存最多的进程，如果守护进程的内存模型不健康，比如日志没做轮转导致内存无限增长，就很容易成为OOM Killer的目标。

7. 实操进阶：一个更贴近生产的守护进程示例

7.1 加入定时任务和日志轮转的迷你守护进程

基础demo能验证守护进程机制，但距离可用还有一段距离。实际生产环境中，守护进程往往有业务逻辑、日志输出、配置重载、干净退出这些需求。这里给出一个稍完整的参考实现，把前面讲的知识点串起来。

这个示例实现一个简单功能：每隔一段时间获取一次系统负载，写入日志文件，支持通过SIGHUP重新打开日志文件，支持通过SIGTERM优雅退出。

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <signal.h> #include <fcntl.h> #include <sys/stat.h> #include <sys/types.h> #include <time.h> static volatile sig_atomic_t g_stop = 0; static volatile sig_atomic_t g_reopen = 0; static int log_fd = -1; void handle_signal(int sig) { if (sig == SIGTERM) { g_stop = 1; } else if (sig == SIGHUP) { g_reopen = 1; } } void daemonize() { pid_t pid; int fd; pid = fork(); if (pid < 0) exit(1); if (pid > 0) exit(0); if (setsid() < 0) exit(1); pid = fork(); if (pid < 0) exit(1); if (pid > 0) exit(0); umask(0); if (chdir("/") < 0) exit(1); for (int i = 0; i < sysconf(_SC_OPEN_MAX); i++) close(i); fd = open("/dev/null", O_RDWR); if (fd >= 0) { dup2(fd, STDIN_FILENO); dup2(fd, STDOUT_FILENO); dup2(fd, STDERR_FILENO); } } void write_log(const char *msg) { if (log_fd < 0) return; char buf[512]; time_t t = time(NULL); struct tm *tm_info = localtime(&t); int len = strftime(buf, sizeof(buf), "[%Y-%m-%d %H:%M:%S] ", tm_info); strncat(buf, msg, sizeof(buf) - len - 1); strncat(buf, "\n", sizeof(buf) - strlen(buf) - 1); write(log_fd, buf, strlen(buf)); } int main() { daemonize(); signal(SIGTERM, handle_signal); signal(SIGHUP, handle_signal); signal(SIGCHLD, SIG_IGN); log_fd = open("/var/log/load_monitor.log", O_WRONLY | O_CREAT | O_APPEND, 0644); if (log_fd < 0) exit(1); write_log("load monitor started"); while (!g_stop) { if (g_reopen) { // 重新打开日志文件，用于logrotate场景 close(log_fd); log_fd = open("/var/log/load_monitor.log", O_WRONLY | O_CREAT | O_APPEND, 0644); if (log_fd < 0) log_fd = -1; g_reopen = 0; write_log("log file reopened"); } // 获取load average double loadavg[3] = {0}; if (getloadavg(loadavg, 3) >= 1) { char msg[64]; snprintf(msg, sizeof(msg), "load: %.2f %.2f %.2f", loadavg[0], loadavg[1], loadavg[2]); write_log(msg); } sleep(10); } write_log("load monitor stopped"); close(log_fd); return 0; }

这个代码里用到了getloadavg函数，这是POSIX标准定义的接口，用于获取系统最近1分钟、5分钟、15分钟的平均负载。整个逻辑不复杂，但已经能够体现守护进程常见的几个需求。

7.2 配合logrotate处理日志增长的套路

守护进程长时间运行，日志文件不断增长，最终磁盘满是最常见的运维事故之一。logrotate就是用来解决日志轮转问题的标准工具，只要配置得当，守护进程完全不需要自己关心文件大小。

但logrotate有一个细节要注意：默认的logrotate操作是先rename旧日志文件，再创建一个新的日志文件。如果守护进程始终持有旧文件的文件描述符，rename之后进程还会继续往旧文件里写数据，而这个旧文件已经被移动走改了名，日志就写到别的文件里去了。

解决思路有两种。一种是logrotate配置里加上copytruncate选项，复制原文件后清空原文件，这样守护进程持有的文件描述符依然指向原来的路径，不需要任何额外处理。另一种是使用create选项配合守护进程的SIGHUP处理，在logrotate的postrotate脚本里向守护进程发送SIGHUP信号，让进程重新打开日志文件。我上面的示例代码里就实现了对SIGHUP的响应，目的正是配合第二种方案。

logrotate配置可以写成这样。

/var/log/load_monitor.log { daily rotate 7 compress delaycompress missingok notifempty postrotate /bin/kill -HUP $(cat /var/run/load_monitor.pid) endscript }

前提是程序启动时把自己的PID写到了/var/run/load_monitor.pid，否则postrotate脚本不知道该向谁发信号。写PID文件的逻辑前面说过，用PID文件加flock保证单实例，再把PID写入文件。这样外部脚本就能通过读PID文件来管理守护进程。

7.3 守护进程的资源限制与系统兼容技巧

守护进程作为长驻进程，资源管理比普通命令行程序要严格得多。一个最常见的隐患是文件描述符泄漏。写日志打开一个fd、读配置打开一个fd，如果代码路径里存在某个分支忘了关闭，时间一长fd就会耗尽。排查文件描述符泄漏的办法很直接，周期性观察/proc/PID/fd目录下的数量，如果数量单调增长，几乎可以肯定有泄漏。

另一个容易踩的坑是socket放在临界区里处理不当。守护进程作为网络服务时，accept返回的连接必须在每个子进程或者线程中独立管理，不能在父子进程间共用同一个已连接socket，否则close之后信号交互会非常混乱，甚至出现双方都对同一socket执行close导致重置连接的情况。经典做法是用SO_REUSEPORT或多进程模型让每个进程独立accept，但这涉及更深的网络编程话题，在守护进程基础之上展开更合适。

从系统兼容角度考虑，纯daemonize方式编写的程序如果想适配不同发行版，最好把启动方式做成分层设计。在SysV init环境里，把PID文件写到/var/run/{name}.pid，同时也提供一个systemd Unit文件。这样不管是老系统还是新系统都能平滑使用。很多开源项目本质上也是这样设计的，只是他们把daemonize逻辑封装得更好。

8. 我的一点实践心得

守护进程这个话题，表面上讲的是进程创建的几个步骤，实际上考验的是对Linux进程模型的理解深度。我见过不少人能把daemonize流程背得滚瓜烂熟，一旦遇到进程被终端信号搞死、日志打不出来、或者多个实例打架的情况，还是会卡壳。原因就在于单独记步骤没意义，必须理解每个步骤在进程模型里到底改变了什么。

我自己在写守护进程时，一般会先画一个简单的状态表，列出进程在每一步之后的PID、PPID、PGID、SID、TTY分别是什么，确认每一步达到预期再写代码。这种朴素的验证习惯帮我躲过不少坑。

另外想特别强调一点，现代Linux环境下，能用systemd管理就直接让systemd管理，不要为了追求所谓的标准守护进程写法而主动daemonize。反过来，如果你在维护一个老项目，暂时不能迁移到systemd，那分清传统daemonize和PID文件管理还是必须掌握的基本功。时代在变，但底层机制不会消失，理解它们才能在不同环境里游刃有余。