深度解析Linux进程创建：fork与execve的底层原理与实战

初见：为什么搞懂进程创建，必须先认识这对组合

我刚开始接触 Linux 系统编程的时候，有个问题困扰了我很久：为什么创建一个新进程这么麻烦？为什么不能像调用函数一样，喊一声“给我开个新程序”就完事了？偏偏要分两步走——先fork()复制出一个几乎一模一样的自己，再execve()把这个“复制品”彻底换掉，变成真正想跑的程序。

后来被各种诡异 bug 折磨过几轮，我才算彻底想明白：这种“分两步走”的设计，恰恰是 Unix 系统最精妙的地方之一。它把“创建一个新进程”和“运行一个新程序”这两件本来耦合在一起的事拆开了，拆成了两个可以独立使用的系统调用。fork()负责复制进程，execve()负责替换进程映像，两个兄弟各管一摊，却又紧密配合。

不管你是写服务端程序、做嵌入式开发、还是用 Go、Python 这种自带运行时的高级语言，底层进程创建的最终机制都绕不开这对组合。特别是在排查“为什么进程没起来”“为什么子进程行为诡异”“为什么资源占用不对”这类问题的时候，理解了 fork 和 execve 的真实行为，很多谜团会瞬间解开。

这篇文章就从这对兄弟的设计思路讲起，把fork()和execve()的原理、细节、实际用法和踩坑经验一次讲透。文章里所有例子我都用 C 语言写，因为只有 C 能让你看到系统调用最原始的面貌。有 Go 或 Python 经验的同学也可以对照着看，你能更好地理解自己平时写的那些“启动子进程”的代码，底层到底发生了什么。

1. 整体设计思路：一场“先复制，再换芯”的双人舞

1.1 为什么 Unix 要把“创建进程”拆成两步

很多现代系统（比如 Windows 的CreateProcess）都把创建进程设计成一个原子操作：你告诉系统“我要跑这个程序”，系统一次性搞定进程创建、内存分配、加载新程序。但 Unix 不是这么干的。它把流程拆成了fork()和execve()两个系统调用。

这里面的原因，得回溯到 Unix 诞生时期的设计哲学。当时的开发者追求的是简单、可组合——与其设计一个功能庞大的“全能启动函数”，不如把功能拆成一个个基础原语，让程序员自己组合。fork()提供一个“复制当前进程”的能力，execve()提供一个“用新程序替换当前进程”的能力。两个一组合，就能实现“运行一个新程序”的目标。

这个设计带来的一个巨大的好处是：子进程在 exec 之前，可以做任何自定义操作。比如改文件描述符、改环境变量、改信号处理方式、切换用户身份、设置进程组等等，然后再去 exec。如果是原子的“创建+执行”操作，这些中间态就很难暴露给程序员，往往需要额外的回调机制或参数传一堆配置，又复杂又死板。

1.2 fork 和 execve 这对组合的职责划分

简单来说：

• fork()：创建一个和父进程几乎一样的子进程。子进程是父进程的副本，有独立的内存空间（通过写时复制技术实现），但手里拿到了父进程大部分资源的“影印件”——文件描述符表、环境变量、信号处理器、挂载点视图等等。
• execve()：让当前进程扔掉自己正在运行的程序映像，从指定的可执行文件中加载一个新程序映像到内存，并从头开始执行。关键是进程的 PID 不变，它是一个进程内部“换人”的操作。

所以标准的流程是：

进程A 调用 fork() → 得到两个几乎一样的进程（父进程A + 子进程B） 子进程B 调用 execve() → 子进程B 变成 进程C（运行新程序） 父进程A 调用 wait() → 等待子进程结束，回收资源

我用一个生活化的类比来帮你记住：fork()相当于你打开了一个文档编辑器，按了 Ctrl+C 复制了一份一模一样的文档草稿（但这是一个独立的副本）；execve()相当于把复制出来的这个文档草稿整体替换成另一个全新的文档内容，然后从头开始编辑。两份草稿从此各走各路，互不影响。

1.3 为什么说这种设计反而更强大

假设你想启动一个程序，同时要让它的标准输入输出指向某个文件、还要设置特定的环境变量。在两步设计下，你可以这样：

pid_t pid = fork(); if (pid == 0) { // 子进程：先做各种准备工作 freopen("output.log", "w", stdout); setenv("MY_ENV", "hello", 1); // 再执行新程序 execl("/usr/bin/python3", "python3", "script.py", NULL); // 如果 exec 失败了，才会走到这里 perror("execl"); exit(1); }

这段代码清晰地展示了“先调整环境，再运行新程序”的模式。如果是一个原子化的创建函数，你要么得在一个巨大的参数结构体里塞各种配置项，要么得提供“预初始化钩子”，反而没有现在这么直接。

还有一个历史原因是效率。早期 Unix 机器资源极其有限，fork()原本是直接复制整个地址空间，其实挺慢的。后来有了写时复制技术，fork()变得极其廉价——它只是标记一下父子进程共享物理内存页面，只有当某一方真正写内存时才会触发页面复制。到了这个阶段，两步设计在性能上也完全不吃亏了。

2. 深挖 fork()：不只是“复制”，而是“分身术”

2.1 fork() 返回的“两次”到底是怎么回事

fork()可能是全 Unix 世界里最反直觉的一个系统调用：你调用它一次，它返回两次。准确地说，是在两个进程里各返回一次。

• 在父进程里，fork()返回子进程的 PID（大于0）。
• 在子进程里，fork()返回 0。
• 如果失败，返回 -1，并设置errno。

这就意味着一件事：子进程和父进程从fork()返回后，执行的下一行代码是同一个位置。代码是同一份，但进程已经是两个了。判断自己是在父进程还是子进程，唯一依据就是看返回值的差异。

#include <stdio.h> #include <unistd.h> int main() { pid_t pid = fork(); if (pid < 0) { perror("fork failed"); return 1; } if (pid == 0) { printf("我是子进程，PID=%d，我的父进程 PID=%d\n", getpid(), getppid()); } else { printf("我是父进程，PID=%d，刚创建了子进程 PID=%d\n", getpid(), pid); } printf("这句话两个进程都会执行，PID=%d\n", getpid()); return 0; }

注意，printf后面的那个输出，父子进程都会打——因为fork()之后，两个进程都在往下继续执行。这也是新手最常犯迷糊的地方：以为 fork 之后代码会分成两个分支，实际上更像是一份代码突然有了两条执行流。

2.2 子进程到底继承了哪些东西

子进程虽然是父进程的“副本”，但并不是百分百复制。继承的、不继承的，分得很清楚。

继承的主要包括：

• 用户 ID、组 ID、进程组 ID、会话 ID
• 环境变量（environ）
• 打开的文件描述符（注意：是共享同一个文件描述符引用，不是复制一份独立的引用计数）
• 当前工作目录
• 信号处理器设置（signal()/sigaction()的处置方式）
• 资源限制（ulimit相关）
• 内存映射（mmap的映射关系）

不继承（或者被重置）的主要包括：

• PID：子进程有自己的新 PID
• 父进程 PID：变成调用fork()的进程的 PID
• 未决的信号（pending signals）
• 定时器（alarm、setitimer之类的）
• 记录锁（fcntl锁）
• 子进程的 CPU 时间统计（清零）
• 父进程创建的某些有O_CLOEXEC标志的文件描述符

这里要特别强调一下文件描述符这个点。子进程继承的是父进程文件描述符表的“拷贝”，但底层引用的文件对象是同一个。这意味着如果你在父进程里打开了一个文件，文件偏移量是进程间共享的，父子进程都往里写文件，写的位置是互相覆盖的。这个行为经常导致一些难以排查的写入错乱问题。

实际项目里，我见过一个故障：父进程打开日志文件后fork()出了一个子进程，父子进程都往同一个日志文件里写东西，结果日志行互相穿插，甚至出现丢失。原因就是文件偏移量共享，两个进程互相覆盖写。解决方式要么是子进程继承后独立重新打开文件，要么在 fork 之前先确保文件已关闭或使用O_APPEND追加模式。

2.3 写时复制（COW）：fork 快的秘密

早期 Unix 的fork()是直接把父进程的全部地址空间复制一份到子进程。如果父进程占用了 1GB 内存，fork 就要复制 1GB，非常耗时。

后来引入了写时复制（Copy-on-Write，COW）技术。原理是：fork 出来的子进程不真正复制父进程的内存页面，而是共享这些页面，同时把这些页面标记为“只读”。当父子进程中任何一个试图写某个页面时，触发一个缺页异常，内核这时才真正复制那个页面（通常是 4KB 大小），然后让写操作落在复制后的新页面上。

这个机制让 fork 变得极其便宜——速度只和内存页面数量、页表大小有关，而不是和实际使用的内存大小有关。所以现在的实践里，哪怕父进程占用了几个 GB 的内存，fork 也往往在毫秒级就能完成。

这带来一个重要的启发：fork 之后，父子进程的内存是“假装共享、实际隔离”的。如果有一个全局变量在 fork 前是 100，fork 之后子进程把它改成 200，父进程的变量仍然是 100。写时复制会让你在变成“真复制”之前，用极小的代价享受“看起来像独立内存”的假象。

#include <stdio.h> #include <unistd.h> int global_var = 100; int main() { pid_t pid = fork(); if (pid == 0) { global_var = 200; // 子进程修改，触发复制 printf("子进程: global_var = %d\n", global_var); } else { sleep(1); // 确保子进程先执行 printf("父进程: global_var = %d\n", global_var); } return 0; }

输出结果必然是：

子进程: global_var = 200 父进程: global_var = 100

子进程可以任意修改自己的变量，父进程完全不受影响。这也意味着，如果想要父子进程之间共享数据，不能靠普通变量，得用进程间通信（IPC）机制，比如管道、共享内存mmap、消息队列等。

2.4 终极解决方案：vfork 是什么来头

fork()还没学透，你可能会在老代码里看到vfork()。它是fork()的一个古老变体，最初是为了在没有 COW 的 Unix 系统上更快地创建子进程。

vfork()的行为是：子进程共享父进程的地址空间（完全不复制），而且父进程会阻塞直到子进程调用execve()或_exit()。这要求在父子进程之间有一个出奇严格的约定：子进程在调用 exec 之前，不能修改任何除了临时用于保存返回值之外的全局或堆变量。

现代 Linux 的vfork()实现已经非常接近fork()+ 相关的优化，但在可移植性方面vfork()一直是个坑。我的建议是：写新代码一律别碰 vfork，直接用 fork 就足够，COW 已经让 fork 足够快了。只有在写极高性能敏感的守护进程 fork 子进程时，才考虑posix_spawn()（这个后面会提）。

3. 深挖 execve()：这是一次“换魂”

3.1 exec 家族六兄弟

你真正在代码里用的 exec 函数其实不止一个，而是一家人。它们的差异主要在于：程序参数怎么给、是否要在 PATH 里查找程序、环境变量怎么传。

名字的规则很简单：带 l（list）的是把所有参数列成一个一个地传，带 v（vector）的是把参数放进一个数组里传；带 p（path）的会去 PATH 环境变量里找可执行文件；带 e（environment）的可以显式指定新的环境变量数组。

要注意，真正发起的系统调用只有execve()这一个，其他五个都是glibc提供的包装函数，内部最终还是会调用execve()。所以当你看到execl、execvp这些写法时，心里要清楚，底层都是execve()在做实际工作。这就是为什么这篇文章标题叫“fork 的好兄弟 execve”而不是“execl”——execve 才是那个真正的系统调用，它的兄弟们只是给它递话的传令兵。

3.2 exec 成功之后，进程都发生了什么

execve()执行成功后，会发生这些事：

1. 进程映像彻底替换：当前进程的代码段、数据段、堆、栈全部被新程序替换。旧程序的代码和数据被丢弃。
2. PID 不变：进程的 PID 保持不变。从外部看，进程“换了个灵魂”，身份还是那个身份。
3. 保留打开的文件描述符：默认情况下，execve()不会关闭文件描述符，除非该描述符设置了FD_CLOEXEC标志（fcntl(fd, F_SETFD, FD_CLOEXEC)），这样 exec 时会自动关闭。
4. 保留当前工作目录、根目录：进程的工作目录不受影响。
5. 信号处理设置需要特别留意：被捕获的信号处理器会被重置为默认行为。原因是：新程序的代码可能根本不在当前进程的地址空间里，旧代码里的信号处理器函数地址已经没有意义了。但被忽略（SIG_IGN）的信号会继续保持忽略。
6. 环境变量替换：如果用的是execve/execle，环境变量数组会被你传的新数组替换。如果用的是execv/execl，则沿用当前进程的environ。
7. 内存中的锁定页面（mlock）会被解除。

最关键的是第 2 点和第 5 点。尤其是“PID 不变”这个特性，让很多监控工具看到的进程 PID 始终是同一个，即使它内部已经 exec 了好几回。

有一个很实际的问题：如果execve()成功了，那它后面的代码还会执行吗？答案是：不会。execve()一旦成功，当前进程的整个地址空间都变成新程序的了，旧程序的执行流已经不存在，所以execve()后面的任何代码都不会执行。

如果execve()后面的代码却执行了，唯一的可能只有一个：exec 失败了。所以每次调用 exec 系列函数，后面必须要跟perror()和exit()：

execl("/usr/bin/python3", "python3", "script.py", NULL); // 能走到这里只有一种可能：exec 失败了 perror("execl 失败"); exit(127);

注意这里的exit(127)，127 是 shell 里“命令未找到”等 exec 失败的常见退出码，虽然不是 POSIX 强制标准，但实际很多工具都这么用。

3.3 execve 在内核层面是怎么工作的（不那么黑盒的讲解）

execve()系统调用并不像表面看这么简单：不是“读文件，加载到内存，跳过去执行”这么直接。Linux 内核里有binfmt 处理器（binary format handler）体系，负责识别可执行文件的格式，并调用对应的加载逻辑。

常见的 binfmt 处理器有：

• binfmt_elf：处理 ELF 格式（Linux 下的主流格式，包括动态链接的可执行文件和静态链接的）
• binfmt_script：处理#!开头的脚本文件
• binfmt_misc：允许用户通过内核模块注册其他格式（比如.class文件，或者某些边角场景）

脚本文件就是一个很好的例子。你写一个 Python 脚本，开头是#!/usr/bin/python3。当你执行./script.py时：

1. 内核读文件头部，发现是#!开头。
2. binfmt_script解析出解释器/usr/bin/python3。
3. 内核把当前进程的映像替换为/usr/bin/python3这个程序。
4. 脚本文件路径作为参数传给解释器。

所以实际上，执行一个脚本最终也会变成 exec 一个解释器程序。

而在 ELF 动态链接的情况下，内核只负责：

• 读取 ELF 文件头，找到程序入口地址（e_entry）
• 设置好栈（包括参数、环境变量、辅助向量 AT_*）
• 跳转到入口

如果 ELF 是动态链接的（PT_INTERP），内核会加载指定的动态链接器/lib64/ld-linux-x86-64.so.2，真正的库加载和重定位工作由动态链接器完成，然后才会跳转到程序的main()。

这也解释了为什么execve()看起来挺快——它不负责把.so全部读进内存，这些交给了按需分页和动态链接器。

3.4 execve 执行失败常见的坑

在服务器上写 C 程序时，execve()的失败是常客。常见的失败原因和排查手顺：

1. ENOENT（2）：文件不存在。排查是否路径写错。如果使用了带 p 的execvp/execlp，要确认PATH环境变量是否正确。
2. EACCES（13）：没有执行权限。排查文件权限位ls -l，确认有x权限；如果是脚本文件，还要确认解释器本身有执行权限。
3. ENOEXEC（8）：文件格式错误。常见于把数据文件、损坏的 ELF、或者给非可执行文件加了执行权限去 exec。有时候脚本文件没有#!行，内核也会尝试用execve失败后返回这个值，这时glibc 的execlp/execvp会退化为用/bin/sh去执行该文件。
4. ETXTBSY（26）：可执行文件正在被写入。这通常是因为你在程序运行时覆盖它的二进制文件。解决：先删除再拷入，或者用git、make等工具处理好文件替换流程。
5. 找不到动态链接器：ELF 文件被设置了PT_INTERP指向一个不存在的动态链接器，最典型的是readelf -l 可执行文件 | grep INTERP看到路径不对。

对这些错误，最直接的手段就是在 exec 之后马上perror并退出，把错误打出来。很多隐蔽的问题就藏在“返回失败但是却被忽略”的代码里。

4. 实操：从 fork 到 execve 的完整过程拆解

4.1 最经典的“fork + exec + wait”三件套

实际生产环境里，fork()和execve()通常会和wait()（或waitpid()）搭配出现。父进程创建子进程后，往往需要等待子进程执行完毕，回收其资源，避免产生“僵尸进程”。

看一个最小但完整的例子——父进程 fork 出子进程，子进程 exec 运行ls -l，父进程等待并获取子进程退出状态：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/wait.h> int main() { pid_t pid = fork(); if (pid < 0) { perror("fork failed"); exit(1); } if (pid == 0) { // ---- 子进程 ---- printf("子进程(PID=%d)开始执行 ls -l\n", getpid()); execl("/bin/ls", "ls", "-l", NULL); // 只有 exec 失败才会走到这里 perror("execl 失败"); exit(127); } else { // ---- 父进程 ---- int status; pid_t child_pid = waitpid(pid, &status, 0); if (child_pid == -1) { perror("waitpid failed"); exit(1); } if (WIFEXITED(status)) { printf("子进程正常退出，退出码=%d\n", WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf("子进程被信号 %d 杀死\n", WTERMSIG(status)); } } return 0; }

这个例子里有几个细节值得注意：

• execl("/bin/ls", "ls", "-l", NULL)第一个参数是完整路径，第二个参数是argv[0]（进程名），第三个是-l，最后必须用NULL结尾。
• 子进程执行execl时，printf的缓冲区问题可能会坑到你（后面详细说）。
• waitpid的第一个参数传子进程 PID，可以精确等待某个子进程。如果传 -1，则等待任意子进程。
• WIFEXITED和WIFSIGNALED是宏观判断子进程退出状况的宏，非常推荐熟练掌握。

4.2 一个被很多新手忽略的坑：stdio 缓冲区

这是一个我踩过不止一次的坑。看下面这段代码：

#include <stdio.h> #include <unistd.h> int main() { printf("准备 fork...\n"); pid_t pid = fork(); if (pid == 0) { execl("/bin/echo", "echo", "子进程 exec 成功", NULL); perror("execl 失败"); exit(1); } // 父进程继续 sleep(1); printf("父进程结束\n"); return 0; }

你猜输出是什么？是“准备 fork...”打印了一次还是两次？

答案：取决于标准输出是否连接终端。如果你在终端直接运行，输出是一行“准备 fork...”——printf默认行缓冲，遇到换行符已经刷出去了，fork 之后缓冲区是空的。但如果你的输出是重定向到文件（./a.out > log.txt），printf就变成全缓冲了，“准备 fork...”只是写进了 stdio 缓冲区，并没有真正写出去。fork 时，这个缓冲区被完整继承到了子进程。子进程 exec 后，stdio 缓冲区会被丢弃（glibc 会处理 CLOEXEC 相关的清理，但缓冲区里的数据就没了），而父进程在 sleep 后才 flush，所以你最终看到的文件内容里可能丢失了第一次 printf 的内容，或者出现乱序。

这类 bug 的排查方式很简单：在 fork 之前调用fflush(NULL)，把所有打开的 stdio 流都刷出去。或者，如果你只是想写日志，直接用write(2)系统调用（无缓冲）代替printf。再或者，在 fork 之后立即考虑在子进程中用setvbuf或者干脆_exit之前fflush。

这里我给一条铁律：任何在 fork 之前的输出，都养成写完之后fflush(NULL)的习惯。这样能避开九成的诡异重复输出或者丢失输出问题。

4.3 在 exec 之前“做赛前准备”：文件描述符操作

exec 之前，子进程可以做很多有用的准备工作。最常见的是重定向标准输入输出。

比如我们要实现一个“运行外部命令并把输出写到文件里”的小工具，可以这样：

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <fcntl.h> #include <sys/wait.h> int main() { pid_t pid = fork(); if (pid == 0) { // 子进程：准备重定向 int fd = open("output.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd < 0) { perror("open failed"); exit(1); } // 把标准输出 1 重定向到 fd dup2(fd, STDOUT_FILENO); close(fd); // 执行新程序，它的标准输出会写到 output.txt execl("/bin/ls", "ls", "-l", NULL); perror("execl 失败"); exit(127); } // 父进程等待 waitpid(pid, NULL, 0); printf("执行完成\n"); return 0; }

这里的核心是dup2(fd, STDOUT_FILENO)——把 fd 复制到文件描述符 1 上，同时关闭文件描述符1原来指向的东西。之后close(fd)关闭原来的 fd（因为环境里已经有了一份指向同一文件的描述符 1），程序再执行ls，它的write(1, ...)就会把数据写到output.txt里。

这是一个非常典型的“fork 之后、exec 之前”的自定义操作。如果没有两步设计，这种“标准输出重定向”功能就得作为CreateProcess的一个复杂参数传进去，想想就头大。

另外关于FD_CLOEXEC，我再多说一句。如果你不想让某个文件描述符被子进程 exec 时继承，可以在 open 的时候就带上O_CLOEXEC，这几乎能杜绝一些安全问题（比如 exec 一个外部程序后，它意外继承了某些敏感 fd）。当fork()之后立即exec时，这是一个值得养成的习惯。

4.4 为什么不直接用 system()？

很多新手会问：不是有system("ls -l")吗？我直接用system()不就行了？

system()的实现本质上就是“fork + execl(/bin/sh, "sh", "-c", command) + waitpid”。所以它的上层使用很简单，但它有几个明显的缺点：

• 它会把命令交给/bin/sh解析，而 shell 解析规则里可能包含你意想不到的展开、替换、通配符行为。
• system()会阻塞等待命令执行完成，不适合需要并发启动多个子进程的场景。
• 信号处理方面有坑：system()在等待时会忽略 SIGINT 和 SIGQUIT，这可能影响交互程序的行为。
• 它不开箱支持“exec 之前的准备工作”，比如重定向、设置环境变量、改用户 ID 等，需要再包一层子 shell 来做，增加复杂度和安全风险。

所以如果你的程序需要的是“启动一个新程序，并精细控制它的运行环境”，fork + execve其实才是更可控、更符合底层机制的做法。system()适合的只是临时跑一条命令、不管细节的场景。

4.5 posix_spawn()：一个“原子化”的备选

posix_spawn()是 POSIX 标准里的一个较新的接口，它把“fork + exec”的步骤包装成一个函数调用，避免在复杂程序里手动 fork 的诸多坑。它在很多场景下（特别是高性能、嵌入式、以及不能在 fork/vfork 后做很多操作的受限环境）很受欢迎。

它的用法大致是：

#include <spawn.h> #include <stdio.h> #include <stdlib.h> #include <sys/wait.h> extern char **environ; int main() { pid_t pid; // 构造参数数组 char *argv[] = {"ls", "-l", NULL}; // 执行 spawn int ret = posix_spawn(&pid, "/bin/ls", NULL, NULL, argv, environ); if (ret != 0) { perror("posix_spawn 失败"); return 1; } waitpid(pid, NULL, 0); printf("done\n"); return 0; }

posix_spawn底层的执行逻辑在不同平台上可能有差异，但在 Linux 上，glibc 的实现通常是先创建子进程，再在子进程里 exec。它用起来简单、看起来是“一次调用完成”，而且避免了手动 fork 时的一些隐患（比如在复杂、多线程程序中 fork 之后马上调用非 async-signal-safe 的标准库函数，这是未定义行为）。

做后端高性能计算的朋友，如果不想用 fork，可以认真考虑posix_spawn。但对大多数场景而言，掌握fork + execve仍然是最根本的能力——毕竟很多系统的批处理脚本、守护进程、容器运行时，底层就是这套老组合。

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

5.1 为什么 exec 之后 printf 的输出没了

现象：程序里printf("Starting...")然后 fork、exec，最后输出文件里看不到这行日志。

原因：标准输出被重定向到文件时是全缓冲，printf的内容还留在 stdio 缓冲区里，fork 时被子进程继承，exec 时缓冲区被丢弃。父进程继续运行后，如果它自己没有及时 flush，这些日志就丢了。

解决：

• 在fork()之前调用fflush(NULL)，强制刷出所有 stdio 缓冲区。
• 或者对日志输出，直接用write(2)系统调用。
• 或者在子进程 exec 之前_exit()（而不是exit()），避免缓冲区被双重 flush 产生双重输出。

5.2 为什么出现了“僵尸进程”

现象：ps里看到一堆defunct或<defunct>状态的进程。

原因：子进程结束了，但父进程没有调用wait()/waitpid()回收它的退出状态。内核会保持该进程的 PCB 数据（比如退出码），直到父进程来取。这个状态就是僵尸。

解决：父进程用waitpid等待子进程；或者忽略 SIGCHLD（signal(SIGCHLD, SIG_IGN)），让内核自动回收；或者在多线程程序里专门开一个线程循环waitpid(-1, &status, WNOHANG)。

补充一句：如果父进程先死了，子进程会被init进程（PID 1）收养，由 init 负责回收。所以只有父进程还活着却不管子进程，僵尸数量才会堆积。

5.3 为什么 execve 提示 “Text file busy”

现象：execve("/path/to/prog", ...)返回ETXTBSY。

原因：可执行文件正被某个进程打开写（比如正在用编辑器写、正在被cp覆盖、或者在容器里被 bind mount 成可写文件等）。内核为了避免“边写边执行”造成不可预期行为，直接拒绝 exec。

解决：等待写入完成再 exec；更好的做法是“写临时文件 + rename”，这样 exec 的是一个完整文件而不是一个写入到一半的文件。如果你用make编译，编译和运行之间如果出现这个错误，多半是调试器或某个工具正握着这个文件句柄。

5.4 execve 成功了，但子进程的退出码不是我预期的

现象：子进程应该返回 0，但父进程用WEXITSTATUS得到 127 或 1。

思路：

• 127 通常意味着 shell 找不到命令或 exec 失败。如果你用的是execlp/execvp且PATH里面有多个同名命令，可能是执行到了错误的版本。
• 1 或其他退出码，是程序自身的main()返回或exit()参数。可以先在子进程 exec 失败分支加fprintf(stderr, "errno=%d (%s)\n", errno, strerror(errno))，从而把错误原因打出来。
• 还有一种可能：你调用的程序会去读某个环境变量、配置文件，但子进程里环境变量不满足（比如没有正确的HOME），程序启动失败退出。排查时可以在子进程里打环境变量快照，确认。

5.5 多线程程序里 fork 之后直接调用 printf / malloc 会不会有问题

现象：多线程程序 fork 出的子进程经常会死锁或崩溃。

原因：fork 只会复制当前调用线程，其他线程全部消失。如果别的线程在 fork 那一刻正持有锁（比如 malloc 的堆锁、printf 的 stdio 锁），子进程里的锁状态就是“被某个不存在的线程持有”，后续任何上锁操作都会死锁。

这是 POSIX 规定的一个大坑：fork 出来的子进程，在 exec 之前只能调用 async-signal-safe 函数（比如write(2)、_exit），绝对不要去调用printf、malloc、pthread_*这类函数。

如果你的程序是多线程的，又想启动子进程，最优解是直接用posix_spawn()，或者安排一个专门的“管理线程”负责 fork，尽量缩短 fork 后、exec 前的代码路径，任何非轻量操作都不要做。

这里附一个可以安全调用的临时“调试打印”技巧：用write(2)直接往 stderr 写字节，因为 write 是 async-signal-safe 的。

// 子进程 exec 前的临时调试方法 write(STDERR_FILENO, "child before exec\n", 19);

5.6 fork 之后子进程里修改环境变量，对父进程有无影响

子进程通过setenv、putenv修改的环境变量，只影响子进程，不会影响父进程。原因很简单：环境变量存在于进程自己的地址空间（栈顶区域），fork 时已经各自持有独立的副本。

但有例外：如果父子进程之间通过mmap共享内存，那么共享的那段内存是真正共享的，一方的修改对另一方可见。这也是为什么 IPC 都要靠共享内存、管道之类的机制，普通变量不能跨进程共享。

5.7 为什么有时候ssh、systemd里看到的 “fork of unprivileged child failed”

在网络热词里有这么一条：windows ssh fatal: fork of unprivileged child failed。这其实是 Windows 上 OpenSSH 的报错，但报错术语借用了 POSIX 的称呼。它通常和系统资源受限（句柄耗尽、内存不足、并发连接数超过限制）相关。

虽然这篇文章不讲 Windows 的 ssh，但它提醒我们一个通性：fork()失败的常见原因就是资源不够。线上排查 fork 失败的思路应该是：

1. 先看errno。EAGAIN表示资源限制，比如达到ulimit -u（进程数上限）、线程数限制、内存不足。
2. 用ulimit -u和cat /proc/sys/kernel/threads-max、cat /proc/sys/vm/max_map_count检查限制。
3. 检查PID 是否耗尽：cat /proc/sys/kernel/pid_max。
4. 检查进程数量：ps -eLf | wc -l。

5.8 速查表：fork 与 execve 常见错误一览

6. 把这对兄弟放进更大的图景里

讲完细节，再说点宏观层面的启发。

fork()和execve()的组合，不只是系统编程知识，它对整个软件架构的影响都很深。

Shell 就是最典型的 fork+exec 消费者。你每在终端敲一条命令，shell 都会 fork 出一个子进程，然后让子进程 exec 你敲的命令，shell 自己则阻塞在 waitpid 上等命令结束。如果你想“后台执行”，shell 就不等它，直接让命令在子进程里跑着。这个模型极其优雅。

容器技术也离不开这套组合。容器运行时（比如 runc、containerd）启动一个容器，本质上会经历一套标准的 fork/exec 流程：父进程创建容器进程（可能会通过 clone 系统调用来创建新的命名空间），然后该进程 exec 进入 OCI 运行时，再 exec 进入容器内的主进程。这些步骤和我们这篇文章讨论的“fork 后换芯”没有本质区别，只是多了一层命名空间和 cgroup 的配置。

进程池、任务调度的底层，也全靠 fork/exec。在网络热词里看到了“进程池”，它的含义就是预创建一批进程，通过 IPC 分发任务，从而避免频繁的创建销毁开销。假设每个任务都走一遍 fork，在 COW 帮助下其实也很便宜，但进程池能做得更极致：进程只创建一次，任务来了就直接发消息处理，连 exec 都省了。在需要启动大量短生命周期命令的场景（比如 CI/CD 跑批量任务），进程池的价值极其明显。

监控一个进程的“创建、运行、结束”全生命周期，本质上是监控 fork/exec 系统调用。像strace -f -e fork,execve就能拿到完整调用链，很多排查场景都用得上。

最后分享一个小经验。在处理“某个进程启动后没有窗口”“进程在后台默默运行但界面没出来”这类问题的时候（比如 ChatGPT 桌面端启动后只有进程没有窗口这类高热度问题），第一步要做的就是用ps -ef确认进程是否真实存在，第二步用cat /proc/<pid>/status看进程状态，第三步再看它是否 exec 成功了（/proc/<pid>/exe软链接指向谁）。如果进程存在但是界面没有出来，通常不是 fork 的问题，而是 exec 之后新程序初始化失败，或者主进程 fork 出了子进程但界面进程崩了。这种排查思路，本质上还是围绕“进程创建”来展开的。

回到这对兄弟，我个人觉得最有价值的收获是：不要喧宾夺主。fork()很酷，execve()也很酷，但它们组合起来才是一个完整的“启动一个程序”的能力。写代码时也不要把 fork 当作制造并发的灵丹妙药，而应该把它当成“一次性创造进程实例”的工具。如果之后还需要线程并发，那就用pthread，别再 fork 一气了——毕竟线程和进程的适用场景，从创建成本到资源共享模型都不相同。

根据我的实际经验，想要真正把这些内容变成自己的肌肉记忆，可以做这几个小练习：

1. 手写一个简化版的 shell：读取用户输入的命令，用fork + execvp + waitpid执行它。做完这个，你对这对组合的理解会指数级提升。
2. 写一个多进程并发下载小工具：主进程用 fork 创建 N 个子进程，每个子进程 exec 一个wget或curl去下载不同文件，主进程负责统计结束状态。
3. 用strace -f跟踪一个你日常使用的命令（比如ls或date），看看它的进程创建和 exec 轨迹。这件事做一次，胜过我写十段八段理论说明。

源码面前，了无秘密。把 pair 这对兄弟吃透之后，Linux 的进程世界对你来说就基本是透明的了。