很多人刚开始接触 Linux 下的进程控制时，最纠结的一个认知问题是："进程到底是个什么东西？" 是那个正在运行的程序吗？是那一串 ps 命令输出的列表吗？还是说，它其实就是代码在内存里跑起来的那个"活体"？我当时学的时候也绕了很久，直到被 fork 那个著名的"返回两次"折腾到彻底失眠，才真正把进程这层窗户纸捅破。

这篇文章我不会按教科书顺序给你念知识点，而是从实际编码和排查的角度，把"进程控制"这条线完整拆一遍：从进程的底层身份到 fork 的写时拷贝，从 exec 替换程序面孔到进程退出的完整走向，最后再看看守护进程这层进阶玩法。全文偏实战，每个环节都有代码、有原理、有我踩过的坑，适合刚学完 C 语言、想深入理解 Linux 编程，或者正在准备面试、需要系统梳理进程知识的朋友。

1. 进程的本质：不是程序，而是"运行中的上下文"

1.1 从一条命令的诞生看进程到底是什么

你在终端里敲一条./hello，按下回车，系统究竟做了哪些事？很多人以为是"把 hello 程序跑起来"，但这句话太笼统了。真实的过程是：shell 进程调用 fork 复制出一个几乎一模一样的子进程，然后这个子进程调用 exec 把 hello 程序的代码段、数据段加载进自己的地址空间，替换掉原来 shell 的代码，最后从入口点开始执行。

所以进程到底是什么？进程是程序的一次运行实例，它承载的不只是代码，还包括当前执行到哪一行（程序计数器）、变量存在哪里（地址空间）、打开了哪些文件（文件描述符表）、和内核交互的身份信息（uid/gid）、以及操作系统用来调度它的全部元数据（进程控制块 PCB）。

我用一个生活化的类比：程序就像一本菜谱，而进程是某个厨师照着这本菜谱做菜的全过程。菜谱是静态的、可以复印无数份，但做菜这个过程有"做到哪一步了"的进度、有灶台上正在用的锅碗瓢盆、有厨师个人习惯的切菜手法——这些动态的状态就是进程上下文。同一个可执行文件可以被同时运行 100 次，就有 100 个进程，它们的代码相同，但各自状态完全不同。

1.2 进程 ID：身份标识与父子血缘

每个进程在内核里都有一个唯一的进程 ID（PID），这是它区别于其他进程的身份证号。同时，每个进程还有父进程 ID（PPID），记录着"我是谁生出来的"。Linux 的进程树顶层是 systemd（在新系统里通常是它，传统系统里是 init），所有进程都是它的后代。

获取这两个 ID 的接口很简单：

#include <stdio.h> #include <unistd.h> int main() { printf("PID: %d\n", getpid()); printf("PPID: %d\n", getppid()); return 0; }

运行结果里那个 PPID 就是你的 shell 进程的 PID。这个父子关系不是摆设，它是进程控制里几乎所有操作的根基：父进程负责回收子进程的"尸体"，子进程被杀死后会通知父进程派"代表"来处理善后。相关系数贯穿 fork、wait 和信号机制，后面全都会用到。

1.3 去看看真实的内核数据结构：procfs

光说 PCB 太抽象，其实你随时可以打开 Linux 的/proc目录"触摸"到一个活的进程。每个 PID 对应/proc/PID一个子目录，里面有进程的全部家当：

ls /proc/1/ cat /proc/1/status | head -20

/proc/1/status里面会显示 Name、State、Pid、PPid、Umask、Capabilities 等信息。/proc/1234/maps能看这个进程的虚拟内存布局，/proc/1234/fd/能看到它打开的所有文件描述符。

我强烈建议你写程序的时候偶尔去/proc翻一翻，因为很多进程疑难杂症——比如文件打不开、内存暴涨、僵尸进程——都能从这里找到第一手线索，比瞎猜有用得多。

2. fork：一次调用，两个返回值，父子进程从此分道扬镳

2.1 fork 的底层机制：复制与写时拷贝

fork 是 Linux 下创建子进程最核心的接口，原型极其简单：

pid_t fork(void);

但它的行为诡异到让每个初学者震惊：调用一次，返回两次。在父进程中返回子进程的 PID，在子进程中返回 0，出错时返回 -1。所以 fork 之后一定要立刻对返回值做判断，用返回值区分当前是父还是子：

#include <stdio.h> #include <unistd.h> #include <sys/types.h> int main() { pid_t pid = fork(); if (pid < 0) { perror("fork error"); return 1; } else if (pid == 0) { printf("我是子进程，我的 PID 是 %d，我爹是 %d\n", getpid(), getppid()); } else { printf("我是父进程，我的 PID 是 %d，刚生了个儿子 %d\n", getpid(), pid); } // 注意：这里父子都会执行到！ printf("这句话父子都会打印，PID = %d\n", getpid()); return 0; }

为什么能返回两次？因为 fork 的核心动作是复制：内核把当前进程的地址空间、寄存器上下文、文件描述符表、信号处理设置全部复制一份，生成一个新的 PCB，然后让父子两个进程从 fork 调用的下一条指令继续各自执行。子进程拿到的是 fork 时刻父进程内存的"快照"，初始状态几乎一模一样，包括变量当前的值。

如果每次 fork 都完整复制所有内存，那遇到几百 MB 的进程频繁 fork 会非常低效。所以 Linux 用了**写时拷贝（Copy-on-Write，COW）**技术：fork 时并不真的复制物理内存页，而是让父子进程共享同一个物理页，且把这些页标记为只读。谁先尝试写入，谁就触发缺页异常，内核这才把这一页复制一份，让写入方拿到自己的副本。这样做的好处是：如果子进程 fork 完立刻 exec 执行新程序，那么整个地址空间根本不需要复制任何物理页，省掉了大量搬运。

这里有个常见的面试追问点：fork 之后，父子进程谁先执行？答案是不确定，由内核调度器决定。你不能在代码里假设"子进程一定先跑"或"父进程一定先跑"，要想控制执行顺序必须用 wait 或信号量同步，否则就会写出依赖调度顺序的"薛定谔式"并发 bug。

2.2 fork 复制了什么？文件描述符与缓冲区的坑

fork 复制的不只是变量。文件描述符表也会复制：如果父进程已经打开了一个文件，子进程里这个 fd 是有效的，而且和父进程指向同一个文件描述（共享文件偏移量）。这个特性可以用来做很多设计，但也埋了著名的坑。

什么坑？stdio 缓冲区的复制。C 语言的printf是库函数，它先把数据写进用户态的缓冲区，等缓冲区满或遇到换行符、fflush 时再真正调用 write 写入内核。如果父进程在 fork 之前先 printf 了一段没有换行符的内容，缓冲区里的数据会被子进程"继承"，导致这段数据被打印两次。

来个具体例子：

#include <stdio.h> #include <unistd.h> int main() { printf("只会打印一次吗？"); // 注意：没有 \n pid_t pid = fork(); if (pid == 0) { printf("[子进程]\n"); } else { printf("[父进程]\n"); } return 0; }

你可能会以为输出是：

只会打印一次吗？[父进程] 只会打印一次吗？[子进程]

但实际可能是"只会打印一次吗？"出现两次。原因是第一句printf只是把内容写进了缓冲区，fork 时缓冲区被完整复制给了子进程，最后父子各自在退出时 flush，各打了一遍。

解决办法很简单：fork 之前调用fflush(NULL)清空所有缓冲，或者让第一句 printf 带上换行符。这个坑在写涉及日志的服务程序时特别常见，稍不注意日志就重复了，排查半天还以为是程序逻辑写错了。

2.3 fork 的"合法"用法与性能考量

多数教科书讲 fork 只是演示"创建一个子进程"，但真实项目里直接用裸 fork 的时候并不多，反而经常是配合 exec 使用（shell 就是这么干的）。单独 fork 而不 exec 的合法场景包括：需要完全保留父进程内存映像做并行处理的服务器模型（早期 Apache 的 prefork 模式）、以及需要在子进程里做隔离性操作的辅助任务。

还有一点必须记住：fork 不是免费的。虽然 COW 省掉了物理内存复制，但创建进程仍然需要分配内核数据结构、复制页表、建立新的调度实体。在现代 Linux 上 fork 一次大概几微秒到几十微秒，但如果是高频创建销毁进程的场景（比如每秒上万个请求都各自 fork），这开销依然不可忽视。这也是为什么后来出现了 posix_spawn、vfork 以及线程等替代方案。

vfork 是个历史遗留的奇葩：它保证子进程先执行，且父进程会阻塞直到子进程 exec 或 exit，子进程共享父进程的地址空间（不复制页表）。它的设计初衷是"子进程马上要 exec 了，别浪费功夫复制"。但现在的 Linux fork 用了 COW 之后，vfork 在性能上已经没什么优势，而且它共享地址空间容易引发奇怪的问题，基本可以忘掉它，看到老代码里用了也建议改成 fork。

3. exec 家族：给进程换一张"执行面孔"

3.1 从 shell 执行程序到 execve 系统调用

如果 fork 是"复制一个自己"，那 exec 就是"把自己替换成另一个程序"。它做的事情非常暴力：把当前进程的代码段、数据段、堆栈整个替换成新程序的映像，然后重新初始化堆，从头开始执行新程序的 main 函数。进程的 PID 不变，但"人"已经换了——这就是 shell 执行命令的完整流程：先 fork 出一个子进程，再在子进程里 exec 你要运行的程序。

exec 不是一个函数，而是一族函数，它们的底层都是同一个系统调用execve，区别只在于参数形式和环境变量的处理方式。

int execl(const char *path, const char *arg, ...); int execlp(const char *file, const char *arg, ...); int execle(const char *path, const char *arg, ..., char *const envp[]); int execv(const char *path, char *const argv[]); int execvp(const char *file, char *const argv[]); int execvpe(const char *file, char *const argv[], char *const envp[]);

命名规则很好记：名字里带l表示参数以列表形式逐个给出（list），带v表示参数以数组形式给出（vector）；带p表示会自动在 PATH 环境变量中搜索可执行文件（不需要写完整路径）；带e表示可以自己指定环境变量数组。

最常用的是execlp和execvp，因为它们可以像 shell 一样直接写命令名。举个例子，在 C 代码里调用系统命令ls -l /tmp：

#include <stdio.h> #include <unistd.h> int main() { printf("执行 exec 之前，我是 %d\n", getpid()); execlp("ls", "ls", "-l", "/tmp", NULL); // 如果 exec 成功，以下代码永远不会执行 perror("exec 失败"); return 1; }

execlp的第一个参数是程序名，第二个参数"ls"是 argv[0]，后面每个参数对应一个 argv 项，最后必须以NULL结尾（用来标记参数结束）。注意 argv[0] 不一定和程序名相同，但惯例上都写成程序名，shell 脚本里常见的$0就是这个值。

3.2 exec 成功之后的事：谁能用 exec 做什么

exec 成功后，当前进程的代码段、数据段、堆栈全部被替换，进程从新程序的入口重新开始。这意味着 exec 之后的那一行代码永远不会执行（除非 exec 失败返回）。所以 exec 是"有去无回"的：它要么不成功，要么整个进程就变成另一个人了。

这个特性导致一个经典认知误区：有人以为 fork + exec 之后父进程会同时运行旧代码和新代码。实际上，父进程在 fork 返回后继续走父进程的分支，子进程调用 exec 后变成全新的程序，两个进程各走各的，互不干扰。父进程只有在子进程里 exec 失败时才会收到一个"失败"的信号（后面会讲），否则就只能在 wait 的时候知道"子进程干了什么然后结束了"。

还有一个实际项目里经常踩的坑：exec 之后，当前进程打开的文件描述符默认是保留下来的（除非设置了 FD_CLOEXEC）。这意味着如果父进程开了一个文件或一个 socket，子进程 exec 后仍然持有这个 fd，这会导致资源泄漏：父进程想关闭 fd 关不掉，因为子进程还攥着同一个引用。解决方法是给 fd 设置FD_CLOEXEC标志，这样 exec 的时候内核自动帮你关闭：

int fd = open("data.txt", O_RDONLY | O_CLOEXEC);

现代 Linux 中，凡是可能被 exec 继承的 fd 我都建议加上O_CLOEXEC，这是写服务程序的基本卫生习惯。早期项目里因为少这个标志导致 socket 句柄泄漏，查了大半天，最后发现是 fork 出来的子进程里带着监听 fd，调整了很久才理顺。

3.3 fork + exec 的完整实战：写一个极简 shell 雏形

把 fork 和 exec 组合起来，就可以写一个极简的"交互式命令执行器"了。逻辑很简单：读取用户输入，fork 一个子进程，子进程 exec，父进程等待子进程结束，然后继续读下一条命令。

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/wait.h> #define MAX_LINE 1024 int main() { char line[MAX_LINE]; while (1) { printf("mini-shell> "); fflush(stdout); if (fgets(line, MAX_LINE, stdin) == NULL) { break; // Ctrl+D 退出 } // 去掉行尾换行符 line[strcspn(line, "\n")] = '\0'; if (strlen(line) == 0) continue; pid_t pid = fork(); if (pid < 0) { perror("fork"); exit(1); } else if (pid == 0) { // 子进程执行用户命令 execlp(line, line, NULL); perror("exec 失败"); exit(127); // 命令找不到的经典退出码 } else { // 父进程等待子进程结束 int status; waitpid(pid, &status, 0); if (WIFEXITED(status)) { printf("子进程退出码: %d\n", WEXITSTATUS(status)); } } } return 0; }

这个程序虽然简陋，但麻雀虽小、五脏俱全，包含了进程控制的四大核心操作：fork（创建）、exec（替换）、wait（等待）、exit（结束）。你可以在上面继续加功能：支持参数拆分（用strtok把输入拆成 argv）、支持cd内建命令（因为 exec 不会改变父进程的当前工作目录）、支持管道（用pipe+dup2）……这些是很多公司面试里手写 mini-shell 的原型。

4. 进程的归途：exit、wait 与僵尸进程的完整体检

4.1 进程退出的两条路径：main 返回和 exit/_exit

进程结束无非两种方式：正常结束和异常结束。正常结束包括 main 函数 return、调用exit、调用_exit或_Exit；异常结束包括收到信号（比如 Ctrl+C 的 SIGINT、Segmentation fault 的 SIGSEGV）、调用abort等。

exit和_exit看起来都是"退出"，但差别很大：

• _exit是系统调用，直接在内核层面终止进程。
• exit是库函数，它会先调用用户注册的atexit回调，清理标准 I/O 缓冲区，然后再调用_exit。

这就意味着：如果进程里用了printf但内容还在缓冲区没 flush，你用_exit退出就永远看不到这些输出，而exit会把缓冲区清空。这也是 fork 缓冲区问题的延续——父子进程各自退出时 flush 各自的缓冲区副本。

正常退出的进程会把退出状态传给父进程，这个状态值只有 0~255 的低 8 位有效。约定俗成 0 表示成功，非 0 表示某种错误，命令行查看时会显示为$?的值。比如 shell 里执行一个程序，然后echo $?能看到退出码。

4.2 僵尸进程是怎么养成的

进程结束之后并没有立即从内核里消失。内核会保留这个进程的 PCB，只把"尸体"留给父进程来收——这个状态就叫僵尸进程（Zombie）。僵尸进程不再占用任何内存或 CPU，但它占着一个 PID 条目，内核里的 task_struct 也还挂着。

僵尸进程出现的根本原因是父进程没有调用 wait 回收子进程的退出状态。子进程退出时，内核向父进程发送 SIGCHLD 信号，同时把退出状态保存着，等待父进程来"认领"。如果父进程一直不认领，子进程就会一直保持僵尸状态。

来看这个经典"养僵尸"的代码：

#include <stdio.h> #include <unistd.h> int main() { pid_t pid = fork(); if (pid == 0) { // 子进程：立刻退出 printf("子进程退出，PID=%d\n", getpid()); _exit(0); } else { // 父进程：睡觉，不回收子进程 printf("父进程继续睡觉，PID=%d\n", getpid()); sleep(30); } return 0; }

运行后另开一个终端执行ps -ef或者ps -o pid,ppid,state,cmd，能看到那个子进程的状态是Z，这就是僵尸。僵尸进程不浪费 CPU，但累积多了会耗尽 PID 空间，导致无法创建新进程。有个很极端的段子：一个生产服务器 PID 耗尽，查下来是有个程序忘了 wait，日积月累养了几万个僵尸。

4.3 正确的"收尸"姿势：wait 与 waitpid 全解

父进程必须用wait或waitpid来回收子进程的退出状态。这两个函数会阻塞父进程，直到某个子进程结束，然后读取它的退出状态，并让内核彻底清理掉子进程的 PCB。

#include <sys/wait.h> pid_t wait(int *status); pid_t waitpid(pid_t pid, int *status, int options);

wait是最简单的版本：等待任意一个子进程结束。waitpid更灵活：可以指定等待某个子进程（pid 参数），可以设置 options 实现非阻塞等待，还可以知道到底是哪个子进程结束了。

关键在status宏的解析。子进程到底怎么死的，都编码在这个 status 里：

int status; waitpid(pid, &status, 0); if (WIFEXITED(status)) { // 正常退出 printf("退出码: %d\n", WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { // 被信号杀死的 printf("被信号 %d 杀死\n", WTERMSIG(status)); if (WCOREDUMP(status)) { printf("产生了 core dump\n"); } } else if (WIFSTOPPED(status)) { // 被暂停（配合 WUNTRACED 使用） printf("被信号 %d 暂停\n", WSTOPSIG(status)); }

这里有个实际排查中很常见的现象：你启动了一个守护服务，几天后发现进程挂了，用echo $?怎么都查不出原因，其实 $? 只保留最后一条命令的退出码。正确做法是在父进程里用waitpid+WIFSIGNALED把"被哪个信号杀死"记录下来，比如被 SIGKILL（9）杀和有 core dump 的 SIGSEGV（11）是完全不同的问题，前者多半是 OOM killer 或手动 kill，后者多半是野指针。

waitpid的 options 里最常用的是WNOHANG，它让waitpid不阻塞，如果没有子进程退出就立即返回 0。这在写非阻塞轮询的服务器里非常关键——你不希望父进程因为等一个不听话的子进程而卡死整个服务器。

4.4 批量回收子进程：回收一个还是回收全部

wait只回收一个子进程，如果有多个子进程同时退出，你只调用一次 wait，其他子进程就只能继续变僵尸。所以在一个收到 SIGCHLD 信号处理函数里调用 wait 时，经常需要用循环配合WNOHANG把所有已退出的子进程收干净：

#include <signal.h> #include <sys/wait.h> #include <stdio.h> void sigchld_handler(int sig) { int status; pid_t pid; // 循环回收所有退出的子进程，不阻塞 while ((pid = waitpid(-1, &status, WNOHANG)) > 0) { printf("回收了子进程 %d\n", pid); } }

这段代码是真实项目里的"标准答案"，很多面试官会问你"信号处理函数里为什么不用 wait 而用 waitpid + WNOHANG"，答案就是避免阻塞信号处理函数、同时回收所有已退出的子进程。还有一个坑：如果子进程收到信号被杀死，我们需要在 SIGCHLD 处理函数里做完整的 WIFEXITED / WIFSIGNALED 判断，否则日志里永远只有"子进程退出"四个字，看不出死因。

4.5 孤儿进程与 init 收养

如果父进程先于子进程退出，子进程会变成孤儿进程，被 1 号进程（通常是 systemd）收养。收养之后，它的 PPID 会变成 1，未来退出时由 1 号进程负责回收，所以孤儿进程不会变成僵尸。这是系统设计上的兜底机制：任何节点都会有一个父节点负责收尸。

但这里有个容易被忽略的点：如果你的程序故意"抛弃"子进程（比如 daemon 化），就必须确保子进程的父进程退出，它才不会被挂在你的进程树下。后面讲守护进程时会再提到这个"二次 fork"技巧。

5. 守护进程：脱离终端的"背后幽灵"

5.1 守护进程要解决什么问题

守护进程（daemon）是长期在后台运行、没有控制终端、不受用户登录退出影响的进程。你熟悉的 sshd、nginx、cron 全部是守护进程。守护进程解决的核心问题是"失去联系"：一个进程如果依附于某个终端，可能因为终端关闭被挂断信号（SIGHUP）干掉，所以它必须完全脱离会话和终端。

标准的 daemon 化流程是教科书里固定的一套组合拳，我当年第一次看到的时候一脸懵，后来一步步拆开才明白每一招的意义。

5.2 从 fork 到 setsid：完整守护进程创建步骤

一个经典的 daemon 化代码框架长这样：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/types.h> #include <sys/stat.h> void daemonize() { // 第一步：fork，让父进程退出 pid_t pid = fork(); if (pid < 0) { perror("fork"); exit(1); } if (pid > 0) { // 父进程退出，让子进程变成孤儿，被 init 收养 _exit(0); } // 第二步：创建新会话，脱离原终端 if (setsid() < 0) { perror("setsid"); exit(1); } // 第三步：再次 fork，确保不再获得控制终端 pid = fork(); if (pid < 0) { perror("fork"); exit(1); } if (pid > 0) { _exit(0); } // 第四步：改变工作目录，防止占用挂载点 chdir("/"); // 第五步：重置文件权限掩码 umask(0); // 第六步：关闭所有文件描述符 for (int i = 0; i < sysconf(_SC_OPEN_MAX); i++) { close(i); } // 第七步：把标准输入/输出/错误重定向到 /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 > STDERR_FILENO) close(fd); } }

每一招的目的拆解如下：

• 第一次 fork + 父进程退出：确保子进程不是会话组长（session leader），这样后续setsid才能成功。同时父进程退出后子进程变成孤儿，与原始终端摆脱血缘关系。
• setsid：让子进程成为新会话的首进程、新进程组的组长，并且没有控制终端。这是整个流程里最关键的一步，相当于让进程"和终端彻底分家"。
• 第二次 fork：防止子进程（现在是会话组长）重新获取控制终端。当一个没有控制终端的会话组长打开一个终端设备时，可能自动获得该终端作为控制终端。再 fork 一次，让孙子进程成为非会话组长，就能避免这个潜在风险。
• chdir("/")：避免把当前工作目录锁定在某些目录上（比如一个可以卸载的 U 盘挂载目录），否则你永远无法卸载那个分区。
• umask(0)：确保进程创建的文件不会带上从父进程继承来的默认权限限制，防止创建出来的文件权限和期望不符。
• 关闭所有 fd 并重定向到 /dev/null：避免继承无用的终端、日志文件句柄，也避免后面往标准输出写东西时因为终端不存在而报错。

我实际写守护进程时还有一个习惯：手动打开一个日志文件并记录 PID 到 pidfile。网上很多示例代码为了演示简洁，都忽略了这个，但真实部署时你要是没有日志，出问题连查的方向都没有。比如用 openlog/syslog 把日志打到系统日志，或者自己 open 一个文件写到固定路径。pidfile 用于后面 stop 脚本能精确找到进程 ID 去 kill。

5.3 单实例守护进程：文件锁防止多开

守护进程还有个经典需求是"保证全局只有一个实例在跑"。如果用户手滑启动两次服务，可能会把同一个数据目录搞坏。通用的做法是用文件锁：

#include <fcntl.h> int fd = open("/var/run/myservice.pid", O_CREAT | O_RDWR, 0666); if (fd < 0) { exit(1); } // 尝试加独占写锁 struct flock lock; memset(&lock, 0, sizeof(lock)); lock.l_type = F_WRLCK; lock.l_whence = SEEK_SET; if (fcntl(fd, F_SETLK, &lock) < 0) { // 已经有别的进程持有锁 fprintf(stderr, "服务已经在运行\n"); exit(1); }

这个锁不是别人"伪造"的 pidfile 文件那种表面检查，而是内核级的文件锁，进程崩了锁自动释放，天然防呆。如果你需要做得规范一点，还可以把 pidfile 里的 PID 顺便写进去，让运维脚本能用它 kill 进程。

5.4 守护进程的退出与清理

守护进程常驻后台，它退出通常不是因为 main 函数跑完了，而是收到了信号。标准做法是注册信号处理函数处理 SIGTERM（优雅停机）。SIGTERM 是kill命令默认发的信号，所以你的守护进程必须响应它，否则 kill 出来毫无反应，运维只能上 SIGKILL。

一个简单的优雅退出框架：

#include <signal.h> static volatile sig_atomic_t running = 1; void handle_signal(int sig) { if (sig == SIGTERM || sig == SIGINT) { running = 0; } } int main() { signal(SIGTERM, handle_signal); signal(SIGINT, handle_signal); while (running) { // 主循环干活 sleep(1); } // 退出前清理资源：把 pidfile 删掉、关闭 socket、写日志 unlink("/var/run/myservice.pid"); return 0; }

这里用sig_atomic_t类型声明 running 是保证信号处理函数和主循环之间的读写是原子的，不会出现编译器优化导致的"看不到变量变化"问题。教科书上都建议信号处理函数里只做最简单的动作，比如置一个标志位，不要在信号处理函数里做复杂逻辑，这一点实际项目里必须遵守，否则很容易引入未定义行为。

6. 进程控制的信号机制与真实运维场景

6.1 信号是进程控制中的"短信电话"

进程控制的最后一环其实是信号（signal）。信号的本质是操作系统向进程发送的异步事件通知，相当于给进程发一条短信：你要退出了（SIGTERM）、你非法访问内存了（SIGSEGV）、你收到中断键了（SIGINT）、你的子进程死了（SIGCHLD）。

不同信号的默认行为各不相同：

这里有个特别容易在服务开发中踩的坑：SIGPIPE。当你向一个已经关闭的 socket 或管道写入数据时，系统会发 SIGPIPE 给进程，默认行为是杀掉进程。很多网络服务刚上线的时候频繁崩溃，查到最后就是没处理 SIGPIPE，客户端一断开，服务端 write 就触发 SIGPIPE 自杀。解决方案是在 main 里加一行：

signal(SIGPIPE, SIG_IGN); // 忽略 SIGPIPE，让 write 返回 EPIPE 错误自行处理

忽略之后，write 会返回 -1 并设置 errno 为 EPIPE，你就可以在应用层判断"对端断了"，该清理连接清理连接，而不是整个进程陪葬。

6.2 信号处理的艺术：注册和使用中的边界

C 语言里注册信号处理的传统接口是signal，但实际项目里我更推荐sigaction，因为它语义可移植性更好、行为可预测。看一个对比：

// 传统 signal 接口 signal(SIGINT, handler); // sigaction 接口 struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_handler = handler; sigemptyset(&sa.sa_mask); // 不屏蔽其他信号 sa.sa_flags = 0; // 默认标志 sigaction(SIGINT, &sa, NULL);

sigaction 的好处是：可以精确控制"在处理信号时屏蔽哪些信号"（sa_mask）、可以设置重启被中断的系统调用（SA_RESTART）、可以获取之前安装的处理函数等。比如 SA_RESTART 的作用是：当你阻塞在 read/accept 上时收到信号，默认行为会使这些系统调用返回 EINTR 错误，导致程序莫名中断；设置了 SA_RESTART 后内核会自动帮你重启这些调用，行为更接近直觉。

真实开发中，我写信号处理函数有三条铁律：

1. 不在信号处理函数里调用 printf、malloc、fork 等非异步信号安全函数。因为信号可能随时打断主线程正在进行的 malloc/free，导致堆结构错乱。要记录日志就用write往 fd 里写，或者只置标志位。
2. 信号处理函数越短越好，最好只是置一个全局标志，让主循环去检查。
3. 别试图在信号处理函数里做复杂业务逻辑，因为你不知道这个信号是什么时候来的，主流程的数据处于什么状态。

6.3 一个真实的排查案例：进程频繁"神秘消失"

我之前遇到过一次特别经典的排障：某服务进程跑几十秒就悄无声息地消失，日志里一点错误都没有。第一反应是有没有 core dump？看 /proc/sys/kernel/core_pattern 发现 core 被 pipe 给 systemd-coredump 处理了，于是用coredumpctl查看，看到进程是被 SIGSEGV 杀掉的，而且产生了 core。

然后我用 gdb 加载 core 文件，backtrace 一看，卡在 stdio 的某个加锁函数里。再一查，有人在多个线程里同时调用 printf，而没有做线程同步，导致 stdio 内部锁被打破，一个线程 free 了另一个线程正在用的缓冲区，触发 SIGSEGV。

这个案例说明一个道理：进程被信号杀死时，光看业务日志是没用的，要先确定死因。Linux 排查进程死因的几个顺序动作是：查 core（看有没有 core，core 里的 backtrace 直接定位崩溃点）、查消息日志（/var/log/messages 或 journalctl，能看到 OOM killer 记录的"杀掉了谁、占用多少内存"）、看进程退出码或者父进程记录的 WTERMSIG。这套流程配合 SIGCHLD 处理函数里打印退出原因，能帮你解决大部分"进程怎么又没了"的问题。

如果连 core 都看不到，多半是被 SIGKILL 强杀的，这时候第一怀疑对象是 OOM killer。查journalctl -k | grep -i oom看看有没有你的进程名，或者去数一下系统可用内存是多少、是不是被别的进程吃光了。我见过太多"神秘消失"，最后都是内存超限被 OOM killer 收割，而不是代码逻辑问题。

6.4 父子进程协作：用信号和 waitpid 做优雅退出

最后把进程控制串起来，一个带优雅退出机制的父子进程协作模型大概是这样的：

父进程流程：

1. 注册 SIGTERM/SIGINT 处理函数，设置一个全局 running 标志。
2. fork 出子进程去干活，子进程 exec 或者跑业务循环。
3. 父进程在 waitpid 循环里等待子进程，同时用 WNOHANG 轮询检查 running 标志。
4. 收到退出信号时，父进程先给子进程发 SIGTERM，然后回收它的退出状态。

子进程流程：

1. 由于继承了父进程的信号处理，子进程也要处理 SIGTERM，负责清理自己的资源再退出。
2. 退出前通过 exit code 向父进程汇报"我是清理完才走的还是被强杀的"。

这套模型不管是写启动脚本、系统服务还是网络服务框架，都是非常通用的底座。你可以在这个基础上不断加功能：心跳检测、进程看门狗、日志回滚……但核心始终是那四板斧：fork、exec、wait、signal。

我在实际项目里还总结过一个经验：能用 shell 脚本或者 systemd Unit 解决的进程守护问题，尽量不要自己造轮子。systemd 自带Restart=on-failure、KillMode=mixed这些参数，能帮你处理很多服务崩溃重启、优雅停机的需求。你仍然需要理解 fork/wait/signal 这些底层机制，因为很多疑难杂症的根因恰恰藏在系统的这层"管道工事"里。