1. 先搞清楚信号是什么不是队列不是异常是异步事件通知1.1 信号的本质是“事件通知”而不是“错误”搞Linux后台服务的人大概率都经历过这么一幕程序跑得好好的突然就没了。查dmesg发现是被OOM killer干掉的翻系统日志发现收到了SIGTERM却没做任何处理直接按默认行为退出了。更麻烦的是那种读写写到一半、临时文件刚落地就被信号打断的场景。这些问题的根源往往不是程序逻辑本身出错而是你根本没有真正理解进程信号也没弄明白信号从产生到处理要穿过用户态和内核态多少次。很多人一听信号第一反应就是程序崩溃、段错误。其实信号是一种异步事件通知机制它和“异常”是两回事。信号可以由任何进程通过kill()主动发出来也可以由内核因为外部事件触发比如你在终端按下CtrlC终端驱动就会向前台进程组发送SIGINT再比如子进程退出时内核会给父进程发SIGCHLD。你可以把信号理解成操作系统层面的“轻量级消息”它只传递一个编号不携带数据负载它是异步的可以在目标进程执行任意指令时插入目标进程可以选择忽略、捕捉并处理或者按默认行为面对。我一直用“轻量级消息”这个说法而不是“异常”因为信号大多数时候不是程序出了毛病而是有人或内核在告诉你某个事件发生了你需要做出响应。搞清了这一点后面理解信号捕捉的全部设计逻辑都会顺畅很多。1.2 常用信号速查哪些能捕捉、哪些不能Linux下信号数量说多不多说少不少。我实际写服务时高频接触的也就是下面这几个信号编号典型触发场景默认行为SIGHUP1终端挂断、会话关闭终止进程可捕捉SIGINT2终端CtrlC终止进程可捕捉SIGQUIT3终端Ctrl\终止进程 core dumpSIGKILL9kill -9 强制杀终止进程不可捕捉/忽略SIGTERM15kill默认发送终止进程可捕捉SIGCHLD17子进程退出或暂停忽略SIGSEGV11非法内存访问终止 core dumpSIGUSR110用户自定义终止可捕捉SIGUSR212用户自定义终止可捕捉SIGSTOP19暂停进程暂停不可捕捉/忽略SIGCONT18继续运行被暂停进程继续运行可捕捉这里最容易被记错的一点是SIGKILL和SIGSTOP是唯二不可被捕获和忽略的信号。SIGKILL连handler都没机会执行直接由内核强制执行SIGSTOP也一样你不能通过捕捉SIGSTOP来阻止进程暂停。所以网上有些教程“教你优雅处理SIGKILL”纯粹是误导SIGKILL的设计目标就是最终手段不给你留任何商量余地。1.3 传统信号是“位图”而不是“队列”这一点对理解信号行为非常关键。传统的1~31号信号在内核里并不是用队列维护的而是用位图bitmap。同一个信号短时间内来了10次目标进程的pending集合里也只有一个bit位被置1。换句话说信号不是“计数型”通知而是“通知型”的。举个例子你的进程注册了SIGINT处理函数但handler正在执行时又来了两个SIGINT那这两个新信号很可能在恢复执行后被合并处理一次甚至丢失掉。对绝大多数业务场景这无所谓但对那些希望“精确计数”的设计就是个大坑——你不能靠传统信号去统计事件发生的次数。实时信号34~64号才是队列式的可以排队能携带附加数据。这点我放到后面实战章节详细说因为传统信号的位图语义直接决定了我们把handler设计成“只置标志位、不干活”的必要性。2. 用户态与内核态为什么信号处理必须“借道”内核2.1 两个世界的划分与保护机制现代CPU有特权级别x86体系下是ring0到ring3。Linux只用两个级别内核态ring0和用户态ring3。内核态可以执行所有特权指令比如操作页表、访问硬件寄存器、开关中断用户态则被层层限制连直接读写外设都不行。为什么要这么分因为如果不分任何程序都能直接碰硬件、改系统数据那随便一个野指针就能把整台机器搞崩。内核把“敏感资源”全部圈在自己手里用户程序想要什么只能通过系统调用提交请求内核检查完合法性后代劳再把结果返回。这就是最基本的保护模型。我经常用餐厅打比方用户态是顾客内核态是后厨系统调用是点单。顾客不能自己冲进后厨炒菜只能把需求告诉服务员由后厨做好了端出来。信号处理也是一样的逻辑——你写的自定义handler是“顾客”的代码但把信号送到你手上这件事必须经过“后厨”内核来安排。2.2 什么时候会发生态切换用户态和内核态的切换主要有三类来源系统调用进程主动发起read、write、open、kill、mmap等这是最主动、最可控的切换。执行系统调用指令后CPU进入内核态在内核栈上执行syscall对应的处理函数完事再返回用户态。中断硬件设备需要CPU关注时比如网卡收到数据包、磁盘完成IO、内核时钟周期性tick都会触发中断。中断是异步的哪怕用户态正跑普通代码CPU也会被迫切到内核态执行中断处理程序。中断处理完再返回被打断的用户态指令。异常CPU执行指令时发现异常比如缺页、除零、非法指令。异常会从当前指令状态陷入内核来处理处理完毕再恢复执行或者按策略终止进程。信号传递恰好横跨这三类场景。比如CtrlC导致SIGINT源头是终端硬件中断普通程序用kill()主动发信号走的是系统调用而进程正在执行非法内存访问触发SIGSEGV本质是异常路径。2.3 一次切换的代价和你为什么要关注它每次用户态↔内核态切换CPU都需要切换栈指针、保存寄存器上下文、做权限检查。单次切换的纳秒级开销在低强度程序上体感不明显但在高频IO场景下比如每秒几十万次read/write的服务切换成本会占据相当比例的CPU时间。这也是为什么高性能网络服务都在拼命减少切换次数要么用readv/writev做批量IO要么上mmap共享映射要么直接用io_uring这种异步批量提交模型。理解了态切换成本就能理解很多性能优化的底层逻辑。信号处理本身也会引入切换所以设计handler时“越轻量越好”不是洁癖而是实打实的性能考量。3. 从signal到sigaction代码怎么选、怎么配才算“能上生产”3.1 signal为什么只适合写demo新手写信号捕捉第一个接触的必然是signal()函数因为它简洁到一句话就能注册handlersignal(SIGINT, my_handler);但简洁的代价是行为不可预期。POSIX之所以后来推出sigaction()就是因为在不同的UNIX实现里signal()的语义差异非常大。System V的signal默认在handler执行期间把该信号重置为默认行为这意味着第一次信号被捕捉后第二信号到达时进程直接按默认方式退出BSD的signal又不一样它默认保持handler注册。glibc在Linux上做了BSD语义的兼容但你在其他平台上跑同一套代码行为可能就变了。另外signal()能拿到的上下文信息极其有限你没法知道是谁发的信号、为什么发、当时进程是什么状态。遇到线上问题想靠handler打印点诊断信息signal()根本不够用。3.2 sigaction的结构与关键参数sigaction()的完整形态#include signal.h struct sigaction { void (*sa_handler)(int); // 简单handler void (*sa_sigaction)(int, siginfo_t *, void *); // 带信息的handler sigset_t sa_mask; // handler执行期间额外阻塞的信号集 int sa_flags; // 控制行为 void (*sa_restorer)(void); // 已废弃不用管 };调用方式struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler my_handler; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART; sigaction(SIGTERM, sa, NULL);这里重点说三个细节都是实际项目里最容易踩坑的地方sa_mask指定在handler执行期间需要额外屏蔽的一组信号。比如你希望在处理SIGTERM时同类型的SIGTERM不要嵌套进来打断你那就把SIGTERM加进sa_mask。默认情况下触发handler的那个信号在handler执行期间是被自动屏蔽的这点和System V的signal不同。SA_RESTART这个标志决定了当handler执行完毕后被信号打断的系统调用是自动重新执行还是返回-EINTR。比如进程正在阻塞等待read()此时SIGTERM到达handler执行完返回后如果设置了SA_RESTARTread()会重新发起等待如果不设置read()直接返回-1并设置errno为EINTR。生产环境大量SA_RESTART是因为很多业务逻辑根本没法优雅处理EINTR。SA_SIGINFO设置这个标志后系统会调用sa_sigaction而不是sa_handler回调参数里会带一个siginfo_t结构体里面包含发送者的PID、UID、信号编号等。对排查问题非常有用。3.3 一个生产级捕捉SIGTERM和SIGINT的示例我写了这么多年代码最常用的一种模式就是“handler置标志位 主循环轮询标志位”。直接看代码#include stdio.h #include signal.h #include string.h #include unistd.h static volatile sig_atomic_t g_flag 0; static void handle_term(int sig) { // 这里只做一件事置标志 g_flag sig; } int main(void) { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler handle_term; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART; sigaction(SIGTERM, sa, NULL); sigaction(SIGINT, sa, NULL); while (1) { // 主循环业务逻辑 if (g_flag) { printf(receive signal %d, do cleanup...\n, g_flag); fflush(stdout); // 这里做真正的资源清理比如关闭文件、释放锁、落盘 break; } usleep(100 * 1000); } return 0; }这个代码里最讲究的一点是volatile sig_atomic_t。sig_atomic_t是C标准保证在信号处理函数中可以安全读写的整数类型volatile是为了防止编译器把对g_flag的读写优化到寄存器里——如果不加volatile主循环里对g_flag的读取可能永远拿的是CPU寄存器里的旧值信号来了也感知不到。3.4 为什么我在生产代码里从不推荐signal结论很明确如果代码要进生产环境直接用sigaction。理由就是上面说的三点可移植性、信息量、可控性。signal()并非完全不能用但在一个多人维护的工程里你没法保证换个人、换个平台后行为不被改变。sigaction虽然写起来啰嗦但它把语义都摆在明面上后面维护的人看一眼sa_flags就知道代码期望什么样。代码可读性也是生产力。4. 信号从kill()到handler的完整旅行两次切换、一个关键检查点4.1 发送阶段kill()系统调用后内核做了什么如果不把“信号从哪来、到哪去”从头到尾捋一遍你很难理解为什么handler的执行时代总是“晚半拍”。我把这个传递路径拆开讲。第一步调用方执行kill(pid, sig)。从库函数到内核最终触发系统调用进入内核态对应内核的sys_kill。内核会先做权限校验——比如你是否有权限向目标进程发信号。校验通过后内核找到目标进程的task_struct把这个信号挂到目标进程的pending位图上。注意这个“挂”字到这里为止内核做的事情只是把信号标记为“有待处理”并没有真正执行任何用户态handler。如果目标进程正处在可中断睡眠状态比如阻塞在read上等待输入内核在挂上信号后还会检查一下这个进程是否正在睡眠、这个信号能不能唤醒它。如果能唤醒就把它唤醒让它有机会回到用户态去处理信号。4.2 pending与blocked信号为什么有时候“收而不发”每个进程有两个关键集合pending待处理集合已经到达但还没递达给进程的信号位图。blocked阻塞集合当前被进程屏蔽的信号位图。如果发送过来的信号在目标进程的blocked集合里这个信号虽然会被放进pending但不会立即递达。它得一直挂在那儿直到进程通过sigprocmask()把该信号从blocked里移除才有机会被处理。这种机制很有用。比如你正在构造一份关键数据结构不希望中途被SIGTERM打断就可以临时把SIGTERM加入blocked做完关键段再解除阻塞期间堆积的信号会一次性检查处理。4.3 返回用户态前的检查信号真正被执行的地方这是全篇最核心的一句话信号的handler不是在“信号到达那一刻”执行的而是在目标进程下一次从内核态返回用户态之前由内核检查pending后安排的。具体来说内核在完成系统调用、中断或异常处理后准备返回用户态之前会调用一个类似do_signal的逻辑。它扫描进程的pending集合找出所有未被blocked的信号。如果找到了内核会做三件事把信号从pending里摘除修改用户态栈帧把原来要返回的用户态代码地址改写成handler的入口地址保存当前的用户态寄存器上下文。这样一来CPU从内核返回后执行的第一段用户代码就不再是刚才被打断的地方而是handler函数。等handler执行完再通过sigreturn()系统调用恢复原先保存的上下文继续执行之前被打断的指令。从这个机制能推出一个重要结论如果一个进程长期处于不可中断睡眠状态D状态比如在等磁盘IO且不可被信号唤醒那么即使你给它发信号信号也迟迟不会被处理直到它脱离D状态回到用户态。用kill命令杀一个D状态进程时经常“杀不动”原因就在这儿。4.4 handler为什么放在用户态执行而不放在内核态你可能会有个疑问既然内核已经接管了信号传递为什么不干脆在内核里直接调用handler省得折腾往返切换原因是多方面的安全handler是用户写的任意代码内核态一旦执行用户代码等于把内核的整个安全边界拆了。一旦handler里有漏洞比如数组越界、野指针直接变成内核漏洞整个系统都可能沦陷。内核栈太小内核栈通常只有几KB到16KB根本容不下用户态复杂的调用栈。用户栈可以按需申请动辄MB级别。内核完整性内核要保持自己的逻辑简洁、可控把信号执行语义放到用户态是实现选择上的必然结果。所以信号的完整生命周期必然经历至少两次用户态↔内核态切换kill()系统调用用户态→内核态→用户态返回用户态前发现信号、重置栈帧本质上还是返回用户态handler执行完后调用sigreturn()用户态→内核态→用户态恢复现场。4.5 handler之后sigreturn如何恢复现场handler执行完的最后一条指令并不是ret而是调用一个由内核在创建信号帧时放置的恢复代码通常叫__kernel_rt_sigreturn。这个恢复代码执行后会触发sigreturn()系统调用再次进入内核。内核从用户栈上的信号帧里取出之前保存的寄存器上下文、信号掩码等全部恢复然后返回用户态目标进程从原打断点继续执行。这也是为什么单线程程序里如果handler里调用了类似exit或_exit整个进程会直接退出——因为根本没走到sigreturn。5. handler里的“雷区”与正确姿势printf为什么不能碰5.1 一个真实场景主程序与handler交错访问很多新手写信号处理喜欢在handler里直接printf打日志看着挺方便。但这是大忌。我举个具体例子主流程正在往stdout写一大段日志printf内部可能要拿到stdout的锁数据写到一半信号到了handler里也调printf想打一行“收到信号”。这时候两个printf对同一把锁的操作就交错到一起了。因为handler是在主线程的执行流里以“借栈帧”方式运行的它和主逻辑其实是在同一个线程里抢同一堆资源。一旦主逻辑和handler都碰同一个非线程安全的东西死锁、输出错乱、内存踩踏都可能发生。信号处理函数要求可重入或异步信号安全。可重入的意思是函数在执行过程中被信号打断然后handler里再次调用同一个函数两个调用必须互不干扰结果仍然正确。实践中能保证这种性质的函数少之又少。5.2 async-signal-safe函数清单Linux的man 7 signal手册里给了一份async-signal-safe函数清单。我挑实际常用的列在下面安全常用函数IO类read、write、open、close、lseek、fcntl、dup、dup2、fsync进程类_exit、_Exit、kill、raise、getpid、getppid、fork、execve信号类sigaction、sigprocmask、sigemptyset、sigaddset、sigismember时间类clock_gettime、nanosleep不在清单里的比如printf、malloc、free、互斥锁相关的pthread_mutex_lock统统不要出现在handler里。printf不是总能拿到锁吗malloc为什么要额外注意因为malloc内部用堆管理结构而主逻辑可能正好malloc执行到一半信号插进来再次malloc堆就会被破坏。规则可以概括成一条handler里能调用的函数要么是系统调用级的封装要么是明确标注为async-signal-safe的入口其余一概不碰。5.3 handler里的标准解法flag 主循环那handler里想打日志、想释放内存、想清理资源怎么办正确做法是把“动作”留在主循环里执行handler只负责“通知”。上面第3章的示例代码就是这个模式的完整实现handler里只做g_flag sig这一件事主循环检测到flag后再去调printf、close、free等任何你想做的操作。这时候主线程是正常执行流函数调用不会被信号打断安全性由常规同步机制保证。需要注意在多线程场景下volatile sig_atomic_t并不等于原子操作。C11之前的标准对跨线程原子性没有强制保证所以如果多个线程都要读这个flag建议用sig_atomic_t配合锁或者直接用C11的atomic_int。单线程信号处理模式下volatile sig_atomic_t基本够用。5.4 两个隐蔽的竞态EINTR与“半初始化状态”即使用了flag 主循环还有两个坑容易在线上才暴露。第一个是EINTR。如果系统调用没有设置SA_RESTART那么当进程阻塞在read()、wait()这类调用上时信号一来系统调用会立刻返回-1errno被设为EINTR。如果你的业务代码没有对EINTR做重试或重新判断程序就会把一个“被打断”当成真实错误处理。我见过不少同事排查了半天最后发现是EINTR导致业务误报。解决办法有两个能用SA_RESTART就用不能用的话代码里要显式处理errno EINTR的情况。第二个问题更阴信号比初始化更早到达。进程刚启动还没注册handler或者handler需要的共享资源还没初始化好外部信号就已经把默认行为触发了。比如你在修改配置文件后发SIGHUP让进程重新加载配置如果此时配置解析器还没初始化完成进程可能直接崩掉。防御手段是把整个初始化阶段的关键信号加入blocked集合等所有资源都就绪后再用sigprocmask解除阻塞。6. 工程实战优雅退出、多线程信号路由与验证手法6.1 用SIGTERM做优雅退出状态机思路生产环境的守护进程用SIGKILL直接从外部强杀是非常粗糙的做法正常流程应该设计成“收到SIGTERM后优雅退出”。我习惯把这套逻辑实现成一个简单状态机初始状态运行中RUNNING收到SIGTERM/SIGINThandler置标志位状态进入“退出中”STOPPING主循环检测到STOPPING状态停止接收新请求、拒绝新任务入队把在途任务执行完刷新缓冲区、关闭文件描述符、释放锁、落地状态退出循环调用exit()收尾。这套设计的核心是信号只负责“请求退出”不负责“立刻退出”。业务能不能立刻退得由程序自身判断。举个例子一个正在写数据库事务日志的进程收到SIGTERM后直接崩溃退出日志半截重启后还得做繁琐的恢复但如果给它几秒钟把缓冲刷完再退数据完整性就保住了。所以生产进程的SIGTERM handler里经常能看到设置一个“退出时限”超时仍未清理完再考虑强退。6.2 多线程进程的信号路由pthread_sigmask sigwait多线程环境下的信号处理比单线程麻烦不少。Linux里信号发往进程时系统会选择线程组中的某个线程来递达具体选哪个取决于信号是否被某个线程阻塞。如果不做任何控制SIGTERM可能随机落在任意线程上处理逻辑和线程上下文纠缠在一起很容易出问题。我推荐一种很稳的设计主线程屏蔽全部信号然后由一个专职线程用sigwait()统一接收处理。例如sigset_t set; sigemptyset(set); sigaddset(set, SIGTERM); sigaddset(set, SIGINT); pthread_sigmask(SIG_BLOCK, set, NULL); // 新开一个线程专门处理信号 pthread_t tid; pthread_create(tid, NULL, signal_thread, set); // 主线程继续做正常业务完全不用关心信号signal_thread里执行的是同步的sigwait调用void *signal_thread(void *arg) { sigset_t *set (sigset_t *)arg; int sig; while (1) { sigwait(set, sig); // 同步等待信号 if (sig SIGTERM || sig SIGINT) { // 置全局退出标志通知业务线程协作退出 } } }这样信号处理和业务调度彻底分离信号处理函数不再是“异步打断”而是变成了一个同步逻辑写起来安全得多。注意屏蔽信号的设置必须在创建业务线程之前完成否则其他线程会继承错误的信号掩码。6.3 当位图不够用实时信号传统信号“同类型只记一个bit”的特性在需要精确计数或传递事件时很让人头疼。Linux提供了实时信号编号34~64它们走的是队列机制同一个实时信号可以多个同时排队不会合并丢失而且可以用sigqueue()携带一个整数或指针值发给目标进程。实际应用中有个经典场景一个监控进程管理多个子任务当子任务完成一批IO时用实时信号通知监控进程处理结果。因为完成事件发生频率可能很高传统信号会丢事件实时信号则能保证每个事件都进入队列等待处理。配合SA_SIGINFO标志handler可以从siginfo_t里取出伴随数据拿到发送者传过来的业务上下文。不过实时信号也有自己的限制队列长度受资源限制太多pending信号会直接丢弃并返回错误。所以它适合“低频、重要、需要计数”的事件不适合当成高频消息总线用。真要高频传输业务数据老老实实走消息队列或者共享内存。6.4 排查信号问题的三板斧线上碰到信号相关的诡异问题我最常用的三个工具kill -l列出系统当前支持的所有信号编号和名称。不要靠背直接查能避免不少低级错误。strace -e tracesignal跟踪进程收到的信号和信号相关系统调用。比如你想知道进程被谁发了SIGTERM、handler里有没有调用sigaction或sigreturn一条命令就能看到完整时间线strace -f -e tracesignal -o /tmp/sig.log ./your_programgdb里设置signal调试调试时用handle SIGTERM stop让gdb在收到SIGTERM时停在现场而不是把进程杀掉然后查看堆栈、变量状态定位handler或主循环的具体问题。还有个小经验查“进程莫名其妙死了”的时候先别急着看业务代码先用grep Sig /proc/pid/status看进程的SigCgt已捕获信号掩码是不是符合预期。如果某个信号的SigCgt没有对应bit置位说明进程根本没注册相关handler信号一来就是默认行为直接退出不用怀疑别的。最后分享一点个人体会。我在实际项目里踩过的最深的坑不是不会用sigaction而是想当然地认为“handler里随便写写没关系”。信号处理真正困难的地方在于它打破了你对程序执行流的线性预期。一个信号可能在任意一条指令处插进来你没法用常规的思维去推断状态。所以我的习惯是能用sigwait同步处理就不用异步handler必须用异步handler时一律只置标志位所有实际工作全部放到主循环或者专职线程里做每一条被信号保护的关键路径都留一个strace跟踪的入口。按这个套路走信号相关的坑我不敢说全避开了但至少踩得明明白白。