4、守护进程的创建步骤：fork()脱离控制终端、setsid()创建新会话、二次fork()防止重新获取终端

守护进程（Daemon）是Linux系统中长期驻留后台、无控制终端、独立于会话运行的进程。其核心特征在于“脱离”：脱离控制终端、脱离进程组、脱离会话，从而避免因终端关闭、用户注销或信号干扰而终止。本章围绕经典的“两次fork + setsid”创建模型，深入剖析每一步的系统调用语义、进程状态变化以及背后的设计逻辑，帮助开发者从原理层面掌握守护进程的标准化创建流程。

4.1 核心原理：为什么需要两次fork与setsid

守护进程的创建本质上是进程环境隔离的过程。Linux进程的生存环境由三个层级构成：会话（Session）、进程组（Process Group）和控制终端（Controlling Terminal）。普通进程启动时，会继承父进程的会话ID、进程组ID以及控制终端。当用户注销或终端关闭时，内核会向会话首进程发送SIGHUP信号，进而影响整个会话内的所有进程组。守护进程要存活于系统后台，就必须彻底切断这种关联。

第一次fork的目的在于确保子进程不是会话首进程。因为setsid()调用有一个限制：如果调用进程是进程组组长，则调用失败。父进程通常是会话首进程或进程组组长，fork出的子进程继承了父进程的PGID，但子进程的PID不同于PGID，因此子进程不是进程组组长，setsid()可以成功执行。同时，父进程退出后，子进程成为孤儿进程，由init进程收养，避免了僵尸进程的产生。

setsid()是创建守护进程的核心系统调用。它完成三件事：创建一个新会话，调用进程成为会话首进程；创建一个新进程组，调用进程成为进程组组长；释放控制终端。这三者共同保证了进程与终端环境的完全隔离。但setsid()之后，进程成为会话首进程，存在一个隐患：如果该进程后续打开一个终端设备，该终端可能被自动设置为控制终端，导致进程重新被终端绑定。

第二次fork正是为了消除会话首进程身份。fork出的孙进程不再是会话首进程，因此即使它后续打开终端设备，也不会自动成为控制终端。这种“双保险”机制确保了守护进程在长期运行中不会因终端操作而意外中断。下表总结了各步骤的关键属性变化：

步骤	进程PID	进程组PGID	会话SID	控制终端	会话首进程
父进程	1000	1000	1000	/dev/tty1	是
第一次fork子进程	1001	1000	1000	/dev/tty1	否
setsid()后	1001	1001	1001	无	是
第二次fork孙进程	1002	1001	1001	无	否

4.2 操作流程：标准创建步骤与代码实现

守护进程的创建遵循一套固定的操作序列，每一步都有明确的系统调用和错误处理要求。以下是标准流程：

1. 调用umask(0)：清除文件模式创建掩码，确保守护进程创建的文件具有预期的权限位，不受父进程umask影响。
2. 调用fork()并让父进程退出：父进程调用exit()退出，子进程继续执行。此时子进程成为孤儿进程，由init收养。
3. 调用setsid()：创建新会话，子进程成为会话首进程和进程组组长，脱离控制终端。
4. 第二次调用fork()并让父进程退出：即setsid()后的进程再次fork，父进程（会话首进程）退出，孙进程继续运行。孙进程不是会话首进程，无法重新获取控制终端。
5. 将工作目录切换为根目录：调用chdir("/")，避免守护进程占用挂载点，防止文件系统无法卸载。
6. 关闭不需要的文件描述符：遍历并关闭所有打开的文件描述符，或至少关闭标准输入、输出、错误（0、1、2），防止资源泄漏。
7. 重定向标准I/O到/dev/null：将标准输入、输出、错误重定向到/dev/null，避免库函数或系统调用因读写终端而产生错误。

以下是一个标准的守护进程创建代码模板：

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <sys/types.h>

void daemonize() {
    pid_t pid;
    
    /* 1. 清除文件创建掩码 */
    umask(0);
    
    /* 2. 第一次fork，父进程退出 */
    pid = fork();
    if (pid < 0) {
        perror("fork");
        exit(EXIT_FAILURE);
    }
    if (pid > 0) {
        exit(EXIT_SUCCESS);
    }
    
    /* 3. 创建新会话 */
    if (setsid() < 0) {
        perror("setsid");
        exit(EXIT_FAILURE);
    }
    
    /* 4. 第二次fork，防止重新获取控制终端 */
    pid = fork();
    if (pid < 0) {
        perror("fork");
        exit(EXIT_FAILURE);
    }
    if (pid > 0) {
        exit(EXIT_SUCCESS);
    }
    
    /* 5. 切换工作目录 */
    if (chdir("/") < 0) {
        perror("chdir");
        exit(EXIT_FAILURE);
    }
    
    /* 6. 关闭所有打开的文件描述符 */
    int maxfd = sysconf(_SC_OPEN_MAX);
    for (int fd = 0; fd < maxfd; fd++) {
        close(fd);
    }
    
    /* 7. 重定向标准I/O到/dev/null */
    int fd = open("/dev/null", O_RDWR);
    if (fd >= 0) {
        dup2(fd, STDIN_FILENO);
        dup2(fd, STDOUT_FILENO);
        dup2(fd, STDERR_FILENO);
        if (fd > 2) close(fd);
    }
}

int main() {
    daemonize();
    /* 守护进程主体逻辑 */
    while (1) {
        sleep(1);
    }
    return 0;
}

4.3 案例拆解：一个日志采集守护进程的完整创建与验证

某物联网网关设备需要运行一个日志采集守护进程，负责从串口读取传感器数据并写入本地日志文件。设备环境为嵌入式Linux，系统启动后通过init脚本启动该守护进程。开发人员在调试过程中发现，进程在用户通过SSH登录时会被SIGHUP信号杀死，且日志文件权限异常。以下为完整的排查与解决过程。

初始现象与约束：守护进程由/etc/init.d/rcS脚本启动，启动后运行正常，但一旦用户通过SSH登录或退出终端，进程立即终止。日志文件由守护进程创建，权限为0640，但期望为0660。系统无systemd，使用BusyBox init。

分析判断过程：通过ps -ef查看进程状态，发现守护进程的PPID为1（init），但TTY列为?，说明没有控制终端。然而，进程的SID与SSH会话的SID相同，说明进程仍属于SSH会话。进一步检查代码，发现开发人员只调用了一次fork和setsid，但未进行第二次fork。由于setsid()后进程成为会话首进程，当SSH会话结束时，内核向该会话发送SIGHUP，守护进程因未处理SIGHUP而终止。

实际操作步骤：

1. 在代码中增加第二次fork，确保最终运行的进程不是会话首进程。
2. 在daemonize()函数开头调用umask(0)，并在创建日志文件时显式指定权限0660。
3. 将标准输出和错误重定向到日志文件而非/dev/null，便于调试。
4. 使用setsid()后检查返回值，若失败则记录错误日志并退出。

结果对比：修改后，通过SSH登录和退出均不再影响守护进程。日志文件权限正确为0660。使用ps -ef确认进程的SID与SSH会话不同，且TTY列为?。通过cat /proc/<pid>/status查看State字段，确认进程处于S（睡眠）状态，且无控制终端。

风险与代价：第二次fork后，守护进程的父进程退出，需要确保init正确收养孙进程，否则可能产生僵尸进程。此外，关闭所有文件描述符时，需注意不要误关已打开的日志文件描述符，应在重定向之后再进行日志文件的打开操作。

复盘经验：守护进程创建并非简单的代码模板套用，必须结合运行环境验证。在嵌入式系统中，init脚本的环境变量、文件系统挂载点、SIGHUP信号处理等都可能影响守护进程行为。建议在开发阶段增加详细的启动日志，记录每一步系统调用的返回值，便于快速定位问题。

4.4 常见误区与总结复盘

守护进程创建过程中，开发者常犯以下几类错误，需要特别注意：

• 忽略umask设置：父进程的umask可能限制文件权限，导致守护进程创建的文件权限不符合预期。应在创建任何文件之前调用umask(0)。
• 只做一次fork：如果只调用一次fork和setsid，进程成为会话首进程，后续打开终端设备时可能重新获取控制终端。必须进行第二次fork。
• 未处理setsid失败：如果调用进程是进程组组长，setsid()会失败。应检查返回值并处理错误，而不是盲目继续。
• 关闭文件描述符不彻底：仅关闭标准I/O是不够的，应遍历关闭所有可能继承的文件描述符，包括socket、定时器fd等。
• 工作目录未切换：如果守护进程的工作目录位于某个挂载点下，会导致该文件系统无法卸载。应切换到根目录或其他安全目录。
• 信号处理缺失：守护进程应至少处理SIGTERM和SIGHUP信号，实现优雅退出或配置重载。默认的SIGHUP行为是终止进程，容易造成数据丢失。

从系统设计角度看，守护进程的创建步骤体现了Linux进程模型的严谨性。每一步都是对进程环境的精确控制：fork创建新进程，setsid创建新会话，二次fork消除会话首进程身份。理解这些步骤背后的原理，比机械记忆代码模板更为重要。在实际项目中，建议将daemonize()封装为独立模块，并增加日志输出和错误处理，便于在不同平台上复用和调试。

守护进程的创建只是第一步，后续的日志管理、信号处理、单实例运行（如使用文件锁）、系统崩溃恢复等，都是生产级守护进程必须考虑的问题。建议开发者结合本章的创建流程，逐步完善守护进程的健壮性设计，确保其在各种异常场景下都能稳定运行。