企业官网建设流程全解析

先问个问题：你在生产环境里有没有遇到过这种场景——程序运行得好好的，突然就退了，日志里什么都没留下；或者某个后台进程莫名其妙没了，但你觉得它“不应该会退出”。如果你第一反应是去看业务逻辑、查代码死循环，那我建议你先查一下信号。

为什么？因为在 Linux 世界里，进程的生死很多时候根本不是由代码逻辑决定的，而是由信号决定的。Linux进程信号是整个系统通知进程“有事发生”的核心机制，也是排查很多诡异问题的第一入口。不管你做后端、做嵌入式、还是做运维，理解信号机制都绕不开，而且这块东西如果不深入，总会在某个凌晨两点的大规模故障里等着你。

这篇文章我会从一个实际的排查过程切入，把信号的产生、传递、处理、阻塞，再到多线程环境下的特殊行为，全部拆开讲一遍。重点不是背 API，而是搞清楚信号这玩意在系统里到底是怎么流动的，以及我们平时写的代码里，哪些“习惯性写法”其实正在埋雷。适合所有在 Linux 下写 C/C++、Go 或者做运维的朋友，新手也能跟着走一遍。

1. 信号是“软件的异常”，但它比硬件异常更常见

先想一个问题：当一个进程访问了非法内存地址，接下来发生的是什么？你可能会说“段错误”，但更底层的事实是——CPU 发现这个访问有问题，操作系统内核收到这个异常之后，向进程发送一个 SIGSEGV 信号。进程如果没有捕获这个信号，默认动作就是终止并生成 core 文件。

所以，信号可以理解成是内核向进程发出的一种通知：“你摊上事了，自己看着办”。只不过这个“事”的来源特别多，不只是硬件异常，还有可能是另一个进程、一个终端按键、甚至是你自己。

1.1 从一个“程序突然没了”的现场说起

有一次我们有个数据处理模块，运行在凌晨的定时任务里，时不时就丢两个任务，没有任何日志输出。因为任务是被一个守护进程统一拉起的，我们第一反应是看守护进程的日志，结果什么都没有。后来在系统日志里看到一个关键句子：

Out of memory: Kill process 12345 (data_worker) score 450 or sacrifice child

瞬间明白了——这不是业务代码崩了，是内核的 OOM Killer 直接把进程处决了，而它处决的方式就是发一个 SIGKILL 信号。SIGKILL 是什么级别？它不可捕获、不可阻塞、不可忽略，一旦发给进程，内核直接终结它。所以你那套优雅退出的逻辑、清理临时文件的钩子，全都没机会执行。

从这件事我学到的第一个教训是：排查程序莫名退出，第一步永远先看信号。看哪个信号、谁发的、为什么发，比一头扎进代码里靠谱得多。

怎么查？最直接的方式就是用-1参数拉起进程，比如：

./data_worker &

然后随时看：

cat /proc/<pid>/status | grep -E "Sig(Blk|Ign|Cgt|Pnd)"

这里面的信息量很大，SigBlk 是当前阻塞的信号集合，SigIgn 是被忽略的信号集合，SigCgt 是已经注册了处理函数的信号集合，SigPnd 是有待处理信号集合。你甚至不用写代码，就能知道这个进程目前在信号方面是什么状态。

1.2 信号是从哪来的：不同来源决定你怎么排查

信号可以产生自硬件，也可以产生自软件，还可以产生自终端。它们的来源决定了我们排查问题的方向。

硬件来源最常见的就是非法内存访问、除零、非法指令。这类信号往往意味着代码里的逻辑 bug，比如野指针、数组越界、未初始化变量参与运算。排查方向自然是内存检查和代码审查，工具上可以用 AddressSanitizer 或者 Valgrind 一类的东西帮忙定位。

软件来源就五花八门了。可能是其他进程用 kill 系统调用主动发过来的，可能是你调用 raise 或 abort 自己给自己发的，也可能是定时器到期之后内核帮你发一个 SIGALRM。这一类信号一般代表着某种“协作”，比如主进程通知子进程重新加载配置、用户手动让某个服务优雅退出。

终端来源就是我们常见的 Ctrl+C 发送 SIGINT、Ctrl+Z 发送 SIGTSTP、Ctrl+\ 发送 SIGQUIT。注意这里有一个细节：当你按下 Ctrl+C 的时候，不是内核直接发给进程，而是终端的驱动层收到这个按键之后，把它转成信号发送给前台进程组。所以一个进程能不能收到这个信号，取决于它是不是前台进程，以及它所在的进程组是哪个。

1.3 常见的信号表：默认动作必须心里有数

信号有一大堆，没必要全背，但常见的那十来个你最好烂熟于心。我列了一个整理过的表格，加粗的是默认动作，方便你对照：

有几个容易搞混的地方值得单独说一下。

SIGPIPE 这个很多人忽略，但它其实非常阴险。你在一个网络服务进程里往一个已经关闭的 socket 写数据，第一次写可能没事，因为数据先进了缓冲区，等内核真正尝试发送时发现对端已经关闭，这个时候就会收到 SIGPIPE。如果你没处理它，进程直接退出，这就是很多 HTTP 服务莫名其妙“闪退”的原因之一。Nginx 这类高并发服务器在自己的事件循环里都是显式忽略或专门处理 SIGPIPE 的。

SIGCHLD 的默认动作是忽略，但请注意“忽略”不等于“不通知”。子进程退出时，父进程会收到 SIGCHLD，不需要主动去接受什么，这个是自动的。只不过默认没人管它，子进程就会变成僵尸进程，直到父进程调用 wait/waitpid 回收。这块内容后面我会专门讲。

还有 SIGCONT 和 SIGSTOP 这对互相配合的信号。SIGSTOP 可以把进程冻结，SIGCONT 可以让它恢复。但有意思的是，SIGSTOP 和 SIGKILL 一样，都不能被捕获或阻塞——内核不让进程自己挡住“冻结”和“处决”这两个权力。

这里给新手一个最简单的心法：默认动作就是“不写任何代码时的行为结果”。你只需要记住哪些信号默认让你退出、哪些默认让你暂停、哪些默认当作没看见，排查问题时就心里有谱了。

2. 捕获信号不是“写个回调函数”那么简单：sigaction 是唯一推荐入口

如果你在进程里想对某个信号做自定义处理，标准姿势是注册一个信号处理函数（handler）。C 语言里有老掉牙的 signal() 函数和现代的 sigaction() 函数，国内很多教材还在讲 signal()，但我在实际工程里几乎从来不用它。为什么？因为 signal() 的行为在不同系统、不同版本上存在历史遗留差异，特别是它处理“信号到达时当前正在执行另一个处理器”的情况时，细节特别容易踩坑。

2.1 signal() 与 sigaction() 的核心差异

signal() 的经典问题之一，是某些系统在处理器执行完毕后，会把信号处理方式重置为默认行为。这意味着如果同一个信号连续来两次，第二次可能直接触发默认动作——进程退出。

更要命的是，signal() 在处理信号期间，并不会自动阻塞同类信号的再次到达。也就是说，你的处理器刚执行到一半，同一个信号又能打断你一次，形成递归触发。这在真实项目里是极其危险的，处理器的栈很容易被打爆，或者逻辑出现不可预期的情况。

而 sigaction() 通过一个结构体把什么都配置清楚了：处理器函数、处理期间要额外阻塞哪些信号、是否需要 SA_RESTART 让被中断的系统调用自动重启，以及一些更细的标志位。

我把两者的核心行为差异做成一个对比：

所以结论就一个：新代码一律使用 sigaction()。signal() 只适合在非常简单的脚本级程序里凑合一下，工程代码用它会给自己埋坑。

2.2 sigaction() 最小的完整用法

我直接给一段可以照着用的代码，风格上我习惯把这些信号处理的代码封装成一个独立模块。

#include <stdio.h> #include <signal.h> #include <string.h> #include <unistd.h> static volatile sig_atomic_t g_flag = 0; static void handle_signal(int sig) { // 在信号处理函数里，保证只做异步信号安全的事 g_flag = sig; } int main(void) { struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_handler = handle_signal; // 处理器执行期间，阻塞 SIGINT 的再次到达 sigemptyset(&sa.sa_mask); sigaddset(&sa.sa_mask, SIGINT); // 让被信号中断的 read/accept 等系统调用自动重启 sa.sa_flags = SA_RESTART; if (sigaction(SIGINT, &sa, NULL) == -1) { perror("sigaction"); return 1; } printf("PID: %d, 按 Ctrl+C 试试\n", getpid()); while (1) { pause(); // 进程挂起直到收到信号 if (g_flag == SIGINT) { printf("收到 SIGINT，做清理工作...\n"); break; } } return 0; }

这段代码里有几个细节不是随便写的。

volatile sig_atomic_t类型，不是随便用的普通 int。它保证读写是原子操作，并且告诉编译器不要在优化时对这块内存做不合理的假设——这在处理器和主循环之间共享标志位时是必须的。

sigemptyset先把掩码集合清零再sigaddset往里面加信号，这个顺序要养成习惯，不要直接往一个未初始化的集合里加信号。

SA_RESTART这个标志，简单说就是让某个被信号打断的系统调用（比如在read一个慢速设备时收到信号）在信号处理完之后自动从头重试，而不是返回一个 EINTR 错误。设不设它，直接影响你程序里的 I/O 代码要不要额外判断errno == EINTR。

2.3 SA_RESTART 和 EINTR：无数人栽在这里

我见过一个实际案例：某公司的网络代理模块，在接到 SIGTERM 之后想优雅退出——先停止接收新连接，再把已有的连接慢慢处理完。结果程序在退出过程中，主线程明明阻塞在accept()上，收到信号之后accept()却直接返回了 -1，错误码是 EINTR。代码里没有对这个情况做处理，于是程序就把“没有新连接”当成“连接出错”，直接异常退出了。

为什么会这样？因为默认情况下，某些慢速系统调用（比如accept、read、write、wait）在等待过程中如果被信号打断，不会自动恢复执行，而是返回 -1，同时置errno为 EINTR。如果你的代码对这种情况没有像下面这样处理，就以为系统出错而退出：

// 常见做法一：遇到 EINTR 就重试 while (1) { n = accept(fd, (struct sockaddr*)&addr, &len); if (n < 0 && errno == EINTR) { continue; // 被信号打断，重试 } if (n < 0) { perror("accept"); break; } break; }

而设置SA_RESTART就是让内核帮你在多数情况下自动重试，省去这层判断。但这里有一个非常关键的坑：不是所有系统调用都支持 SA_RESTART 重启。

像select、poll、epoll_wait、sigsuspend、nanosleep、clock_nanosleep、sem_wait这类函数，即使设置了 SA_RESTART，依然会在被信号打断时返回 EINTR。为什么？因为它们设计之初就不确定“继续等待”和“从等待中恢复”哪个更合理，所以把决定权交回给调用者。

这也就是说，你写 I/O 密集型的服务时，任何阻塞系统调用最好都做好 errno == EINTR 的处理，不管你设不设 SA_RESTART。我一直要求自己代码里每一个涉及阻塞等待的地方，都必须明确回答一个问题：如果这里收到一个信号，进程应该怎么办？是重试、继续等待，还是立刻退出？想清楚再写代码。

2.4 信号处理器里能不能用 printf：async-signal-safe 函数清单

这是新手最常见的疑惑：既然处理器函数是 C 语言写的，里面总该可以随便调用库函数吧？

答案是大写的“不行”。信号处理函数可能在一个完全不安全的时机插入执行——比如正在调malloc，正在操作某个全局链表，正在执行 printf 内部的缓冲操作。如果处理器里也调用了这些函数，轻则数据损坏，重则死锁、崩溃。

POSIX 标准给出了一个 async-signal-safe 函数清单，意思是这些函数在信号处理函数中使用是安全的，常见的包括write、read、open、close、osync族、sigaction、_exit等。要注意的是，printf、malloc、free、pthread 系列函数都不在这个清单里。

所以工程上的做法通常是：

• 处理器里只设置标志位（volatile sig_atomic_t）；
• 主循环发现标志位置位之后，再去做实际的清理工作、打印日志、释放资源；
• 如果实在需要在处理器里做日志，用write直接往文件描述符里写字符串，不要用printf。

我自己用过一个比较取巧的办法：处理器里write往一个自建的管道写一个字节，主循环在 epoll/select 里监听这个管道的读端。信号一来，管道的读端变可读，主循环自然被唤醒，然后可以安全地做任何事。这就是经典的“信号自管道”（self-pipe trick），很多开源项目里都能见到，兼顾了安全和简单。

3. 阻塞、未决与排队：标准信号和实时信号的本质差异

很多人对信号的认知只停留在“捕获和忽略”这两个层面，但真正让信号机制复杂的，是“阻塞”和“未决”这两个状态。你哪怕不写任何处理代码，内核也会为你维护两套信号状态集合，理解它们的意义，你才真正理解信号。

3.1 阻塞集合与未决集合：信号被“扣下”的过程

每个进程都有两个关键的信号状态集合：阻塞集合（blocked set）和未决集合（pending set）。

阻塞集合也叫信号掩码（signal mask），它表示“哪些信号我不想现在处理”。注意，阻塞和忽略完全是两回事。忽略是接收到了但当作没看见；阻塞是接收到了但先扣在内核的队列里，等到解除阻塞那一刻再补发给你。

未决集合就是内核帮你“扣下”的信号集合。当你调用sigprocmask或pthread_sigmask把某个信号加入阻塞集合，后面这个信号来了，内核不会调用它的处理器，而是先把信号挂到该进程的 pending 集合里。直到你解除阻塞或者显式地sigsuspend去等待，信号才会被“补送”。

一句话总结这个管线：

信号产生 →（检查是否阻塞）→ 未决集合 →（解除阻塞或等待）→ 递送到处理器

你可以在/proc/<pid>/status文件里直接查看进程当前的这两个集合：

SigBlk: 0000000000000000 SigIgn: 0000000000000000 SigCgt: 0000000000000100 SigPnd: 0000000000000000

右边的十六进制数按位展开，每一位代表一个信号。这组数字对排查问题特别有用——如果一个进程卡住了，而 SigPnd 里某一位不为零，就说明有个信号已经送到了但被阻塞着，始终没人处理。这通常是死锁的前兆。

3.2 标准信号的丢失问题和实时信号的排队与数据携带

这里有个非常非常重要的事实：标准信号是“不排队”的。

什么意思？如果同一个信号在一个进程还没来得及处理的情况下被连续发送了十次，内核的 pending 集合只是一个位图，每个标准信号只占一位。所以十次发送在进程“看”来只相当于一次，中间的九次全都合并、丢失了。

这个问题在进程里有多个相同来源的信号源时会显得特别明显。比如你用setitimer定时器每隔 50ms 发一次 SIGALRM，但你的处理器一次就要耗时 200ms 才能跑完，那么在你处理的过程中，新到的 SIGALRM 就会被合并成“还有一次”，等当前这轮处理完再补一次，再来的继续合并。

Linux 解决这个问题的方法是引入了实时信号（Realtime Signal）。实时信号的编号范围是从 SIGRTMIN 到 SIGRTMAX，在主流 Linux x86-64 上一般是 34 到 64。实时信号是可以排队的，而且每个实时信号实例还支持携带一个整数或者指针值，发送方用sigqueue系统调用把数据一块发过去，接收方用 SA_SIGINFO 标志注册处理器，从siginfo_t结构里把数据取出来。

所以当你面临“需要可靠地发送频繁事件并携带数据”的场景时，标准信号是力不从心的，实时信号才是正解。不过实时信号数量有限，从 34 到 64 一共 31 个（某些架构可能略有差异），用之前要规划好分配，别贪心。

3.3 阻塞和解除阻塞的实际代码：千万别忘在 fork 之后重置掩码

阻塞信号最常见的场景是：程序启动早期，很多资源还没初始化完成，不希望某个信号打断初始化流程，于是先把一组信号阻塞起来，等初始化完成再解除。

sigset_t newmask, oldmask; sigemptyset(&newmask); sigaddset(&newmask, SIGTERM); // 阻塞 SIGTERM sigprocmask(SIG_BLOCK, &newmask, &oldmask); // 记录旧掩码 // 这里做初始化工作，即使有人发 SIGTERM 也不会立刻中断 sigprocmask(SIG_SETMASK, &oldmask, NULL); // 恢复旧掩码

这段代码本身不复杂，真正复杂的是它的传播问题。如果这个进程里还调用了fork，那么子进程会继承父进程当前的信号掩码，包括你刚设的各种阻塞。如果你在子进程里没有恢复掩码，而子进程恰好是个业务执行体，它可能对其他进程发来的 SIGTERM 毫无反应，甚至无法正常退出。

正确做法是：在fork之后的子进程中，立刻判断是否要恢复默认掩码，或者干脆用sigprocmask把掩码重置。这里我提供一个工程建议：凡是会派生子进程的程序，在子进程执行任何非 trivial 业务之前，把信号掩码恢复为全空（或明确设为已知状态），否则一个“干净的”子进程可能带着一堆不合理的阻塞信号开始干活。

3.4 sigsuspend：原子地等待信号到达

还有一个接口值得专门说——sigsuspend。它做的事情是：用给定的掩码替代当前进程的阻塞集合，然后挂起进程，直到一个未被阻塞的信号到达并触发处理器，之后恢复原来的掩码。

为什么需要这个？因为如果你按顺序分两步走，先sigprocmask(SIG_SETMASK, &mask)再pause()，中间有一个时间窗口，信号可能会在两者之间到达——你可能在恢复掩码之前就把这个信号错过了。而sigsuspend把“设置掩码并挂起等待”变成一个原子操作，不会漏信号。

我在写一个需要串行处理信号的应用时，经常会用这样的模式：把所有要处理的信号阻塞住，然后在一个循环里调用sigsuspend等待，信号到达后立即恢复阻塞再执行处理逻辑，做完之后再次调用sigsuspend。这样能保证同一时刻最多只有一个信号处理器在执行，规避了大量重入和并发问题。

4. 多线程程序里的信号：发的究竟是“进程”还是“线程”？

这部分是真正容易把很多人绕晕的地方，也是面试里问到 Linux 进程信号时最常见的进阶题点。多线程环境下，信号不再只是“发给进程”那么简单。你得搞清楚：信号到底是发给了进程，还是发给了线程？谁会收到，谁有资格处理？

4.1 进程定向信号与线程定向信号

按 POSIX 的说法，信号既可以是进程定向的，也可以是线程定向的。

最常见的kill(pid, sig)发送的就是进程定向信号。对内核来说，进程其实是“线程组”，它会把信号投递给该线程组中某个满足条件的线程。什么样的线程算满足条件？首先，该线程没有阻塞这个信号；如果有多个线程都没阻塞，内核一般选择其中一个——通常是主线程，但这不是绝对的。

而pthread_kill(pthread_t, sig)发送的是线程定向信号，它明确地指定发给那个线程。注意，线程定向信号也会触发默认动作，比如你发给某个线程 SIGTERM，如果它没处理，那整个进程都会终止，不要以为“只终止这个线程”。

那内核如何决定信号发给谁？判断优先级大致如下：对于进程定向信号，内核先检查所有线程的掩码，去掉阻塞了这个信号的线程，从剩余线程中选一个投递；如果所有线程都阻塞了这个信号，就放到进程的 pending 信号队列里，然后哪个线程一旦解除阻塞，信号就投递给谁。

这个设计带来的实际问题是：信号处理器的执行线程是不确定的。你无法保证它一定在主线程或其他特定线程里执行。如果你的处理器函数访问了某些“线程专属数据”，比如 TLS、线程局部存储，或者在一个持有锁的线程里操作了其他线程的资源，就会出现极其隐蔽的并发问题。

4.2 pthread_sigmask：线程级信号掩码的隔离

多线程程序里，每个线程都有自己的信号掩码。这个掩码是用pthread_sigmask设置的，不是sigprocmask。sigprocmask在多线程环境下的行为是未定义的，POSIX 明确要求多线程程序使用pthread_sigmask。

进程序号线程各自的掩码之间是什么关系？当发送一个进程定向信号时，内核检查所有线程的掩码，找到一个不阻塞它的线程投递。但如果某个线程通过pthread_sigmask阻塞了这个信号，而其他线程没有阻塞，那么这个信号仍然会被其他线程接收——也就是说，一个线程的阻塞并不会影响信号被整个进程“收到”。

反过来，如果你想确保某个信号只被特定线程处理，一个通用做法是：在进程启动早期、其他线程还没有创建之前，就用pthread_sigmask把要处理的信号全部设置成阻塞。这样后来创建的每一个线程都会继承这个阻塞掩码。然后你单独创建一个“信号处理线程”，在这个线程里先解除阻塞，再通过sigsuspend或者sigwait专门等信号。这样信号只有这一个线程收得到，处理逻辑天然地串行化。

4.3 工程上推荐的“专职信号处理线程”模式

我自己在写网络服务程序时很喜欢用这个模式，把信号处理和主业务逻辑彻底隔离。

基本步骤如下：

1. 在main函数最开始（任何线程创建之前），用pthread_sigmask阻塞所有关心的信号（比如 SIGTERM、SIGINT、SIGUSR1、SIGCHLD），这样所有后续线程都会继承这个阻塞掩码；
2. 创建一个线程，专门调用sigwait或sigsuspend等待信号；
3. 当信号到达时，由这个专职线程收到并处理，主线程和其他工作线程完全不受信号干扰；
4. 如果需要优雅停机，专门线程把“停止服务”的标志位置位，或者通过管道/队列通知工作线程退出，然后主线程等待所有子线程结束后再退出。

sigwait接口的好处在于：它不需要注册信号处理器，直接以返回值形式给出收到的信号编号。整个程序里信号到了它这里，被当成普通事件处理，完全绕开了“处理器函数里不能随便调用非异步安全函数”的限制。

我写过一个简化的示例，示意这种模式的核心结构：

#include <pthread.h> #include <signal.h> static sigset_t g_wait_set; static void *signal_thread(void *arg) { int sig; while (1) { if (sigwait(&g_wait_set, &sig) != 0) { continue; } if (sig == SIGTERM) { // 收到终止信号，通知业务线程退出 // 这里可以安全地调用各种库函数 } else if (sig == SIGUSR1) { // 自定义重载配置 } } return NULL; } int main(void) { sigemptyset(&g_wait_set); sigaddset(&g_wait_set, SIGTERM); sigaddset(&g_wait_set, SIGINT); sigaddset(&g_wait_set, SIGUSR1); pthread_sigmask(SIG_BLOCK, &g_wait_set, NULL); pthread_t tid; pthread_create(&tid, NULL, signal_thread, NULL); // 启动业务线程... // 主线程可继续做别的事，或直接 pthread_join 等待 return 0; }

这个模式让我少踩了很多坑。信号处理不用再躲躲闪闪地避讳 malloc、printf 这些库函数，因为sigwait是普通函数，在信号线程的上下文里调用它们是安全的。代价就是你需要额外起一个线程，并且必须在所有线程创建前就设好阻塞掩码——这个时机非常关键，错过了，某个早期线程可能已经创建并继承了默认掩码。

4.4 信号对多线程同步原语的影响：EINTR 的线程版

在多线程环境里，像pthread_mutex_lock这类锁操作被信号打断的情况比较少见，因为 POSIX 规范不要求 pthread 锁在被信号打断时产生 EINTR。

但pthread_cond_wait的情况不同。条件变量等待可能被信号打断并返回 EINTR，虽然有些实现不会，但你绝对不能依赖“不会”。我在一次项目里就遇到过：某个工作线程在pthread_cond_wait上等待任务到来，主线程收到 SIGINT 后希望所有线程退出，但条件变量没有超时机制，线程就一直卡在那里不做任何清理，最终程序卡死在退出流程中。

工程上的两个对策：一是用pthread_cond_timedwait增加一个超时时间，即使没有信号到达也能周期性醒来检查退出标志；二是把所有信号接到专职线程里处理，业务线程不直接面对信号。

两个方案里，我强烈推荐第二个，因为方案一会给系统引入无谓的定时唤醒开销，而且代码逻辑会变得越来越乱。

5. 真实项目里最常见的几个信号“事故现场”

最后这一部分，我打算把实际工程中最常见的几个信号相关“事故现场”逐一还原，每一个都是我亲眼见过、或者亲手排查过的问题。理解了这些案例，你才算真正把信号机制用得很熟。

5.1 SIGPIPE：写管道写 socket 时的“静默杀手”

你的程序往一个 socket 里写数据，对端已经关闭，内核在第二次或第三次写的时候发现了这个情况，它会怎么做？默认行为是向你的进程发送 SIGPIPE，然后终止你的进程。

问题就出在这个“默认行为”上。你的业务逻辑可能只是想让正常的网络错误通过返回值暴露给用户，结果进程在你还来不及处理返回值之前就被信号干掉了。

这个问题在管道场景里也常见。你用popen启动一个子进程，然后往标准输入写数据，结果子进程很快就退出了，管道里没有读者，你下一次写就会触发 SIGPIPE。

处理方式很简单，看你的场景：

• 如果你确实不关心“写管道但没人读”这件事，可以直接忽略 SIGPIPE：设置sa_handler为SIG_IGN；
• 如果你希望写失败通过返回值体现，也是忽略 SIGPIPE，然后把write/send的返回值检查好，用errno == EPIPE来判断对端关闭。

几乎所有正式的网络服务程序都会在启动阶段把 SIGPIPE 显式忽略掉。这不是偷懒，而是把“对端关闭”变成一个可处理的错误代码，而不是一次无声的进程退出。

5.2 SIGCHLD：僵尸进程的元凶和正解

父进程生了很多子进程，子进程先退出，父进程还没来得及wait，此时子进程就变成僵尸进程。在子进程退出到父进程wait的这段时间里，它的进程描述符还留在内核里，占着 PID 和少量资源。如果父进程一直不wait，僵尸进程就会一直积累，最终可能导致 PID 耗尽。

信号在这里的作用是：子进程退出时，内核自动向父进程发送 SIGCHLD。父进程如果不处理，就是默认忽略——注意，默认忽略只是父进程“不作为”，僵尸进程依然存在，内核不会自动帮你回收。

正确的做法是在父进程里捕获 SIGCHLD，并在处理器里调用waitpid(-1, &status, WNOHANG)回收。但这里有个细节：SIGCHLD 是标准信号，不排队。如果你的程序同时有一大批子进程退出，可能只会收到一次 SIGCHLD，结果waitpid只回收了一个子进程，其他子进程继续僵尸。

所以正确的回收循环应该是：收到一次 SIGCHLD，就在处理器里不断用waitpid(-1, ..., WNOHANG)循环回收，直到返回 0 或 -1，把所有已退出的子进程全部收干净。

static void handle_sigchld(int sig) { int saved_errno = errno; while (1) { pid_t pid = waitpid(-1, NULL, WNOHANG); if (pid > 0) { continue; // 还有退出的子进程，继续收 } break; // 没有更多退出的子进程，退出循环 } errno = saved_errno; }

还有一个更省心的方案：把 SIGCHLD 设置成SIG_IGN。在某些 Linux 系统上，如果你显式忽略 SIGCHLD，子进程退出时会立即被内核自动回收，不会变成僵尸。不过这个行为在 POSIX 标准里属于可选的，不一定所有平台都支持，所以写跨平台代码时不要依赖这一招。

5.3 SIGSEGV/SIGBUS 崩溃现场：怎么收集可用的信息

这两个信号是对开发者的老朋友了。SIGSEGV 是无效内存访问，SIGBUS 是访问未对齐的内存地址，或者访问一个被截断的映射文件区域。两者默认都会产生 core dump 文件，用 gdb 或其他调试器去分析 core 文件，是定位崩溃问题的有效方式。

但有些生产环境为了安全会把 core 文件关闭。所以工程上更常见的做法是：注册一个 SIGSEGV 的处理器，在里面尽量保存崩溃时的上下文信息，然后再恢复默认行为让进程退出，以便生成 core。

这个场景下要格外小心：崩溃可能发生在任何地方，你的处理器却不一定安全。处理器里只能做最简单的事——比如写一个固定的字符串到某个文件描述符，或者调用sigaction恢复默认动作，然后调用_exit，不要调用任何可能分配内存的库函数。

我见过有团队试图在 SIGSEGV 处理器里打印调用栈，结果二次崩溃，连原始信息都丢了。更稳妥的方案是直接用 gdb 的handle命令配置，或者用系统工具如 systemd-coredump 来做收集，而不是全靠自己写处理器。

# 临时开启 core 文件 ulimit -c unlimited # 用 gdb 分析 core gdb ./program core

5.4 SIGKILL 与 SIGSTOP：永远不要试图“优雅地抗拒”

最容易被一些人忽略的事实是：SIGKILL 和 SIGSTOP 这两个信号没有办法捕获、没有办法阻塞、没有办法忽略。内核给出了这种“不可抗拒”的设计，就是为了确保管理员在系统失控时仍然有最终的“强制停止”手段。

所以当你的程序被kill -9干掉了，不要抱怨“怎么没有执行清理逻辑”——SIGKILL 本身就是不给清理机会的，内核直接用 force 的方式终止进程。这也解释了为什么老练的运维会先用默认的kill（SIGTERM）给进程一个优雅退出的机会，过几秒看进程还在，再用kill -9强制处决。

给业务程序做优雅退出时，正确姿势是把资源清理逻辑写在 SIGTERM 的处理器或专用信号线程里，利用系统给你的这最后几秒时间，保存状态、关掉监听、通知子进程退出，然后再退出主循环。

我一直跟团队说：你的程序应当把 SIGTERM 当作“上级找你谈话”，把 SIGKILL 当作“保安直接把你架出去”。前者要好好应付，后者你根本没机会挣扎。

最后分享一个自用的调试技巧

不知道你有没有遇到过这种情况：程序在某个地方卡住了，你想给它发个信号测试一下信号处理器到底对不对，又不想把它干掉。这时候你可以先kill -STOP <pid>让进程暂停，再用kill -USR1 <pid>发自定义信号，观察进程的行为，最后用kill -CONT <pid>恢复运行。整个过程就像是在给进程做“体外实验”，不会干扰它的正常状态，也不会有误杀风险。

另一个我常用的排查小技巧是strace加信号跟踪参数。比如：

strace -e trace=signal -p <pid>

这个命令会把进程接收到的每一个信号以及信号处理的系统调用实时打印出来，配合日志一起看，经常能直接定位到“信号来了但没人处理”的问题。

我自己在实际项目中养成的习惯是：在初始化代码里专门加几个调试用的自定义信号（比如 SIGUSR1 打印线程数、SIGUSR2 打印连接池状态），生产环境留门，排查问题时随时能用信号“撬开”进程内部看看发生了什么。成本极低，收益极高。

如果你刚接触信号这块，别急着背全部 API，先用本文里的代码把“捕获一个信号并安全处理”跑通，再去看阻塞和实时信号，最后再啃多线程部分。这个顺序走下来，Linux 进程信号这关基本就过了。