开篇先聊点实在的：Linux进程控制这个话题，几乎是所有玩系统、写服务、做嵌入式的朋友都绕不开的一道坎。无论是面试时候被问“僵尸进程怎么处理”，还是线上排查CPU飙高、端口被占用，甚至只是想在服务器上稳定挂一个后台任务，本质上都是在跟“进程控制”这四个字打交道。我自己刚接触Linux那会儿，总觉得进程这东西玄乎乎的——它在跑、它在睡、它死了，但除非用ps看一眼，否则根本不知道到底发生了什么。后来在嵌入式项目里因为进程管理没做好，栽过跟头，才彻底把这块啃透。

这篇内容不打算写成教科书式的“进程控制全面指南”，而是按照我实际使用和排查问题的经验，把进程控制拆成几条主线：先用命令行的视角把进程的运行状态讲清楚，再深入到系统调用层面拆解fork、exec、wait这几个核心函数，然后给出一套可以直接动手练的完整实例，最后聊一聊那些踩过的坑和排查思路。不管你是刚开始学Linux的新手，还是已经在做嵌入式、后台服务器开发的朋友，这篇应该都能帮你把碎片化的知识串起来。

1. 进程控制的整体认知：先分清“命令操作”和“系统编程”两条线

1.1 进程到底是什么，为什么要“控制”它

进程可以简单理解为一个正在运行的程序实例。程序是躺在磁盘上的静态文件，进程则是被加载到内存、分配了CPU时间片、有自己独立地址空间的动态实体。Linux里万物皆文件，但进程是个例外——它是一个由内核调度器统一管理的执行单元。

那“进程控制”控制的是什么？从业界实际需求来看，主要集中在四个方面：进程的创建、进程的执行与替换、进程的终止、进程的回收与状态监控。命今行下的kill、ps、top、nohup，本质上是用户态的“控制请求”；而fork、exec、exit、wait这一族系统调用，则是内核态提供的底层控制接口。两条线分别对应运维/使用者的操作视角和开发/内核研究者的编程视角。

我之前带过一个实习生，他搞混了一个基础概念：以为kill -9 PID就是“杀死进程的API”，实际上kill只是通过信号机制向进程发送一个终止请求，最终的处理逻辑在内核和进程本身的信号处理函数里。这种误解挺普遍的，所以第一篇想先把概念边界划清楚。

1.2 理解进程生命周期：运行、睡眠、停止、僵尸

Linux进程不只有“运行”和“结束”两种状态。用ps -l看进程状态码，会发现有R（运行）、S（可中断睡眠）、D（不可中断睡眠）、T（停止）、Z（僵尸）等。理解状态机是进程控制的第一步。

• R 表示进程正在CPU上运行或处于可运行队列中，随时可能被调度。
• S 是最常见的状态，表示进程在等待某个事件，比如等待I/O完成、等待Socket数据到来，此时进程被挂起，不占用CPU。
• D 是内核线程或执行系统调用的进程在等待不可中断的I/O操作时进入的状态，这个状态杀不掉，只能等I/O恢复。
• T 是进程被暂停，通常是因为收到SIGSTOP或SIGTSTP信号，+后缀表示它在前台进程组里。
• Z 就是著名的僵尸状态，进程已经终止，但它的退出状态还没有被父进程接收，因此内核保留了它的进程描述符，等待被“收尸”。

状态之间不是随便跳转的，每一个状态切换背后都有明确的系统调用和内核逻辑支撑。比如SIGKILL信号直接终结进程，进程直接进入僵尸态而不是立刻从进程表中消失；再比如fg命令把后台任务调回前台，本质是发送SIGCONT让处于停止态的进程重新被调度。

2. 从命令行出发：直观感受进程控制和资源查看

2.1 进程查看三板斧：ps、top、pidstat

进程控制的前提是“能看见进程”。我个人最常用的三组命令，覆盖了静态快照、动态刷新、按线程维度统计三个层级。

第一板斧是ps。面试和实际排查都爱问ps -ef和ps aux有什么区别。其实两者输出内容基本一致，区别主要在语法风格：ps -ef是Unix风格，ps aux是BSD风格。ps aux的STAT列会更直观地显示进程状态，我用ps -eo pid,ppid,stat,comm,user这种自定义格式更多些，因为可以严格挑选关心的列，输出干净不乱。

第二板斧是top。日常排查CPU爆满，top是打开的第一屏。按P键按CPU排序，按M键按内存排序，直接找到最耗资源的那个PID。需要说明的是，top默认显示的CPU使用率是一个相对值，受采样间隔影响，看到瞬时超高不一定是真凶，要观察一段趋势。相比top，现在服务器上更推荐htop，交互更友好，支持树状进程视图，可以直接选择信号发送，但对纯净生产环境来说没有自带htop的，装不装看需求。

第三板斧是pidstat。它不是最常被提到的工具，但按进程维度的pidstat -p PID 1可以每秒输出一次该进程的CPU、内存、I/O和线程上下文切换详情。之前定位一个多线程程序为什么会话锁频繁，就是靠pidstat -w -t -p PID看到每个线程的上下文切换次数异常飙升，才锁定到一个自旋锁的问题。

2.2 进程停止与信号：kill的正确打开方式

很多人觉得kill就是“杀进程”，但kill本质是“发信号”。普通的kill PID发送的是SIGTERM（15号信号），这是一个礼貌的终止请求，进程可以捕获它、做清理工作、保存数据、优雅退出。而kill -9 PID发送的是SIGKILL，内核直接强制终止，进程没有机会做任何善后处理。

这里吃过亏——有次在测试环境上直接kill -9了一个正在写本地缓存的程序，结果重启后发现旧缓存文件损坏，程序里没有做启动时校验，直接加载了半个写坏的文件，导致数据错乱。后来统一规范：日常停服务优先用SIGTERM，只有确实卡死无响应才考虑SIGKILL。在脚本里更合理的是先发SIGTERM，等待若干秒后检查进程是否还在，还在再补一个SIGKILL，给进程留出清理和落盘的窗口。

发信号不只是杀进程。kill -STOP PID让进程暂停，kill -CONT PID让它继续，配上fg/bg命令的用法就能理解作业控制的底层语义。还有kill -HUP PID在传统守护进程里常用来触发重新加载配置文件，nginx、sshd都遵守这个约定，很多老运维喜欢用kill -HUP $(cat pidfile)来平滑加载配置而不中断服务。

2.3 后台运行与守护化：nohup和setsid的底层差异

命令行里控制进程最常用的就是后台运行。command &只是把进程放到当前终端的后台作业，但终端关闭时进程可能会收到SIGHUP而退出。nohup command &的作用是让进程忽略SIGHUP，所以即使关掉终端，进程也能继续跑，输出默认写到nohup.out。

而setsid是更彻底的方式：setsid command会让进程完全脱离当前会话，重新创建新的会话和进程组，不再有控制终端，它已经成为一个类似守护进程的存在。这两者的原理区别在于进程组与会话的继承：nohup只是忽略挂断信号，进程仍然属于原来那个会话；setsid是把进程变成新会话的领头进程，彻底“断奶”。

实测下来，如果只是临时在远端跑个长任务，nohup足够用；但如果想写一个严谨的后台服务启动脚本，最好用systemd管理，或者至少用setsid配合输出重定向。很多线上服务崩溃的隐藏原因之一，就是父进程退出时子进程被牵连杀掉，问题根源在进程组和会话的控制上。

3. fork与exec：进程创建的底层原理

3.1 fork的写时复制与PID分配逻辑

系统编程视角下的进程控制，核心起点是fork()系统调用。调用一次，返回两次，这是初学时最容易卡住的地方。在父进程中返回子进程的PID，在子进程中返回0，这个设计是为了让父子进程根据返回值执行不同的逻辑分支。

教科书上说fork之后子进程是父进程的一个完整副本，但现代Linux实现用了copy-on-write（写时复制）技术：fork时子进程和父进程共享同一份物理内存页，只有当某一方真正写入数据时，内核才复制对应的内存页。所以fork本身的开销非常小，这也是很多高性能服务使用多进程模型的底气所在。

还有一点容易忽略：fork成功后，父子进程属于同一进程组，父进程的PID与子进程的PID在数值上不一定是连续的。Linux内核分配PID是每递增1并绕回循环使用，同时为了避免PID猜测攻击，有时会随机跳过一些值。所以拿到一个PPID想推算兄弟进程的PID是不靠谱的，能看到的就是真实的父子关系。

3.2 exec族函数：替换进程的代码与数据

fork只是复制了当前进程的地址空间，但子进程如果要去执行另一个程序，就需要exec族函数。execl、execv、execle、execvp这些变体的区别只在参数传递方式、路径查找方式、环境变量处理上。exec系函数成功后不返回，因为当前进程的代码段、数据段、堆、栈已经全部被新程序替换，原来的进程映像不复存在。

一个经典问题是：fork之后再exec，是不是多此一举？如果只是顺序执行一个大程序，确实可以直接用exec替换当前进程。但实际场景中，我们需要先创建子进程，在子进程中重定向标准输入输出、关闭不需要的文件描述符、设置信号掩码，然后再exec去执行目标程序。这是“先改造环境，再跳槽”的模式。

我写过一个小工具，负责按需拉起加密解密子进程：父进程通过pipe建立两个通道，fork出子进程后在子进程里把标准输入输出重定向到pipe，然后execl去执行openssl命令，父进程则通过管道向子进程写入待处理数据、读取处理结果。整个过程fork管生、exec管换、管道管通信，各司其职。

3.3 exit与退出状态：进程的最后一步

进程退出有两个出口：return和exit。在C语言里，main函数return 0等价于调用exit(0)。但两者不完全等价：exit会先执行atexit注册的清理函数，再刷新标准I/O缓冲区，最后调用_exit陷入内核；_exit和_Exit则直接让内核清理进程资源，不执行用户态清理函数。

这里有个容易踩的经典坑：printf的标准输出缓冲区。如果代码里输出了日志但没有换行符，_exit直接终止可能导致缓冲区内容被丢弃，什么都没打出来。我排查过生产环境里一个daemon进程崩溃后日志缺失的问题，最后就是因为它用_exit退出，用户态缓冲区里那几行日志根本没来得及刷到文件，加了个setvbuf改成行缓冲才解决。

退出状态码的范围是0到255。父进程只能获取这个8位的状态值，超出部分会被截断。注意负数退出码，比如进程因信号终止时的状态是“128+信号编号”——SIGKILL对应137，SIGSEGV对应139，这是shell脚本里判断进程死因的一个速记方式。

4. 实战：编写一个完整的子进程管理与状态监控程序

4.1 代码结构与核心设计

这一段给出一套可以直接复制运行的最小但完整的演示程序，涵盖fork、exec、waitpid、信号处理和进程状态监控。代码可运行在任意Linux发行版上，依赖只有gcc和标准C库。

c复制#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
#include <signal.h>
#include <string.h>
#include <errno.h>

static pid_t child_pid = 0;

static void handle_sigterm(int sig) {
    if (child_pid > 0) {
        kill(child_pid, SIGTERM);
    }
}

int main(int argc, char *argv[]) {
    if (argc < 2) {
        fprintf(stderr, "Usage: %s <command> [args...]\n", argv[0]);
        return 1;
    }

    signal(SIGTERM, handle_sigterm);

    pid_t pid = fork();
    if (pid < 0) {
        fprintf(stderr, "fork failed: %s\n", strerror(errno));
        return 1;
    }

    if (pid == 0) {
        /* 子进程：执行目标程序 */
        execvp(argv[1], &argv[1]);
        /* 只有exec失败才会执行到这里 */
        fprintf(stderr, "exec failed: %s\n", strerror(errno));
        _exit(127);
    }

    /* 父进程：记录子进程PID，进入监控状态 */
    child_pid = pid;
    printf("[parent] child process started, pid=%d\n", pid);

    int status = 0;
    pid_t ret = waitpid(pid, &status, 0);
    if (ret < 0) {
        fprintf(stderr, "waitpid failed: %s\n", strerror(errno));
        return 1;
    }

    if (WIFEXITED(status)) {
        printf("[parent] child exited normally, code=%d\n", WEXITSTATUS(status));
    } else if (WIFSIGNALED(status)) {
        printf("[parent] child terminated by signal %d\n", WTERMSIG(status));
    }

    child_pid = 0;
    return 0;
}

这个程序的设计逻辑提炼出来只有三句话：父进程fork之后用execvp执行外部命令，父进程进入waitpid阻塞等待，子进程退出后父进程根据status解码退出原因。execvp的第一个参数是可执行程序名，argv[1]到argv[argc-1]就是传给子进程的参数数组。

4.2 编译运行与结果解析

用gcc -o proc_demo proc_demo.c编译之后，先跑一个正常退出的命令：

bash复制./proc_demo ls -l /tmp

输出大概是：

code复制[parent] child process started, pid=31234
...（ls的输出）
[parent] child exited normally, code=0

再跑一个异常退出的命令，比如试图运行一个不存在的程序，exec失败，子进程以127状态码退出：

bash复制./proc_demo /bin/bash -c "exit 3"

输出：

code复制[parent] child process started, pid=31236
[parent] child exited normally, code=3

exit 3让bash子进程返回状态3，WEXITSTATUS(status)解出来的code=3一目了然。这个“退出状态码透传验证”本身就是调试进程控制问题时非常实用的手段。

4.3 关键代码逐行拆解

很多人写多进程程序只关注主逻辑，忽略进程退出路径，这一段来拆解几个关键点。

waitpid(pid, &status, 0)的第三个参数是选项，设为0表示阻塞等待。如果换成WNOHANG，则不会阻塞，而是立即返回0表示子进程仍在运行，此时需要轮询或配合SIGCHLD信号异步处理。在真正的服务器程序里，阻塞式waitpid和信号处理是两套不同风格，新手容易混淆。简单的多进程调度器用阻塞式足够，但如果你在事件循环里阻塞等待子进程退出，整个事件驱动的模型就卡死了，这时候必须用WNOHANG配合SIGCHLD。

WIFEXITED(status)和WIFSIGNALED(status)这两个宏用于解码status。status变量由内核在waitpid返回时填充，其高8位是退出码，低7位是导致进程终止的信号编号，第8位是核心转储标记。直接用整数值去比较是不严谨的，永远用标准宏去判断。

父进程收到SIGTERM时会把信号转发给子进程。这看起来很简单，但隐藏了一个关键细节：kill(child_pid, SIGTERM)发完信号之后，父进程仍然阻塞在waitpid上。因为子进程接收SIGTERM后是否立刻退出取决于它自己的信号处理逻辑，如果子进程自己捕获了SIGTERM并选择了忽略，那么父进程会在waitpid上一直等下去，child_pid = 0这行永远不会执行。这种场景下需要给waitpid设置超时，或者引入第二套机制来兜底。实际做服务守护进程时，我一般会在发信号后轮询等待几秒再用kill(child_pid, SIGKILL)强杀，保证退出链路完整。

5. 进程回收与僵尸进程：为什么必须“收尸”

5.1 僵尸进程的形成机制与危害

僵尸进程的产生原因很简单：子进程终止后，内核不会立即释放它的进程描述符，而是保留这个描述符，直到父进程调用wait/waitpid获取退出状态。如果父进程迟迟不调用wait，子进程就永远处于Z状态，成为僵尸。

一个两个僵尸进程看着问题不大，但数量积累到一定程度就是事故：每个僵尸进程都占着一个PID，而系统能分配的PID总数是有限的（可以通过/proc/sys/kernel/pid_max查看），大量僵尸进程会导致新进程无法创建。我遇到过一台测试机PID耗尽，服务完全无法启动，登录进去ps一看，几百个僵尸java进程挂着——原来是一个管理程序异常退出后，它负责回收的一批子进程全部成了孤儿，没人收尸。

5.2 回收子进程的三种标准姿势

最基础、最常见的姿势是wait或waitpid的阻塞等待。这种方式实现简单，逻辑清晰，适用于一个父进程对少量子进程的串行管理场景。但服务端程序不能随便阻塞主流程，所以有了第二种姿势：使用SIGCHLD信号配合waitpid异步回收。

SIGCHLD是内核在子进程状态变化时给父进程发的信号。在信号处理函数里调用waitpid(-1, &status, WNOHANG)，可以一次性收割所有已退出的子进程且不阻塞。要点是信号处理函数里不能调用不可重入函数，waitpid是可重入的安全函数，而printf不是，所以千万别在信号处理函数里打日志。

第三种姿势是在现代Linux集群和容器环境里主流的方案：把子进程托管给systemd或专门的init进程，让它们成为孤儿，系统级init会自动回收。代码里对应的是daemon(0, 0)或自己实现双重fork，让子进程的父进程变成PID 1，这样即使原父进程崩溃退出，最终的回收也有兜底。

5.3 一个耗时程序的僵尸问题排查实录

有一回调试一个长期运行的计算程序，跑几百次任务就开始报Resource temporarily unavailable，排查发现进程表里堆了几十个僵尸进程。根因是程序里用了fork创建子进程，但是创建完之后父进程就自己去忙别的事了，压根没调用wait。

第一版修复很简单：子进程任务本来就很快，父进程加一个waitpid(child_pid, &status, 0)立即回收。改了之后僵尸数量降为0。后来程序升级，变成并发创建5个子进程，结果waitpid只堵在第1个子进程上，后面4个退出后照样变僵尸。这才改成统一处理SIGCHLD信号的方式，信号处理函数里循环waitpid(-1, &status, WNOHANG)，一次性收割。总结下来就一句话：子进程越多，越不能用点对点的阻塞等待，必须上信号驱动批量回收。

6. 进程优先级与调度控制：如何影响进程的“话语权”

6.1 nice值、优先级和调度器的关系

Linux进程中，CPU调度的核心依据之一就是进程优先级（pri），它由静态优先级和动态优先级组成。用户态可以通过nice值来影响静态优先级，范围是-20到19，默认值是0。nice值越低，进程越“激进”，优先级越高；nice值越高，进程越“谦让”，优先级越低。

实际使用中怎么理解？一个音频处理程序需要低延迟，就可以用nice -n -5 ./audio_daemon启动，让它比普通进程更抢占CPU。一个后台的日志打包任务不想占用主业务的CPU，可以用nice -n 10 ./log_compressor，让它在系统空闲时才多干活。renice命令可以调整已运行进程的nice值，renice -n -5 -p PID，普通用户只能调高不能调低，root无限制。

top命令的NI列和PR列就分别显示nice值和动态优先级。PR的计算一般是“20 + nice”，但现代的完全公平调度器（CFS）下，PR只是一个近似映射，真正调度靠的是虚拟运行时间vruntime。越是优先级高的进程，vruntime增长越慢，越容易被调度器选上。

6.2 实时调度与CPU绑核：嵌入式和高性能场景的进阶控制

在嵌入式和工业控制场景里，光设置nice值往往不够，需要实时调度策略。Linux支持SCHED_FIFO、SCHED_RR和SCHED_DEADLINE等实时调度类，通过pthread_setschedparam或sched_setscheduler设置。SCHED_FIFO是先进先出实时调度，高优先级的SCHED_FIFO进程不会被低优先级抢占，直到它自己让出CPU或阻塞；SCHED_RR在FIFO基础上增加了时间片轮转，同样优先级的实时进程之间可以轮换。

设置实时优先级要特别小心，因为一个失控的实时进程可能饿死整个系统的普通进程。rtkit这类机制会限制普通用户获取实时优先级的权限。一般只有root能设置SCHED_FIFO优先级1到99。我在工控机上做运动控制时用过SCHED_FIFO给伺服控制线程一个较高的实时优先级，配合CPU绑核，把抖动时间从毫秒级压到了几十微秒级，代价是CPU的一个核心几乎被该线程独占，系统里其他任务要避让。

CPU绑核相关的调用是sched_setaffinity，命令行的对应工具是taskset -c 2,3 ./process。绑核的意义在于减少CPU缓存失效和上下文切换：进程只在一个核心上运行，L1/L2缓存命中率会明显提升。但对普通业务服务来说，绑核可能让负载不均衡，非高频场景一般不主动用。

7. 进程控制系统调用与信号综合排查表

7.1 核心系统调用速查

7.2 常见场景排查思路速查

8. 进程控制的延伸思考：从单机到容器与嵌入式

8.1 容器技术与命名空间下的“进程控制”

到了容器时代，进程控制有了新的维度。容器本质上是宿主机上的普通进程，但通过命名空间隔离，让容器内进程以为自己是独立系统里的PID 1。这套机制涉及clone系统调用与CLONE_NEWPID等标志位，fork只是clone的最小子集。

在容器里要注意的是：容器内的PID 1进程承担了原来系统init的职责，如果它没有正确设置信号处理，容器退出时可能残留僵尸子进程。这就是为什么很多容器基础镜像会选择tini这类微型init作为入口，本质就是给容器内的进程加一个“收尸人”。写容器内服务脚本时，不要想当然地以为子进程退出后会被系统自动回收——在PID命名空间内的环境下，回收职责完全落在容器PID 1的进程肩上。

8.2 嵌入式Linux中的进程控制特点

嵌入式Linux场景下，进程控制还有一个特点：资源受限。CPU频率低、内存小、Flash慢，fork会复制父进程页表，即使写时复制降低了物理内存开销，页表的复制依然存在成本。对于内存非常紧张的小设备，我见过一些方案直接只用posix_spawn而不是fork+exec。posix_spawn内部的实现可以针对嵌入式环境做优化，在某些musl libc版本下，它能做到不完整复制父进程地址空间，大幅减少创建子进程时的内存峰值。

嵌入式里还有一个容易忽略的点：进程启动顺序和依赖管理。很多设备里没有systemd，只有简单的rcS脚本，进程控制全靠start-stop-daemon这种工具。这类工具本质上就是一个封装好的“fork + exec + PID文件 + 信号管理”流程。我自己写一个服务的启动脚本时，通常遵循的模板是：先检测PID文件是否存在以及进程是否存活，再start-stop-daemon --start --pidfile /var/run/app.pid --exec /usr/bin/app -- -d启动服务并生成PID文件，停止时先发SIGTERM等几秒再发SIGKILL，这些操作背后的原理，就是把前面所有进程控制的系统调用经验沉淀成了脚本约定。

8.3 现代后台服务与进程管理框架

再往上层看，现在写服务基本不再自己裸调fork了。Node.js的child_process模块、Python的multiprocessing库、Go的os/exec包、Java的ProcessBuilder，都是进程控制的语言级封装。用的还是那套系统调用，但封装层帮你处理了管道、超时、退出码解码、信号转发等大量样板逻辑。理解底层原理的价值在于：当你看到child_process.spawn打印一个奇怪的退出码，或者ProcessBuilder挂起不退出时，你能立刻对应到底是exec失败、信号终止、还是缓冲区没排空的问题——而不是困在语言框架的报错信息里打转。

像systemd这类系统服务管理器，更是把进程控制精细化到了极致：Type=forking、Type=exec、Type=notify这些字段，对应的是父进程先退还是子进程接管的语义判断，KillMode=control-group决定了服务停止时要对进程组内所有进程统一发信号。理解了进程组、会话、信号转发这些概念，读systemd配置就像看一个结构清晰的进程状态机说明。

9. 面试真题视角：进程控制的五种经典拷问

结合最近几年的Linux面试题热词，把常见的进程控制问题按思路整理了一遍，希望能帮你建立“题目-原理-解答”的对应关系。

1. fork之后，父子进程的执行顺序是怎样的？

这是一个考察调度理解的问题。fork调用完成后，父子进程都会从fork返回处继续执行，但谁先执行完全由内核调度器决定，不能在代码里做任何顺序假设。如果需要父子进程同步，要么用wait让父进程等待子进程退出，要么用管道、信号量等IPC机制做同步。生产代码里跳过wait直接访问共享资源是很典型的竞态问题源头。

2. 孤儿进程和僵尸进程有什么区别？

孤儿进程是父进程已退出而子进程还在运行，此时子进程会被系统init（或systemd）收养，变成PPID为1的进程，孤儿进程不会一直存在，它会被正常调度；僵尸进程则是子进程已退出但父进程没有调用wait回收，进程表项被保留，占用PID和内核资源。区别一句话：孤儿还在跑，僵尸已经死但没人收尸。

3. 一个程序可以有两个父进程吗？

不能，每个进程只有一个PPID。但一个父进程可以拥有多个子进程，它们共享同一个父进程PID。这是树状结构，不是网状结构。

4. 如何让一个进程退出后自动重启？

经典做法是父进程循环waitpid，检测到子进程退出后，判断退出码、计数重启次数、重新fork。生产环境里负责“看门狗”的脚本/程序必须是独立且高可靠的，同时要设置重启次数上限和退避策略，避免“崩溃-重启”死循环烧CPU。也可以借助systemd的Restart=on-failure实现对服务的自动拉起。

5. kill与system("kill ...")有什么不同？

kill是系统调用，直接在进程控制层面发信号。system("kill ...")则是启动一个shell去执行外部命令，开销更大、路径依赖更多、返回语义也更绕。生产代码里要控制另一个进程，应该直接调用kill(pid, sig)，而不是system拼接命令行。

10. 实际操作中总结的几点经验

最后分享几条我个人掏心窝的经验，不一定写在教科书里，但确实在项目里救过我。

第一，fork之后先思考文件描述符的走向。fork会复制所有文件描述符，子进程如果不主动关闭从父进程继承来的监听Socket、日志FD，会导致资源泄漏、端口无法释放。最典型的问题就是：服务进程进行热升级时，老的进程还占着文件句柄，日志轮转失败。写多进程程序时，先在子进程里明确close掉不该继承的FD，再exec，逐步养成这个习惯能避开一大批线上疑难杂症。

第二，用PID文件要小心PID复用。如果进程崩溃退出，系统很快把它的PID分配给一个新进程，此时旧的PID文件可能指向一个完全不相干的新进程。启动守护进程前必须先检查PID文件对应的进程是否真的是自己这个程序，可以读/proc/PID/exe或/proc/PID/comm来确认，不能只看PID存在就认为服务还在运行。

第三，写进程控制逻辑时把日志打完整。很多人嫌日志多，但排查问题时候最大的痛点就是“不知道进程走到哪一步”。我在多进程代码里常见的日志点包括：fork前、子进程exec前、子进程启动成功后（输出child pid）、waitpid返回后、正常退出分支、异常信号分支。每一条日志带着时间和PID，回放一遍完整的进程生命周期，出问题就能直接定位到调用链的哪一环。

第四，善用strace来验证系统调用序列。如果程序里某个进程控制逻辑有问题，最直接的办法就是strace -f -e trace=process -p PID或strace -f -e trace=clone,execve,waitpid ./bin，一眼就能看到进程在什么时候fork、什么时候exec、什么时候waitpid卡住，不用靠猜。

Linux进程控制这个主题，说大可以写到内核源码的调度器设计，说小就是命令行的几个操作。但从实际工作的角度，就是把“看清现状、控制行为、回收资源”这三件事做到位。搞透了fork和exec的机制、信号与退出状态的关系、子进程回收的几种姿势，无论是写一个多进程服务、排查一个线上故障，还是应付面试时的一系列追问，都会顺手很多。