企业官网建设流程全解析

1. 从"内核喊你收消息"说起：进程信号到底是什么

你有没有遇到过这种场景：一个程序跑着跑着突然就崩了，终端提示Segmentation fault (core dumped)；或者按Ctrl+C想中断一个死循环的任务，程序却纹丝不动；又或者写了个网络服务，某个客户端断开连接，服务进程直接收到SIGPIPE悄悄死掉。

这些听起来像是"神秘事件"的背后，都是 Linux 的进程信号在起作用。信号本质上是内核主动通知进程"发生了一个异步事件"的一种机制，你可以把它理解成手机上收到一条弹窗通知——不管你在干什么，只要有事件发生，内核就会把这条通知塞给你，然后由你决定怎么处理：忽略、执行默认动作，或者自己写一个处理函数来应对。

对做服务端开发、嵌入式开发，或者还在学校啃《Linux 系统编程》的人来说，信号几乎是绕不过去的一道坎。它不像是函数调用那样"你按顺序执行完再来"的同步流程，而是随时可能插入到你正在跑的某行代码中间的异步机制。数据结构里的锁、条件变量你可能已经很熟，但信号这块儿的"异步、不可控、信号处理函数里啥都不能乱调"的脾气，很多人容易踩坑。

这篇文章我会从信号的核心机制讲起，逐个拆解signal、kill、raise、abort、alarm这五个最常用的信号接口，再把 Core Dump 核心转储机制和硬件中断的关系讲透，最后把我在实际开发中踩过的一些坑和排查思路一并整理出来。内容尽量做到"能落地"——每一段都有命令、有代码、有注意点，拿到就能用。

2. 信号机制的整体设计：五步理解信号的一生

2.1 信号的产生方式：从硬件到软件的四条路径

在写代码之前，先想想信号到底是怎么来的。信号来源大致有四类：

• 来自键盘的终端信号：比如你在终端按下Ctrl+C（产生SIGINT）、Ctrl+\（产生SIGQUIT）。这是大多数人对信号的第一印象——一个中断当前前台进程的快捷键组合。
• 来自硬件异常：比如进程访问了非法内存地址，CPU 触发异常，内核把异常翻译成SIGSEGV发给进程；执行了非法指令，则发出SIGILL；浮点除零发出SIGFPE。这就是"硬件中断"和进程信号之间最直接的联系——硬件异常是触发源，信号是内核丢给用户进程的"事故通知单"。
• 来自软件主动调用：这就是本篇文章的主角们。kill(pid, sig)、raise(sig)、abort()、alarm()都是用户态主动发送信号的方式。
• 来自运行环境/软件条件：比如管道写端被读端关闭时，进程收到SIGPIPE；定时器到点后收到SIGALRM；子进程退出时父进程收到SIGCHLD。

理解信号来源的最大意义在于：排查问题的时候，你可以根据信号类型倒推"这个进程到底经历了什么"。比如我调试过一个诡异的服务进程崩溃问题，最后发现是运行环境的看门狗超时触发了SIGTERM，而不是代码本身出现 bug——从信号入手，它一下给排查锁定了方向。

2.2 信号的标准流程：产生、注册（挂起）、递达、处理

信号并非"产生后马上被处理"那么简单。一个信号的一生要经过四个阶段：

1. 产生：信号被某个源头生成出来。
2. 注册/挂起：如果信号尚未递送到进程，内核会在进程的pending信号集合里做标记。注意，对于标准信号，同一类信号在未递达之前只会保留一个标记——就算你连续发了 10 次SIGUSR1，进程醒来也只会处理一次。这一点和高等级的实现（比如后来 POSIX 化之后出现的实时信号）有本质区别。
3. 递达：内核在恰当时机（通常是进程从内核态返回用户态之前）检查信号集合，决定把信号"递交"给进程。
4. 处理：进程执行三类动作之一——忽略、默认动作、或者调用通过signal()/sigaction()注册的自定义处理函数（也叫"捕获"信号）。

而"默认动作"又分几种：终止进程、终止并产生 core 文件、忽略信号、暂停进程、恢复进程。光是这个"默认动作"矩阵就值得记一张表：

注意SIGKILL和SIGSTOP这两个兄弟很特殊，内核直接处理，用户进程没有机会拦截。这话很多书都写，但很多人遇到kill -9杀不掉的进程时还是不信邪——那不可能是被你程序捕获了，而是进程处于不可中断的睡眠状态（比如在内核态卡在某些 IO 上），属于另一个完全不相关的话题。

2.3 为什么建议用sigaction()而不是signal()

标题里把signal放在首位，但实际上在严肃的服务端项目里，我几乎不会直接用signal()注册信号处理器。原因比较现实：signal()在不同 Unix 衍生系统上语义有差异，在某些实现中，信号处理函数执行完之后，该信号的处置方式会被重置为默认行为，这意味如果在处理函数里二次注册不够及时，同一信号再次来临时就可能直接把进程干掉。另外，signal()无法设置信号屏蔽字，也无法带上SA_RESTART这类标志，导致某些系统调用（read、write、accept等）在收到信号后会被中断，返回EINTR错误，处理起来非常难受。

所以我在这篇文章里的代码示例会刻意偏重sigaction()，只是在讲解信号概念时把signal()当作入口。这不是劝退 API，而是帮你少走弯路。下面讲到实操时，会给出sigaction()的标准写法。

3. signal() 与捕获信号的实操细节

3.1 用 signal() 实现第一个信号捕获程序

先从最直观的写法下手，看一个简单的例子：捕获SIGINT，让程序在按Ctrl+C时不必立刻退出，而是打印一条消息。

#include <stdio.h> #include <stdlib.h> #include <signal.h> #include <unistd.h> void handle_sigint(int sig) { // 注意：printf 在信号处理函数里其实不是完全安全的选择 // 简单 demo 可以这么用，实际项目里要用异步信号安全的 write() printf("捕获到 SIGINT，信号编号: %d\n", sig); } int main(void) { signal(SIGINT, handle_sigint); for (int i = 0; ; i++) { printf("运行中 %d 秒...\n", i); sleep(1); } return 0; }

编译后跑起来，按Ctrl+C，程序不会退出而是打印提示后继续运行。你可能会想："那我怎么杀它？"——只能另开终端用kill -9 <pid>，因为SIGKILL是不允许被捕获的。

这里要特别说一句：上面代码里的printf只是拿来演示。严格来说，printf并不是异步信号安全函数，如果在信号处理函数里调用它，而这个函数恰好打断了主流程里正在执行printf的同一份内部缓冲区操作，可能导致状态错乱甚至死锁。生产级代码里，信号处理函数里只应该使用write()、_exit()这类异步信号安全函数。

3.2 sigaction() 的完整姿势与 SA_RESTART 之谜

再来看sigaction()的正确用法。以捕获SIGINT为例：

#include <stdio.h> #include <stdlib.h> #include <signal.h> #include <string.h> #include <unistd.h> volatile sig_atomic_t g_flag = 0; void handle_sigint(int sig) { // 只设置一个标志位，主循环里轮询检查 // sig_atomic_t 保证读写是原子的 g_flag = 1; } int main(void) { struct sigaction sa; memset(&sa, 0, sizeof(sa)); sa.sa_handler = handle_sigint; sigemptyset(&sa.sa_mask); // 处理信号期间不额外屏蔽其他信号 sa.sa_flags = 0; // 先不设置 SA_RESTART，观察系统调用中断现象 if (sigaction(SIGINT, &sa, NULL) == -1) { perror("sigaction"); exit(EXIT_FAILURE); } printf("等待信号，按 Ctrl+C 试试...\n"); while (!g_flag) { pause(); // 挂起进程，等待任何信号 } printf("收到信号，主循环退出\n"); return 0; }

这段代码里有两个关键点：

• volatile sig_atomic_t类型的变量用来在信号处理函数和主流程之间传标志。这个类型保证了对它的读写是原子的，不会被主流程的赋值打断产生撕裂问题。
• pause()会让进程挂起，直到捕获到一个信号。这是信号编程里非常经典的写法。

现在来说SA_RESTART。如果你在一个阻塞的read()上等待数据，此时一个信号过来，默认行为是让read()返回-1，同时置errno为EINTR（被中断）。很多初学者会在这里懵掉：为什么我的程序莫名其妙read失败？其实只是被信号打扰了。

解决办法是在sa_flags里设置SA_RESTART，内核会在信号处理函数返回后自动重新启动被中断的系统调用，对应用层来说就像"信号没发生过"一样。

sa.sa_flags = SA_RESTART;

但注意，SA_RESTART并不能覆盖所有系统调用。有些调用（如poll、epoll_wait、accept在某些场景）依然可能返回EINTR，所以严谨的写法是循环重试，例如：

while (1) { ssize_t n = read(fd, buf, sizeof(buf)); if (n == -1 && errno == EINTR) { continue; } if (n == -1) { // 真正的错误 } break; }

这是我在实际服务端代码里几乎处处可见的一段逻辑。别偷懒，EINTR必须显式处理。

3.3 sa_mask 与信号屏蔽的连锁反应

sigaction结构体里的sa_mask定义的是：当某个信号的处理函数正在执行时，临时屏蔽哪些信号。比如你希望在处理SIGINT期间，如果来了SIGUSR1，先别打扰，那就把它加进sa_mask。

注意这个机制不是永久屏蔽当前正在处理的信号类型——同一信号在处理期间会被阻塞，但处理函数返回后自动解除。这也引出一个重要现象：同一个信号如果反复快速产生，处理函数不会"递归"执行，而是等待当前处理完成后再去处理下一个未决信号，并且因为标准信号只保留一个未决标记，所以经常"丢"掉中间几次。

这一点想深入理解可以做个小实验：给 SIGINT 的处理函数里加长延时循环，然后用kill -INT <pid>连发 5 次，你会发现处理函数只串行执行了一次或几次，并不是发多少次就处理多少次。理解了"未决信号集只记一笔"之后，对信号的理解就上了一个台阶。

4. kill、raise、abort、alarm：信号发送家族逐一拆解

4.1 kill(2)：不只是"杀死"，而是"发信号"

kill()这个函数名极具迷惑性——好像是专门用来杀掉进程的，但它的本质是向指定进程发送任意信号。在 Linux 系统里：

int kill(pid_t pid, int sig);

• pid > 0：发送给指定的进程 ID。
• pid == 0：发送给调用者同进程组的所有进程。
• pid == -1：发送给所有有权限发送的进程（慎用！我见过有同事用它做测试，结果整个终端会话的进程全被信号影响，场面一度不可收拾）。
• pid < -1：发送给进程组 ID 为-pid的所有进程。

在运维场景里最常用的自然是kill -TERM <pid>和kill -KILL <pid>。KILL是最后手段，而TERM会先通知进程"你该收拾东西走了"，给进程一个优雅关闭的机会（比如释放资源、落盘状态）。

我曾经写过一个服务，启动脚本里一律用kill -TERM，然后在服务里注册了SIGTERM的处理函数，执行平滑退出——先停止接收新请求，再等待处理中的请求结束，最后关闭数据库连接池。这套逻辑让线上服务的重启零停机。

再看kill()的返回值。如果进程不存在，返回-1并设errno为ESRCH；如果没权限，返回-1且errno是EPERM。在脚本里判断进程是否存活，用kill(pid, 0)是一个常见技巧——信号 0 表示"只做检查，不真正发信号"，可以用来探测进程是否存在。

4.2 raise(3)：自己给自己发信号

raise(sig)等价于kill(getpid(), sig)，区别不过是一个封装。但它有一个特殊价值：在单线程程序里，raise 一定会让信号被当前线程处理；而kill(getpid(), sig)在多线程环境中信号会发送给进程内任意一个没有被阻塞该信号的线程，处理线程不可控。

那raise到底什么时候用？我的实践是：

• 在程序里模拟一种"外部事件发生"的信号，用来驱动测试逻辑。比如写单元测试时，想测试SIGUSR1处理器能不能正确改变状态机，就可以raise(SIGUSR1)手动触发。
• 在后台服务里给自己发SIGTERM做自我终止。某些管理脚本会这么用，比如进程内部发现配置严重错误，决定"自我了断"。

示例：

#include <stdio.h> #include <signal.h> int main(void) { printf("我自己给自己发 SIGUSR1...\n"); raise(SIGUSR1); // 默认动作是终止进程，所以这条语句后面的代码不会执行 printf("这行不会打印\n"); return 0; }

默认情况下SIGUSR1会终止进程，所以如果没有注册处理函数，程序会在这里安静地挂掉。这也是很多人在测试时踩到的第一个坑：用完raise(SIGUSR1)没注册对应 handler，程序直接退出，还半天找不到原因。

4.3 abort(3)：最粗暴的"原地自爆"

abort()的行为是：先解除SIGABRT的阻塞，然后向自己发送SIGABRT。如果该信号没有被捕获或者处理函数返回，进程会终止，并且大概率产生 core 文件（前提是 core 限制允许）。

abort()的语义是"异常终止"。它和我们自己raise(SIGABRT)有一个细微差别：abort()在发送信号之前会先把SIGABRT从阻塞状态解除，确保信号一定能够递达。另外，在核心转储机制生效时，abort()产生的SIGABRT默认会导致 core dump，方便事后用 gdb 查看崩溃现场。

很多项目中会把assert宏和abort()绑定起来。C 标准库里的assert(expr)在判定失败时会打印错误信息并调用abort()。所以你在测试阶段看程序崩出一个Aborted (core dumped)时，基本就能推测是某个断言没过。

但需要注意：线上环境千万不要滥用abort()，因为它不是优雅退出，不给你清理资源的机会。响应外部请求失败可以返回错误，真遇到不可恢复的致命问题再考虑它。

4.4 alarm(2)：延时炸弹，到点自动引爆

alarm()是一个简单但非常有用的定时器接口：

unsigned int alarm(unsigned int seconds);

它让内核在seconds秒后向当前进程发送SIGALRM。返回值是"之前未到期的闹钟还剩多少秒"；如果之前没有未到期的闹钟，则返回 0。

从 POSIX 规范看，SIGALRM的默认动作是终止进程。所以如果你设置了alarm(3)却忘了注册处理函数，程序三秒后就会被终止。但实践中更常见的用法是配合一个自定义 handler，实现"超时控制"：

#include <stdio.h> #include <signal.h> #include <unistd.h> #include <errno.h> void timeout_handler(int sig) { // 处理超时，比如设置一个标志让主流程退出 write(STDOUT_FILENO, "timeout expired\n", 16); } int main(void) { struct sigaction sa; sa.sa_handler = timeout_handler; sa.sa_flags = 0; sigemptyset(&sa.sa_mask); sigaction(SIGALRM, &sa, NULL); alarm(3); // 3 秒后闹钟到期 printf("等待闹钟...\n"); int n = 0; do { n = read(STDIN_FILENO, NULL, 0); // 故意用一个会阻塞的调用模拟等待 } while (n == -1 && errno == EINTR); // 走到这里说明被信号打断了 read printf("read was interrupted by signal\n"); return 0; }

这个例子的关键是想让你体会：alarm + 信号处理函数是早期 Unix 里实现超时机制最常用的手段。把闹钟定好，然后去读一个可能永远没有数据的设备，时间一到SIGALRM就会打断read，触发超时逻辑。现在虽然我们有select/poll/epoll的超时参数，但很多老代码和个别特殊场景仍然依赖alarm思路。

alarm()还有一个经典应用——给服务端 socket 的accept()加上超时保护，防止进程在无连接时无限期阻塞。不过现在更推荐用setsockopt(SO_RCVTIMEO)或者select来做，可读性更好。

还要提醒一下：alarm()只能设置一个闹钟，多次调用会覆盖之前的设置。如果要在同一进程里管理多个不同超时，要么自己实现一个"闹钟管理表"，要么切换到setitimer()或 POSIX Timer（timer_create）。这也是我在做服务端开发时建议重点掌握的替代方案：

#include <sys/time.h> #include <signal.h> // 每 100ms 触发一次 SIGALRM struct itimerval tv; tv.it_value.tv_sec = 0; tv.it_value.tv_usec = 100000; tv.it_interval.tv_sec = 0; tv.it_interval.tv_usec = 100000; setitimer(ITIMER_REAL, &tv, NULL);

setitimer相比alarm优势明显：支持周期触发、支持微秒级精度。标题里既然写了alarm，我就多补一句：alarm其实是setitimer(ITIMER_REAL)的简化版，底层用的是同一个内核定时器机制。

5. Core Dump 核心转储机制：崩溃现场如何还原

5.1 Core Dump 是什么：崩溃那一刻的内存快照

进程收到某些"致命"信号（如SIGSEGV、SIGABRT、SIGQUIT、SIGILL、SIGFPE等）并即将退出时，内核会尝试把进程的整个内存镜像、寄存器状态、进程元信息等内容写入一个文件，这个文件就是 core 文件。它相当于"崩溃现场的照片+录音"，之后可以用调试器还原程序当时在干什么，也能精确回溯变量值、函数调用栈。

要理解 core dump 的价值，想象你是一个侦探，案发之后有一份现场完整录像，当然比只看到一具尸体强得多。没有 core 文件时，你只能靠日志猜；有了 core 文件，你可以直接看崩溃线程的调用栈，定位是哪一行代码越界访问了。

触发 core dump 的信号有三类典型代表：

• SIGSEGV：野指针、越界、访问已释放内存。
• SIGABRT：assert 失败、abort()调用。
• SIGFPE：除零（整数除法直接触发 CPU 异常，生成该信号）。

5.2 打开与关闭 Core Dump：ulimit 与 sysctl

大多数 Linux 发行版默认是关闭 core dump 的，因为 core 文件往往动辄几十 MB 甚至几个 GB，磁盘撑不住、还可能有敏感数据泄漏风险。检查当前限制：

ulimit -c

如果输出0，说明 core 文件不会生成。想打开：

ulimit -c unlimited

但要注意，ulimit是 shell 内置命令，只对当前 shell 及其启动的子进程生效。如果是从 systemd 服务拉起的进程，限制要看服务配置或者系统全局/etc/security/limits.conf。

另外需要确认内核层面的转储开关：

# 查看内核是否允许核心转储 cat /proc/sys/kernel/core_pattern

常见路径如core或core.%e.%p，也可以自定义成带时间戳的路径。某些系统还会把 core 直接丢给 systemd-coredump 处理，那就不是普通文件了，要用coredumpctl查看：

coredumpctl list coredumpctl info <pid>

在开发环境里调 core dump 之前，我通常先确认两件事：ulimit -c unlimited是否生效，以及core_pattern是否是预期路径。有时候调了半天没生成，最后发现是 core_pattern 被配置成了/dev/null——直接被内核无情丢弃了。

5.3 用 gdb 分析 Core 文件：四步还原崩溃现场

等到 core 文件落下之后，直接让 gdb 加载：

gdb ./your_program ./core.12345

进入 gdb 后，最有用的两个命令是：

bt # 打印崩溃时函数调用栈 frame N # 切换到某一帧查看局部变量

如果你编的是带调试信息的版本（gcc -g），还能看到精确到行的代码位置。这也是为什么线上发布二进制一般要保留一份带-g的"调试副本"，以便事后和 core 文件对应分析。

给新手的排查流程：

1. 确认崩溃信号：gdb启动时会自动打印类似Program terminated with signal SIGSEGV, Segmentation fault。
2. bt看调用栈，找最后一次main到崩溃点之间经过的函数。
3. 层层下钻frame，查看关键变量和指针有没有异常值（比如指向了 0x0、0xdeadbeef）。
4. 结合源码检查是越界、空指针还是逻辑问题。

有一个我自己印象深刻的排查案例：某模块不定时崩溃，日志没有任何异常。拿到 core 文件后发现栈顶是memcpy，参数里的目标地址是堆上一个已经释放的 chunk。顺着局部变量的指针往回追，发现是另一个线程提前释放了对象，主线程还在用——典型的典型数据争用。如果没 core 文件，这类问题靠日志几乎没法排查。

5.4 Core 文件的一些进阶玩法

除了 gdb 手动分析，现代 Linux 上还可以把 core dump 交给崩溃报告工具自动收集。有些团队会在core_pattern里指定一个管道处理程序，例如：

|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e

这样 core 数据不进磁盘文件，而是被交给系统组件管理，统一查看。这个做法在生产环境里更安全、更好管控，但前提是别把core_pattern设为外部网络路径——core 文件里可能包含内存中的密钥、密码、凭证，泄露风险不容小觑。

我在生产服务器上通常把core_pattern定向到某个专门的临时目录，并且设置磁盘配额，同时做好文件定期清理。不能因为 core 分析方便就无限制开，抢救完现场立刻关掉或者收缩限制，是我的一贯做法。

6. 硬件中断与进程信号：从异常到信号的翻译官

6.1 CPU 异常如何变成进程收到的一个信号

很多人误把"硬件中断"理解成"信号就是硬件中断"，其实严格来说是两条链路。硬件中断（如网卡收到数据、磁盘完成 IO）由 CPU 的中断控制器通知内核，内核的驱动代码处理；而 CPU 在执行指令时发现异常（比如访问非法地址、非法指令、除零），这个"异常"被内核捕捉后，转化为某个信号发送给当前进程。

拿最典型的SIGSEGV举例。当进程访问了一个不属于它的内存页：

1. CPU 触发缺页异常/保护异常。
2. 内核的异常处理程序检查这个地址是否合法。
3. 如果虚拟地址根本没有映射，或者访问权限不对，内核就判定为"不可修复的段错误"。
4. 内核向当前进程发送SIGSEGV。
5. 如果进程没有捕获该信号，默认动作是终止进程并生成 core。

换句话说，硬件异常是"因"，信号是内核对外发布的"果"，信号只是内核把硬件层的灾难翻译成用户态听得懂的事件。这也是为什么在信号处理函数里你能收到si_code（通过带扩展信息的 sigaction 获取），里面会区分这个SIGSEGV是内存访问越界、还是写只读区域、还是内核发来的其他原因。

6.2 常见硬件触发信号的对照表

区分SIGSEGV和SIGBUS是很多进阶开发者的必修课。SIGSEGV通常是访问"没有权限访问"的虚拟地址；SIGBUS则是"地址合法但硬件没法访问"——比如在 mmap 的文件上超出了文件实际长度，访问了还没扩展出去的部分，就会得到SIGBUS。

6.3 信号处理器不是中断处理器

在嵌入式或者底层开发里，经常会有一个误区：把信号处理函数当作中断服务程序来用。其实两者完全不同：

• 中断处理程序运行在内核态，能直接响应硬件事件，限制极多（不能用不安全的调用、不能睡眠）。
• 信号处理函数运行在用户态，是进程正常执行的上下文衍生的"旁路逻辑"，相对宽松，但仍然只能调用异步信号安全的函数。

我曾经见过一个项目，在信号处理函数里用malloc分配内存，然后出现偶发死锁——原因是malloc内部可能持有锁，而信号恰好打断了主流程中同样执行malloc的代码，两个执行流争同一把锁就卡死了。这个坑非常经典，也再一次印证了那句话：信号处理函数里有且仅有"设置 volatile sig_atomic_t 标志、调用write、调用_exit、调用sigaction修改后续处理"这类安全操作。

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

7.1 为什么我用 Ctrl+C 杀不掉程序

按Ctrl+C发送SIGINT，如果程序没有退出，可能原因：

• 程序注册了SIGINT处理器且处理器没有退出动作（最常见，你自己写的 handler 里只打印消息但没调用exit）。
• 程序把SIGINT忽略掉了，比如某些守护进程会主动signal(SIGINT, SIG_IGN)。
• 进程不是当前终端前台进程，Ctrl+C不会发给它。

排查办法就是ps -o pid,stat,cmd看进程状态，再用kill -TERM、kill -KILL逐级尝试。

7.2 信号处理函数里能不能调用 printf、malloc、strcpy

不建议。严格来说，只有异步信号安全函数才可以在信号处理函数中安全调用。printf、malloc、free都可能操作全局数据结构或锁，存在死锁和状态污染风险。如果确实要在处理函数里输出，用write(2)行输出；如果要做复杂逻辑，最好的方案是"只置标志位"，在主流程合适的位置检查标志再执行完整操作。

7.3 为什么 kill -9 也会遇到"杀不死"的进程

SIGKILL不可被捕获、不可被忽略，正常情况下能终结任意进程。但有一个例外：进程处于D状态（不可中断睡眠），通常是等在内核的磁盘 IO 或 NFS 等外部操作上，信号要等它回到用户态时才能递送。遇到这种进程，只能等内核操作完成或重启系统。排查时可以看进程的状态字段：

ps aux | awk '$8 ~ /D/'

7.4 收到信号后 read/write 返回 EINTR，怎么处理

这是服务端编程里最常见也最容易忽略的问题。EINTR并不是致命错误，属于"信号打扰了你当前的系统调用"。处理方式就是循环重试：

static ssize_t robust_read(int fd, void *buf, size_t count) { ssize_t n; do { n = read(fd, buf, count); } while (n < 0 && errno == EINTR); return n; }

配合sigaction设置SA_RESTART可以减少这类问题的发生，但终究不能完全消除，所以代码层面还是要有重试逻辑。

7.5 为什么程序突然莫名其妙"消失"了

后台进程"消失"时，优先去翻系统日志和进程退出码。如果是被信号终止，shell 或者父进程能看到WIFSIGNALED(status)以及对应信号值。在 shell 里跑一个程序失败退出，可以立即：

echo $?

如果退出码大于 128，基本可以断定是被信号杀掉的，退出码减 128 就是信号编号。比如$?返回 139，则139 - 128 = 11，对应SIGSEGV。这个技巧我在排查脚本问题时用了无数次，非常实用。

7.6 使用信号时的另外几条实战心得

• 注册处理函数时尽量用sigaction而别用signal，尤其在需要跨平台和保证可靠行为的时候。
• 不要尝试捕获SIGKILL和SIGSTOP，你捕获不到，白白浪费精力。
• 多线程进程里，信号默认可以发给任意线程。如果不希望某线程被某个信号打断，可以设置线程级信号掩码。
• 信号经常被用来做"优雅停机"的触发通道，配合全局标志位实现主循环退出，比直接用exit()粗暴退出更稳妥。
• 测试信号机制时，打印进程 PID 再另开终端发信号，别老用系统自带的kill打断整个终端会话。

8. 踩坑之后的经验沉淀

自己这些年处理过的和信号相关的线上问题不少，最大的感受是：信号机制并不难，难的是意识。它不像内存泄漏那样有明显的迹象，很多时候进程崩溃就会被记录为一句"Exited with signal 11"，然后排查看似毫无头绪。但只要养成了几个好习惯，难度会大幅下降。

第一个好习惯是：每写一个服务端程序，务必先明确要处理哪些信号。SIGTERM用于优雅停机，SIGINT用于终端中断，SIGSEGV、SIGABRT之类的崩溃信号，宁可让系统生成 core 也别在 handler 里做太多操作，保留第一现场比什么都重要。

第二个好习惯是：信号处理函数里只做"通知"，不做"处理"。真正的工作放到主流程里去做，用volatile sig_atomic_t标志位或者一个自写的无锁队列把事件传递出去。你可以先把这个原则定下来，再开始写代码。我见过太多为了图方便在 handler 里"顺便更新一下数据库"、"顺便写个日志文件"而导致线上诡异问题的案例。

第三个好习惯是：永远保留一份带调试信息的发布产物。崩溃后要分析 core 文件却发现二进制没有符号，那种感觉真是极其难受。哪怕线上跑的是-O2的版本，也有办法保留单独的符号文件。只要调试信息在，core 分析就能定位到具体函数和行号，排查效率天差地别。

如果你的代码已经开始涉及网络服务、多线程、守护进程这些场景，信号必定会出现在你的代码里。别怕它，先把这几个接口用熟，再逐步理解"信号是内核与进程之间最底层的事件通知语言之一"这件事。下一篇我可以继续写写父子进程间的信号继承、信号与多线程的交互，以及用signalfd把信号处理放到事件循环里的现代做法——那又是另一个非常有趣的话题。