写第4篇信号处理的稿子来聊信号捕捉和中断的纠缠关系。前几篇把信号的基本概念、产生方式、阻塞和未决讲了这篇重点看信号从内核到用户态这一段路到底怎么走以及“信号”和“中断”这两个听着像、实际却不是一回事的东西经常把新手绕晕。先说一个现象。做嵌入式或者后端开发的人大概率都写过类似代码signal(SIGINT, handler);但如果你去翻那些老鸟写的代码尤其是涉及网络服务、守护进程这类需要长时间运行的场景基本没人用signal清一色sigaction。不是signal不能干活而是它在一个关键细节上太含糊这个细节恰恰就是“信号处理函数执行期间新来的同种信号要不要屏蔽”。这篇就把信号捕捉的完整机制讲清楚顺带把“中断”这个概念拉进来对比。你会发现信号从硬件层面看不是中断但从软件流程上看又处处在模仿中断。搞明白这层关系后面看EINTR、看sigreturn、看restart_syscall都不会觉得是碰运气。1. 信号从触发到处理的完整链路1.1 信号机制的本质是“异步通知”要理解信号捕捉先得建立一个整体认知信号本质上是内核向进程发的一条异步消息告诉进程“某件事件发生了”。这个事件的来源五花八门可能是用户按下CTRLC触发了SIGINT可能是程序自身执行了非法指令触发了SIGSEGV也可能是另一个进程通过kill()系统调用主动发过来。但有个关键点常常被忽略信号并不是被进程“立刻”处理的。内核只是把信号记录在进程的pending位图里标记一下“有个信号在等你处理”然后等待合适的时机再递送。这个“合适的时机”通常是进程从内核态返回用户态的那一刻比如一次系统调用结束、一次中断处理结束、或者进程被调度重新获得CPU。类比一下你正在工位上写代码同事走过来跟你说“下午三点有个评审会”你嘴上答应了但手头的活没停。等到三点整你放下手里的代码去会议室开会。同事通知你是“信号的产生”你到点去开会是“信号的处理”。中间这段时间你脑子里记住了这件事但并没有立刻放下一切去执行——这就是信号的“未决”状态。这个设计不是拍脑袋决定的。如果内核一产生信号就让进程立刻切换到处理逻辑会出现两类问题第一进程可能正在操作临界资源突然被打断会导致数据不一致第二信号处理函数要调用一系列库函数这些函数未必是异步安全的。所以Linux设计成“攒到安全时机再处理”这个时机就是用户态与内核态的切换点。1.2 信号处理的三条路默认、忽略、捕捉进程收到信号后内核会查一张表——进程的信号处置disposition表。这张表里每个信号对应一个动作无非三种默认动作大多数信号的默认动作是终止进程有些会附带core dump比如SIGSEGV。有些信号的默认动作是“忽略”比如SIGCHLD子进程状态变化。忽略进程显式告诉内核“这个信号我不要管”设置SIG_IGN。注意和默认动作里的“忽略”是两回事。捕捉进程提供一个自定义的处理函数信号递送时内核会安排这个函数在用户态执行这就是“信号捕捉”。信号捕捉的核心就是这个自定义处理函数handler。但这里有一个很多人没想明白的问题信号处理函数明明是一个用户态的函数凭什么能在进程不知道的情况下被调用要知道用户态代码的执行顺序本来是由main函数一路调下去的操作系统可没义务在固定位置插入你的handler。答案藏在“中断/异常返回路径”里。一个进程从用户态陷入内核态不管是因为系统调用、缺页异常、还是硬件中断最终都要走一段恢复用户态现场的路。Linux在执行iret或eret等架构对应的返回指令之前会检查TIF_NEED_RESCHED和signal pending这些flag。如果有信号要递送就先把用户态的寄存器上下文保存好然后修改一下返回地址让它指向信号处理函数。等这个函数跑完再通过一个专门的系统调用sigreturn恢复到之前保存的上下文继续执行原来被中断的代码。这个过程本质上就是一次“软中断”式的现场保护与恢复只是被保护的现场不是CPU硬件上下文而是进程的用户态上下文。这也是标题里“信号捕捉中断”最微妙的地方信号不是硬件中断但处理信号的动作处处在模拟硬件中断的处理流程。2. 信号捕捉的两个APIsignal与sigaction2.1 signal()只适合写Demosignal()的原型很简单typedef void (*sighandler_t)(int); sighandler_t signal(int signum, sighandler_t handler);用法也没什么门槛#include stdio.h #include signal.h #include unistd.h void on_sigint(int sig) { write(STDOUT_FILENO, Caught SIGINT\n, 14); } int main(void) { signal(SIGINT, on_sigint); while (1) { sleep(1); } return 0; }编译运行后按CTRLC进程不会退出而是打印一行提示继续跑。看着挺像那么回事。但signal()在Unix历史上有个大坑它的语义在不同系统上不一样。System V上信号处理函数执行期间这个信号会被自动重置回默认动作且处理期间屏蔽同种信号。BSD上则相反处理函数执行完后不会自动重置且处理期间不屏蔽同种信号。Linux的signal()默认遵循BSD语义但同时又可能受SA_RESETHAND等标志影响行为在不同glibc版本和内核配置下还有微小差异。更关键的问题是如果处理函数执行期间同种信号再次到达会发生什么在System V语义下信号被重置为默认动作第二次信号来了直接按默认动作打死进程。也就是说你写了handler想优雅地处理两次CTRLC结果第二次CTRLC直接让进程暴毙。用signal()根本控制不了这个行为。另外signal()也不支持屏蔽特定信号集比如你在handler里想临时屏蔽SIGTERM做不到。signal就是最简陋的“设个handler完事”适合写教学示例和临时脚本不适合做正式的服务端程序。2.2 sigaction()才是通用做法sigaction()能解决上述所有问题因为它的接口直接把“行为”和“选项”分开了int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);struct sigaction最关键的两个成员是sa_handler和sa_flagsstruct sigaction { void (*sa_handler)(int); void (*sa_sigaction)(int, siginfo_t *, void *); sigset_t sa_mask; int sa_flags; void (*sa_restorer)(void); };sa_handler就是自定义处理函数sa_mask告诉内核进入这个handler期间额外屏蔽哪些信号sa_flags用来按位控制各种行为细节。常用的sa_flags我先列出来后面实操会挨个验证SA_RESTART被信号打断的慢速系统调用自动重启。这是解决EINTR问题的关键选项。SA_NOCLDSTOP主要用于SIGCHLD子进程停止或恢复时不通知父进程。SA_SIGINFO不使用sa_handler改用sa_sigaction这样handler能拿到siginfo_t里面有发送信号的进程PID、信号产生原因等详细信息。SA_RESETHAND进入handler后将信号处置重置为默认动作相当于System V的古老语义。SA_NODEFERhandler执行期间不屏蔽同种信号。和signal()相比sigaction()最大的改进在于你可以明确指定handler执行期间屏蔽哪些信号也可以选择不屏蔽可以选择被打断的系统调用是否自动重启还能拿到信号来源的详细信息。代价就是接口稍微复杂一点。2.3 slack出一个对照表能力signal()sigaction()设置自定义handler支持支持获取siginfo详细来源不支持支持SA_SIGINFOhandler期间屏蔽指定信号不支持支持sa_maskhandler期间屏蔽同种信号行为随系统/glibc版本变化默认屏蔽可用SA_NODEFER关闭系统调用被打断后自动重启不支持支持SA_RESTART行为一致性跨平台差异大符合POSIX标准行为明确我自己的习惯是写演示代码用signal()写任何要长期运行的、不敢确定行为边界的程序一概sigaction()。你要是接手过老项目看到代码里还有signal()多半要么是历史遗留要么是写的人没踩过那个“二次信号秒杀”的坑。3. 中断与信号兄弟关系还是父子关系3.1 中断是CPU层面的概念信号是进程层面的概念“中断”在计算机体系结构里是个硬件术语CPU的某个引脚收到电平变化外部中断或者执行到某个特殊指令如int 0x80软中断/系统调用CPU会暂停当前指令流跳转到中断向量表对应的处理程序。这个处理程序运行在内核态处理完再恢复现场。“信号”则是操作系统提供的软件层面的进程间异步通知机制。它不依赖具体CPU硬件只要是Linux能跑的平台信号语义都一致。但两者有一个很深的联系很多信号的源头就是中断或异常。比如你按一下键盘的CTRLC键盘控制器产生硬件中断中断处理程序最终把SIGINT投递给前台进程组你访问了一个非法内存地址CPU触发缺页异常/保护异常异常处理程序最终把SIGSEGV投递给当前进程。所以可以说信号是“中断/异常这种底层事件被OS翻译成进程能感知的语言”的一种结果。反过来进程接收到信号去执行handler的过程也复用了中断返回路径。前面说了内核在返回用户态之前检查是否有pending信号如果有就修改用户态的指令指针让它先跑去执行handler。这一步本质上是“伪造”了一次异步过程调用和中断处理里的“跳转到中断服务程序”思路高度一致。3.2 慢系统调用与EINTR的由来理解了“内核在返回用户态时递送信号”后就能解释一个现象为什么一个阻塞中的read()调用收到信号后可能返回-1并且errno被设成EINTR。假设进程调用read()从终端读数据但终端上没有任何输入。内核让进程进入睡眠把它挂到等待队列上。这时来了一个信号内核要把信号递送给进程。但进程当前正在内核态执行read()的系统调用代码状态是“睡眠中”。怎么办Linux的做法是先唤醒进程让他从read()的内核路径返回返回前查一下pending信号发现有信号就去执行handler。但这样一来read()这个系统调用就没执行完。用一次调用换来一个没执行完的半成品返回值自然要说清楚——返回-1并把errno设为EINTR意思是“我没被打死但被打断了”。这个过程你可以理解为信号打断了内核正在执行的“慢速”操作就像电话打断你正在进行的线下排队。你接完电话发现队伍已经散了还得重新排。不过EINTR也不全是坏事。它给程序员一个机会在read()被打断后主动决定是继续读、放弃读、还是先干点别的。比如网络编程里accept()被信号打断是很常见的不做处理的程序就可能莫名其妙返回失败。很多新手在accept()返回-1时没查errno是不是EINTR直接把进程退出了这就是“信号重击穿了中断处理”的典型事故。3.3 SA_RESTART让内核帮你重试如果你不想每次都在代码里判断EINTR可以用sigaction()的SA_RESTART标志。这位翻译是信号处理函数返回后由内核自动重新发起那个被中断的系统调用。比如#include stdio.h #include signal.h #include unistd.h #include errno.h #include string.h void on_alarm(int sig) { write(STDOUT_FILENO, alarm!\n, 7); } int main(void) { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler on_alarm; sa.sa_flags SA_RESTART; sigaction(SIGALRM, sa, NULL); alarm(2); char buf[128] {0}; ssize_t n read(STDIN_FILENO, buf, sizeof(buf) - 1); if (n 0) { printf(read err: %s\n, strerror(errno)); } else { buf[n] \0; printf(got: %s\n, buf); } return 0; }运行这个程序2秒后SIGALRM触发read()还在阻塞。因为设置了SA_RESTART内核会在handler跑完后自动帮我们重新发起read()所以errno不会是EINTRread会继续等输入。把SA_RESTART注释掉再跑一次read()返回-1errno是EINTR。需要注意SA_RESTART不是万能的。某些系统调用如poll()、epoll_wait()、nanosleep()在某些内核版本上即使设置了SA_RESTART也可能返回EINTR。所以“依赖SA_RESTART”和“手动处理EINTR”不是二选一而是在多数场景都要掌握的技能。我的经验是对于重要的系统调用永远默认“可能被中断”把它写成循环重试例如while ((n read(fd, buf, len)) 0 errno EINTR) { /* retry */ }这样即使别人将来改掉了SA_RESTART你的代码也不会出问题。4. 实操从零写一个带信号捕捉的守护型进程模板4.1 场景需求优雅退出与配置重载我挑一个非常典型的业务场景来演示写一个长时间运行的进程要求收到SIGTERM、SIGINT时能优雅退出释放资源、保存状态。收到SIGHUP时能重新加载配置文件而不是退出。多个信号同时到达时不出现“二次进handler”导致脏数据的问题。这个场景在Nginx、Redis这类服务里非常常见。不夸张地说只要能跑通这套逻辑你就算是掌握了信号捕捉的七成功力。4.2 完整代码与编译运行直接看代码。我保留了注释方便一行行对照理解#include stdio.h #include stdlib.h #include string.h #include unistd.h #include signal.h #include errno.h static volatile sig_atomic_t g_running 1; static volatile sig_atomic_t g_reload 0; static void handle_signal(int sig) { if (sig SIGTERM || sig SIGINT) { g_running 0; } else if (sig SIGHUP) { g_reload 1; } } static int set_signal_handler(int sig) { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler handle_signal; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART; /* 进入handler期间屏蔽掉这几个信号防止重入 */ sigaddset(sa.sa_mask, SIGTERM); sigaddset(sa.sa_mask, SIGINT); sigaddset(sa.sa_mask, SIGHUP); if (sigaction(sig, sa, NULL) 0) { perror(sigaction); return -1; } return 0; } static void do_reload_config(void) { /* 模拟重新加载配置 */ write(STDOUT_FILENO, reload config...\n, 17); } int main(void) { if (set_signal_handler(SIGTERM) 0 || set_signal_handler(SIGINT) 0 || set_signal_handler(SIGHUP) 0) { exit(EXIT_FAILURE); } write(STDOUT_FILENO, daemon start\n, 13); while (g_running) { if (g_reload) { g_reload 0; do_reload_config(); } sleep(1); } write(STDOUT_FILENO, daemon exit\n, 12); return 0; }编译运行gcc -Wall -O2 -o sigdemo sigdemo.c ./sigdemo另开一个终端试试这些操作kill -HUP $(pgrep sigdemo)终端会打印reload config...进程继续运行。kill -TERM $(pgrep sigdemo)终端会打印daemon exit进程结束。这段代码有几个设计细节值得品味volatile sig_atomic_t在信号处理函数里读写全局标志位必须用volatile防止编译器优化掉读取操作sig_atomic_t保证读写是原子的不会读到撕裂的值。这是写信号处理函数的铁律。主循环里检查g_reload而不是在handler里直接做重载逻辑handler只负责设置标志位。原因在于handler里能安全调用的函数极其有限printf、malloc这些动内部锁的都不行所以把重活放到主循环里做。sa_mask屏蔽同种信号一个handler没跑完同种信号再来会被暂时阻塞避免重入导致标志位状态错乱。4.3 执行流程拆解看一次信号处理走过的路光能跑通还不够我把一次kill -TERM从发起到进程退出中间发生的事拆成一段一段的方便你真正理解kill(pid, SIGTERM)是系统调用进程从用户态陷入内核态。内核在目标进程的pending信号位图里置位。此时进程可能正在sleep()处于睡眠状态。内核唤醒进程让它从sleep()返回返回路径上检查到有pending信号。内核处理SIGTERM的处置设置发现是自定义handler于是把当前用户态上下文寄存器、栈指针、指令指针等保存到进程的内核栈里临时把用户态指令指针改成handle_signal函数的地址并重建信号帧。进程回到用户态CPU开始执行handle_signal。注意此时栈上被内核放置了一个特殊的信号帧里面保存着之前被中断的上下文还有sigreturn系统调用所需的信息。handle_signal把g_running置0返回到特殊代码段触发sigreturn系统调用。sigreturn告诉内核我处理完了你把我之前保存的现场恢复吧。内核恢复第4步保存的上下文进程回到被中断前的用户态代码——也就是sleep()返回之后的位置。主循环检查g_running发现是0退出循环打印daemon exit。这套“陷入内核→伪造现场→跑handler→sigreturn恢复现场”的流程就是Linux信号处理的经典路径。很多人只知道handler会被调用却不知道中间还藏着一次额外的系统调用。学会用strace观察这个流程会有种豁然开朗的感觉strace -f -e tracesigreturn,sigaction,kill ./sigdemo看到restart_syscall和sigreturn这些没有显式写在你自己代码里的系统调用就明白内核在背后做了多少事。5. 信号处理的坑实战经验速查5.1 不可重入函数handler里的两条红线信号处理函数执行时进程的主控制流是被“打断”的。如果你在handler里调用了printf、malloc这类函数而正好主程序也在调用同一个函数就可能出现两个执行流交叉进入同一个非线程安全函数的情况。举个例子主程序正在调用printf输出数据执行到一半printf内部的缓冲区锁刚被拿走信号来了handler里又调了printf锁已经被主程序拿走了handler就会阻塞等待但主程序此时已经被“暂停”在锁里了——形成一个死锁。表现就是进程卡死看起来像假死gdb也难定位。信号处理函数里的操作必须限定在一个很小的集合内。POSIX规定了一批“异步信号安全函数”比如read、write、open、close、_exit、sigaction、sigprocmask等printf、malloc、free、pthread_mutex_lock这些统统不在列。我自己的原则很简单handler里只做volatile sig_atomic_t标志位赋值最多再write一个字节到日志fd。其他所有逻辑全部放到主循环里通过检查标志位来执行。真的需要在信号响应里做复杂操作可以考虑“自pipe”技巧handler里write一个字节到管道主循环read管道后执行实际逻辑。这样可以完全避开不可重入问题。5.2 全局标志位需要volatile sig_atomic_t编译器优化是一个很大的隐藏杀手。看这段代码static int g_flag 0; void handler(int sig) { g_flag 1; } int main(void) { while (g_flag 0) { /* busy loop */ } return 0; }理论上收到信号后g_flag被改成1循环退出。但gcc -O2编译时编译器发现g_flag在整个主循环里没有被修改于是很可能把读取g_flag的操作优化到循环外也就是说循环体变成了死循环信号来了也跳不出去。加上volatile就能阻止这种优化static volatile sig_atomic_t g_flag 0;volatile告诉编译器这个变量的值可能被外部改变每次都要重新从内存读。sig_atomic_t则保证读写操作在信号处理场景下是原子的。这两者组合是信号处理函数和主循环共享状态的唯一安全简单方式。5.3 标准信号不排队别指望不丢信号标准信号1~31有一个非常重要的特性它们是不排队的。也就是说如果进程在SIGTERM还未处理时又收到一个SIGTERM内核只会把pending位图里的那一位置1然后计数归1。第二个信号在处理完第一个之前等于“白来了”。这个特性意味着如果你的业务逻辑里信号代表一种“事件计数”那就不能用标准信号。比如你期望“收到10次信号就处理10次”用标准信号必然丢。解决办法有两个方向改用实时信号SIGRTMIN及以上。实时信号支持排队信号值本身还能携带一点业务信息通过sigqueue发送。如果不想引入实时信号的复杂性就用“信号只当敲门砖具体事件自己记账”的思路handler里只把标志位置1主循环自己维护计数器每次处理完重置标志位。因为处理逻辑在主循环而主循环会在每个周期把标志清掉所以不存在丢了标志就丢事件的问题。5.4 interrupted系统调用除了EINTR还要关注nanosleep和ppoll前面提到SA_RESTART但要特别说明nanosleep()、poll()、epoll_wait()这类“阻塞等待类”系统调用即使在设置了SA_RESTART的情况下某些内核版本/场景下也可能返回EINTR。这是POSIX允许的SA_RESTART只保证一部分“慢速系统调用”重启并没有把所有系统调用都覆盖。我自己踩过的一个真实坑是用epoll_wait()做事件循环某次线上机器上出现大量线程被唤醒后立即返回日志里全是EINTR。排查了一圈才发现是监控agent发了个实时信号过来而程序对EINTR没有处理导致事件循环以为有事件要处理空转了好几次才继续epoll_wait。因此我现在写事件循环都有一个固定模板for (;;) { ret epoll_wait(epfd, events, maxevents, timeout); if (ret 0) { if (errno EINTR) { continue; } break; /* real error */ } ... }5.5 信号屏蔽不要乱用sigprocmasksigprocmask()可以让你主动阻塞某些信号也可以清空阻塞。用的不多但有一类场景很典型多线程程序里用pthread_sigmask把某些信号阻塞住然后由一个专属线程用sigwait统一处理。为什么多线程程序不建议用“每个线程各自设handler”因为Linux的进程信号是发给进程的但由哪个线程处理是由内核挑选的。多个线程抢着处理一个信号行为很难预测。用sigprocmask/pthread_sigmask把信号阻塞在所有业务线程里再单独开一个信号处理线程调用sigwait去“收信号”是更可控的模式。注意sigprocmask是进程级的在多线程里要配合pthread_sigmask使用否则行为不一定符合预期。5.6 调试信号问题的三板斧kill -l列出所有信号名称和编号。标准信号1~31实时信号32~64。strace -e signal跟踪进程收到的信号。能看到信号编号和handler行为但不能直接看到handler内部。gdb里的handle SIGTERM stop让信号到达时先停下你可以看进程状态、调用栈再决定是否继续。有一次我在调试一个“进程收到SIGPIPE就静默退出”的问题刚开始百思不得其解。后来用strace发现是某个socket write触发了EPIPE内核随后发SIGPIPE默认动作直接终止进程。解决方式是在启动时忽略SIGPIPE或者给socket写入函数加上MSG_NOSIGNAL标志。这类问题排查路径非常典型遇到“进程没打日志就消失”的情况优先怀疑信号默认动作。6. 写在最后的经验沉淀信号捕捉和中断机制在Linux系统编程里属于那种“花两天学完、要花两年踩坑”的知识点。它看似简单——不过是一个回调函数注册但真正牵扯到内核的执行流切换、系统调用的中断与重启、异步安全和可重入性这些底层问题时处处是坑。我从自己实际项目里总结出几条特别想分享给后来者的体会第一handler里绝不做重活。不管你是写redis还是写单片机上的RTOS任务凡是能在主循环里轮询的标志位绝不放到回调里执行。信号处理函数就是“记一下、喊一嗓子”的角色复杂逻辑一旦进去就是不定时炸弹。第二统一用sigaction别用signal。这个决定看起来只是选择偏好但实际能帮你少踩很多语义差异的坑。尤其当你把代码从Linux移植到其他类Unix系统时signal在System V和BSD之间的行为差会直接制造线上故障。第三永远假设系统调用会被信号打断。每个阻塞调用都写一个EINTR重试逻辑比依赖SA_RESTART更稳妥。这不是代码冗余而是防御性编程。你永远不知道哪个第三方库会在某个信号处理函数后修改sigmask或者哪个内核版本对SA_RESTART的支持区间有变化。第四理解“内核返回用户态”这个递送时机比死记API重要得多。一旦想通了信号是在系统调用/中断返回路径上被递送的EINTR、sigreturn、SA_RESTART这些概念就都串起来了。信号之所以和中断纠缠在一起是因为它在实现层面确实复用了中断控制流的那套机制。信号处理的上半部分也就是捕捉和中断的机制到这里基本说透了。下一篇可以接着聊实时信号、sigqueue和跨线程信号处理那又是另一片天地。