★ FEATURED ARTICLE 很多人写了几年 C 语言和系统编程问起来信号机制都能说出“ CtrlC 就是给前台进程发 SIGINT”“kill -9 杀不掉说明没辙了”这类话但真让他解释信号在内核里怎么流转、sigaction 里那一堆标志位各自干什么、SIGCHLD 怎么用才能彻底告别僵尸进程就开始含糊了。这就是我想写这篇东西的原因。Linux 进程信号不是只能停留在“会用 kill 命令”这个层面它是异步事件处理的核心机制是进程间最简单的通信方式之一也是你理解后面一切高级 IPC管道、消息队列、共享内存、epoll 信号集成的基础。这篇文章我会从信号的本质讲起把生命周期、核心 API、可重入函数这些平时很容易含糊的点逐个拆开再给几个可以直接抄作业的实操示例最后是我自己踩过的坑和排查思路。适合正在学系统编程的开发者、写过一些 C 但始终没把信号机制完全理清的同学以及需要排查线上诡异问题的朋友。1. 信号到底是什么先把它从玄学变成常识1.1 信号的本质是“软件中断”我见过不少资料把信号描述成“异步通知机制”这说法没错但太抽象了。我自己理解信号的方式是把整个操作系统想象成一个大型物业中心每个进程是住在楼里的住户内核是物业经理。信号就是物业经理给住户门口塞的小纸条——可能告诉你“有人按了你家门铃”SIGINT可能告诉你“你家里水管爆了”SIGSEGV也可能告诉你“你家孩子毕业了”SIGCHLD子进程状态变化。这个小纸条塞到你门口后你手上正在做的事不会立刻停下来——物业不会冲进你家把书撕了而是等你完成手头这个小段落从内核态返回用户态时你低头看一眼纸条决定怎么处理。这就是信号和中断的差别。硬件中断是硬件设备网卡、磁盘直接跟 CPU 说“别干现在的活了先来处理我”信号是内核发给进程的软件通知进程收到后不一定马上处理而是等到合适的时机。专业说法叫“软件中断”我更喜欢叫它“延迟处理的通知”。1.2 信号的生命周期从生到灭要经历这几个环节信号的完整生命周期分为四个阶段产生、注册、注销、处理。这四个词是搞懂整个机制的核心。产生信号来源很多键盘输入CtrlC触发 SIGINT非法内存访问触发 SIGSEGV调用 kill()/raise() 函数主动发硬件异常除零也会产生信号。注册信号被内核记住了。注意对于标准信号1-31如果同一个信号还没有被处理后续再次产生的相同信号会直接丢弃合并处理。这就是“信号丢失”问题的最根本原因。而实时信号34-64支持排队不会丢。注销进程准备要处理这个信号时内核会把对应位从未决信号集里清掉。对于标准信号因为合并了所以注销只需要清一次位实时信号因为排队每处理一个才清一个。处理进程执行预先绑定的处理函数或者执行默认动作或者忽略它。这四个环节只要能背下来后面几乎所有信号相关的疑惑都能找到答案。比如你问“为什么程序莫名丢了一个 SIGUSR1”答案是注册环节就合并了你问“为什么信号处理函数里调 printf 会出现诡异崩溃”答案要往重入问题上找。1.3 信号的三种处理方式默认、忽略、自定义信号处理有三种路径。第一种是默认动作每个信号都有系统预设的处理行为SIGINT 默认终止进程SIGCHLD 默认忽略SIGPIPE 默认终止进程。第二种是忽略信号相当于在门口贴了张“此住户不接收该通知”。第三种是自定义处理函数这是大多数情况下的重点你用 signal() 或 sigaction() 注册一个函数告诉内核“收到这个信号你就调我”。这里有个极其容易踩的坑SIGKILL 和 SIGSTOP 这两个信号不能被捕获、不能被阻塞、不能被忽略。这是内核的最后一道保险——如果一个进程可以把杀它的信号都拦截了系统就失控了。所以 kill -9 永远奏效除非进程处于不可中断的内核态睡眠。这是设计上的有意为之不是 bug。2. 核心机制逐层拆解从注册函数到信号集操作2.1 signal() 和 sigaction()功能相似命运截然不同很多人一开始接触的是 signal() 函数因为书上是这么写的#include signal.h void handler(int signo) { // 处理逻辑 } signal(SIGINT, handler);但实际项目中我几乎不用 signal()原因只有一个语义在不同系统间有差异历史包袱太重。在部分早期系统上signal() 注册的 handler 在被调用一次后会被重置为默认行为导致第二次信号来时直接走默认路径进程直接退出。race condition 问题也是 signal() 绕不开的硬伤——信号处理方式和设置之间不是原子的。sigaction() 没有这些问题。虽然它用起来啰嗦但胜在稳定和精确#include signal.h #include string.h struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler handler; sigemptyset(sa.sa_mask); sa.sa_flags 0; if (sigaction(SIGINT, sa, NULL) -1) { perror(sigaction); exit(EXIT_FAILURE); }你会发现 sigaction 多出来两个东西sa_mask 和 sa_flags。sa_mask 是信号处理函数执行期间要额外屏蔽的信号集。比如你的 SIGINT handler 执行比较久你希望在它执行期间暂时压住 SIGTERM 的干扰就把 SIGTERM 加进去。sa_flags 是一堆行为控制开关最常用的是 SA_RESTART——让被信号打断的系统调用阻塞在 read/write 等函数时自动重启而不是返回 EINTR 错误。这个细节单独拎出来说因为它能省掉你一大笔代码量。2.2 信号集操作别直接给 sigset_t 赋值信号集 sigset_t 不是 int你没法直接写mask SIGINT|SIGTERM。它本质上是内核里一张位图每个位对应一个信号。用户态访问它必须走一组专用函数sigemptyset(set); // 清空所有位 sigfillset(set); // 所有位都置1 sigaddset(set, SIGINT);// 打开 SIGINT 的位 sigdelset(set, SIGINT);// 关闭 SIGINT 的位 sigismember(set, SIGINT); // 查询 SIGINT 在这个集合里吗信号集最大的用处有俩一是配合 sigprocmask() 做阻塞控制二是配合 sigpending() 检查未决信号。这里必须强调一下阻塞和忽略是两回事。阻塞是把这个信号暂时压在门口不让它进来处理但是信号本身还在解除阻塞后会立即触发忽略是不注册处理函数也不做默认动作信号来了没有后续动作。前者像是把纸条夹在门缝不拆开后者是把纸条直接扔垃圾桶。2.3 阻塞与未决两个容易混淆的核心状态阻塞这个场景我用一个例子讲透。写一个守护进程在把配置写入磁盘的关键步骤里你不希望这段时间来的 SIGHUP 触发重新加载配置因为文件写到一半打断会导致配置错乱。做法就是在写文件之前用 sigprocmask() 把 SIGHUP 加进阻塞集写完文件后再解阻塞。解阻塞后如果在阻塞期间有 SIGUPS 信号来过了内核会把这个信号标记为 pending未决。你可以用 sigpending() 检查sigset_t pending_set; sigpending(pending_set); if (sigismember(pending_set, SIGHUP)) { // 在阻塞期间确实来过 SIGHUP }这个机制在实际工程中太常用了。我常常把它类比成打车排队信号来了相当于你取了个号阻塞相当于你关了叫号提示音pending 相当于叫号屏上显示了你的号。等你重新开声音就会立刻被叫到。这个机制还有一个经典用法就是统一信号入口。很多服务会把一批信号SIGTERM、SIGINT、SIGHUP、SIGUSR1全部加到阻塞集然后进程启动后专心做初始化初始化完成后再统一解除阻塞让所有积压的信号一次性进入 handler。这样就不存在“初始化还没完成信号已经来了”的竞态问题。3. 实操演练四个可以直接上线的信号处理场景3.1 优雅退出别再让进程死无全尸很多进程死在 SIGTERM 下不是因为它必须死而是因为没人接住这个信号做清理。看下面这种典型写法#include stdio.h #include stdlib.h #include signal.h #include unistd.h #include string.h static volatile sig_atomic_t running 1; void handle_term(int signo) { (void)signo; running 0; } int main(void) { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler handle_term; sigemptyset(sa.sa_mask); sa.sa_flags 0; if (sigaction(SIGTERM, sa, NULL) -1) { perror(sigaction); return 1; } while (running) { printf(working...\n); sleep(1); } printf(cleaning up...\n); fflush(stdout); return 0; }注意我用的是volatile sig_atomic_t而不是普通 int。C 标准保证 sig_atomic_t 的读写是原子的在信号处理函数和主循环之间共享这个变量不会被撕裂。volatile 则保证编译器不会把这个变量优化到寄存器里缓存每次读取都真实地从内存拿。这两点屏蔽了绝大多数优化器的幺蛾子。记住信号处理函数和程序主流程共享的变量必须是 volatile sig_atomic_t除非你确定你的系统上 int 读写天然原子大多数是的但别赌。3.2 SIGCHLD 的威力彻底告别僵尸进程新手写多进程程序最头疼的就是回收子进程。最常见的错误写法是用 wait() 阻塞等待子进程退出如果父进程还有其他事要干就僵住了。错误写法是干脆不回收跑一段时间后 ps 一查一堆僵尸进程。正确做法是利用 SIGCHLD——子进程状态变化退出、暂停、恢复时内核会给父进程发这个信号。父进程注册 handler在 handler 里循环调用 waitpid() 回收#include stdio.h #include stdlib.h #include signal.h #include sys/wait.h #include unistd.h #include string.h void handle_child(int signo) { (void)signo; int status; pid_t pid; // 关键点循环回收一次信号处理回收所有已退出的子进程 while ((pid waitpid(-1, status, WNOHANG)) 0) { if (WIFEXITED(status)) { printf(child %d exited, status%d\n, pid, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf(child %d killed by signal %d\n, pid, WTERMSIG(status)); } } } int main(void) { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler handle_child; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART | SA_NOCLDSTOP; if (sigaction(SIGCHLD, sa, NULL) -1) { perror(sigaction); return 1; } pid_t pid fork(); if (pid 0) { printf(child running\n); exit(3); } while (1) { printf(parent loop...\n); sleep(2); } return 0; }这个 handler 里有几个细节必须说透。第一为什么循环 waitpid因为多个子进程同时退出时内核只会发一个 SIGCHLD标准信号合并的特性如果你只 waitpid 一次剩下的子进程就会继续挂着当僵尸。循环到返回 0 或 -1 为止确保全部回收。第二WNOHANG 必须带。不带的话如果其中一个子进程还没退出waitpid 就会阻塞在信号 handler 里这是灾难性的。你用一个异步的处理函数去做同步阻塞的事程序性能直接毁了。第三SA_NOCLDSTOP 这个标志告诉内核只有子进程真正退出时才发 SIGCHLD暂停和恢复比如作业控制里的 CtrlZ不触发。这样可以避免大量无关的信号洪峰冲破你的 handler。第四printf 在信号处理函数里其实是不安全的后面会展开说。这里为了演示效果用了 printf实际生产代码应该用一个写 pipe 或 set flag 的方式。这个方案用好了你那个跑了几万个子进程的服务再也不会在 ps 里看到 状态。3.3 定时器的另类实现用 SIGALRM 打破 read 阻塞read 一个管道或者串口如果对端一直不发数据read 会永远阻塞。你想给它加个超时时间比如 3 秒没数据就别等了。方法很多select/poll/epoll 是正路但有一个更轻量的方式是 SIGALRM#include stdio.h #include signal.h #include unistd.h #include string.h void handle_alarm(int signo) { (void)signo; // 超时处理直接抛一个长跳转或者设置标志 // 这里只打印实际项目中通常配合 siglongjmp } int main(void) { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler handle_alarm; sigemptyset(sa.sa_mask); sa.sa_flags 0; sigaction(SIGALRM, sa, NULL); alarm(3); char buf[128]; ssize_t n read(STDIN_FILENO, buf, sizeof(buf)); if (n 0 errno EINTR) { printf(read timeout\n); } else if (n 0) { printf(read %zd bytes\n, n); } return 0; }这里有个知识点必须澄清默认情况下信号打断阻塞的系统调用后read 会返回 -1 并且 errno 被设为 EINTR而不是自动重试。除非你注册 sigaction 时带了 SA_RESTART。上面这个例子故意没带 SA_RESTART所以 read 超时后能正常退出。但如果你在某处注册 SIGALRM 时带了 SA_RESTART那么 read 会在信号处理完后自动重启你的超时设计就完全失效了。这个坑我踩过不知道多少次——在混合代码库里同一信号的注册方式在不同模块中可能不一致导致行为飘忽。原则是要利用 EINTR 做超时或让阻塞提前返回就绝不能加 SA_RESTART要保证系统调用不被打断语义就必须加 SA_RESTART。二选一想清楚再用。3.4 信号处理中的工具函数_Exit() 与 write()信号处理函数讲究快、稳、短。你在这个函数里停留的每一微秒都是你程序正常逻辑停摆的时间。两个铁律要记死尽量只调用 async-signal-safe 的函数非异步信号安全的函数不要调用哪些函数是异步信号安全的这个表在 POSIX 标准里明确列出来了。常见的有write、read、_Exit、_exit、signal、sigaction、sigprocmask、sigpending、waitpid、getpid、open、close、unlink 等。常见的陷阱是printf、sprintf、malloc、free、strlen、strcpy——这些都不是。为什么 printf 在信号 handler 里危险因为 printf 内部可能加锁stdio 锁如果主流程执行到 printf 的临界区时信号来了handler 里再调 printf同一个线程面对同一个锁就死锁了。malloc 同理主流程可能在分配内存的过程中被信号打断handler 里再次 malloc 时会碰到处于中间状态的数据结构轻则崩溃重则内存损坏。正确的做法很多。最简单的是在 handler 里用一个普通变量置标志位主流程循环里发现标志位变了再执行复杂逻辑。或者用 POSIX 的 signalfd 把信号变成 fd 可读事件集成到 epoll 里统一处理。高级一点的用 self-pipe trick——在 handler 里往一个管道写一个字节主流程的 epoll 或 select 监视这个管道。我实际项目里最常用的就是设置标志位 write 管道二选一稳如老狗。4. 我踩过的坑和排查思路4.1 僵尸进程排查实录有次我负责的某个服务跑了大概 20 小时后在监控面板上看到进程句柄数一路飙升进程数也暴涨。第一反应是 fork 泄漏——创建子进程却没回收。登上去一看ps 输出里全是defunct进程僵尸一片。当时的问题出在父进程注册了 SIGCHLD handler但 handler 里只调用了一次 waitpidvoid handle_child(int signo) { (void)signo; waitpid(-1, NULL, WNOHANG); }这个代码在低并发下看着没问题但高并发下多个子进程同一时刻退出内核合并了 SIGCHLDhandler 只执行一次只回收其中一个子进程其余子进程就全部滞留成僵尸。修好方式就是前面说的——循环 waitpid 直到返回 0 和 -1。顺便说一下这条排查思路可以用在任何类似场景凡是发现僵尸进程99% 是 SIGCHLD handler 没循环回收或者干脆没注册 SIGCHLD。4.2 EINTR 错误SA_RESTART 不能根治一切一个网络服务读取客户端请求时突然报错“read: Interrupted system call”然后连接被关闭。EINTR 的正确处理方式不是一律加 SA_RESTART而是区分场景。对于 socket 读多写少的服务你希望保证连接的持续性加 SA_RESTART 是省事方案。但对于某些需要精确超时、需要根据 EINTR 判断外部事件的场景SA_RESTART 反而是障碍。我建议的通用做法是加 SA_RESTART 作为默认值然后在需要精确中断的少数地方比如 SIGALRM 超时单独用 sigaction 注册不重启的标志做到精细控制。4.3 volatile sig_atomic_t 的教训有一次某个 worker 进程莫名其妙“死等”——主循环里一直在跑但就是不做实际工作了。查了半天最后发现 handler 里设置了一个全局 int 标志位但主循环里这个标志位被编译器优化到寄存器里循环体里每次都读取旧值。编译优化不会看你的线程或信号上下文它只看数据流。修复方式就是给互斥变量加上 volatile 限定符并且使用 sig_atomic_t 类型。有些人用 sig_atomic_t 但是没加 volatile有些人加了 volatile 但类型还是普通 int 并且 int 在目标平台上读写不保证原子这两种都是隐患。写信号处理相关的共享变量时必须是volatile sig_atomic_t这是标准规定的“信号安全”变量类型我在 code review 里反复强调这条原则救回来好几个潜在崩溃项目。4.4 信号注册时机不要在共享状态未初始化前就注册一个隐性问题在 main 函数开头注册 SIGTERM handlerhandler 里需要访问一个全局配置结构体但这个结构体在注册 handler 之后、进入主循环之前才初始化。那么窗口期就出现了——“注册 handler”到“初始化配置”之间的某个瞬间如果来了 SIGTERMhandler 会访问一个未初始化的指针。这种 bug 极其隐蔽因为普通测试往往不会在启动后 5 毫秒内发信号但线上集群的监控探活程序就可能这么做。修复方式有三种一是先初始化全局状态再注册 handler二是用 pthread_sigmask 在注册前把所有信号阻塞等初始化完成后再解除三是在 handler 里加状态判断状态没有置为“就绪”就直接返回。我一般三种都用。4.5 多线程程序中的信号分发信号和多线程是另一个深坑。在多线程进程里标准信号是发给进程的具体由哪个线程处理其实由内核挑——通常是当前没有被阻塞的那个线程。这样你就无法预期哪一个线程会执行 handler这让很多设计变得不可控。我的建议是多线程程序里尽量避免用传统信号处理而是用 signalfd epoll把信号事件统一收进某个专门的线程处理。或者用 pthread_sigmask 在每条线程里屏蔽所有信号然后专门开一条“信号线程”用 sigwait() 统一取信号。这两种方式都能帮你把信号从异步地狱里拽回来变成同步可预测的事件。5. 按需使用的高级工具sigwait 与 signalfd5.1 sigwait把异步信号变成同步读取sigwait 函数提供了一种完全不同的信号处理思路#include signal.h sigset_t set; sigemptyset(set); sigaddset(set, SIGINT); sigaddset(set, SIGTERM); sigprocmask(SIG_BLOCK, set, NULL); int signo; while (1) { if (sigwait(set, signo) 0) { // 收到信号signo 告诉你具体是哪一个 // 这里的代码运行在正常线程上下文可以用任何库函数 } }sigwait 有两层含义。第一层是彻底回避了信号处理函数“异步”的天然属性——你不再有 handler你在同步读信号就像读一个管道一样。第二层是安全性的彻底解放——因为代码不在信号上下文里执行你可以放心地调 malloc、printf甚至加锁。这个模式在多线程、多进程优雅重启的代码里出场率非常高。主线程把所有关心的信号全部屏蔽掉然后起一个专门的线程用 sigwait 循环等待收到 SIGTERM 就做清理收到 SIGHUP 就重新加载配置收到 SIGUSR1 就手动触发一次日志轮转。代码结构清晰每个信号对应一个 case 分支任何语言的开发者读起来都没有障碍。5.2 signalfd让信号融入 epoll 生态signalfd 的意义在于把信号变成可读的 fd#include sys/signalfd.h #include signal.h sigset_t mask; sigemptyset(mask); sigaddset(mask, SIGINT); sigprocmask(SIG_BLOCK, mask, NULL); int sfd signalfd(-1, mask, SFD_NONBLOCK | SFD_CLOEXEC); // 然后 sfd 就可以丢进 epoll、select、poll 了在 eBPF、gRPC、Nginx 风格的网络服务里这套玩法是标配。信号不再是打断事件循环的“定时炸弹”而是跟新连接、可读 socket 一样均匀地出现在 epoll 的返回列表里。你用一个统一的循环处理网络 IO 和信号事件结构统一、没有竞态、不会因为某个信号处理函数阻塞而拖累整个进程。我自己的经验是写集成到现有网络框架里的服务优先用 signalfd写独立的守护进程sigwait 更省心需要轻量级、不引入额外复杂度的场景传统 sigaction 标志位最直接。工具没有优劣之分只有合不合适。5.3 信号还能做单实例锁最后分享一个非常实用的小技巧。用信号做单实例检查比文件锁更轻巧且更可控启动进程时注册一个 SIGUSR1 handler然后尝试给自己绑定一个固定的 PID 文件如果 PID 文件已存在尝试给那个 PID 发一个 SIGUSR2 信号能发成功说明那个进程还活着就退出发不成功说明 PID 已死可以接管。这种思路在防双开的服务进程中经常出现用起来比单纯检查 PID 文件存活状态更可靠因为 PID 文件正常存在但进程已崩溃的情况太常见了。写在后面几个实操体会信号这套机制我个人的体会是它是理解 Linux 系统行为的一个分水岭。很多人一直停留在“会用 kill”的阶段一旦遇到线上问题就摸不着头脑就是因为没有把这套生命周期、注册函数、阻塞、可重入函数、线程分发这些底层逻辑打通。一旦你亲手写完优雅退出的代码用 SIGCHLD 把几十万子进程收得干干净净再用 signalfd 把信号整合进 epoll你再看各种服务框架的源码很多看似晦涩的设计选择就豁然开朗了。最后再分享一个简单但救命的小技巧调试信号相关的行为时记得用strace -e tracesignal或者strace -f -e tracesignal跟踪信号分发情况。它可以把每个信号什么时候产生、发给哪个进程、用的什么 mask、由哪个线程接收和处理像日志一样打印出来。这比你在代码里猜半天高效一个数量级。真正复杂的问题栈和日志往往看不出来strace 一上真相立刻现行。这些就是我在信号机制上积累的实战经验希望能帮你在后续项目里少走几个弯路。有问题欢迎交流信号这块东西讨论越多越容易发现自己的盲区。
阅读完成 · 觉得有帮助？
