写这篇文章之前我想先聊聊我自己的体会。早期做Linux开发时有段时间我特别怕处理信号相关的问题尤其是那种“明明kill了进程却没有任何反应”的情况。后来把信号的pending未决/保存机制彻底弄明白之后很多诡异的现象突然就说得通了。信号保存这个概念说难并不难本质就是内核里一张位图但这张位图牵扯出的行为却影响着后台服务、嵌入式程序甚至每一次你按下的CtrlC。这篇文章我会用最直白的方式从信号保存的原理讲起配合可直接运行的代码和调试技巧把“信号保存简单使用”这件事讲透。无论你是刚接触Linux编程的学生还是准备面试的开发者又或是被奇怪信号问题折磨的运维和嵌入式工程师看完应该都会有收获。1. 为什么要把“信号保存”单独拿出来讲在Linux下排查问题时你有没有遇到过这种场景一个进程明明收到了kill命令进程却毫无反应日志里也什么都没留下仿佛信号被“吞”掉了。反过来有时候只是发了一次信号程序却崩溃了完全超出预期。这些现象背后大都指向同一个概念信号从产生到真正被进程处理之间存在一个“保存”的中间阶段专业术语叫pending也就是未决状态。信号机制是Linux/Unix体系中最基础也最容易让人困惑的进程间通信方式。绝大多数人对信号的理解止步于“CtrlC能终止程序”“kill -9能强杀进程”但这只是信号默认行为的最浅层。真正决定一个信号行为走向的是内核如何记录它、保存它、以及何时把它递送给进程。当信号因为某些原因没能立刻被处理最常见的原因是被阻塞它就会被内核暂存起来等待合适的时机再递送。这个暂存的动作就是标题里说的“信号保存”。为什么要单独关注这个点因为在实际开发里大量bug都出在这个层面。比如你在程序启动时用sigprocmask屏蔽了SIGINT结果一段时间后需要恢复却发现CtrlC不生效了又比如你在信号处理函数里执行了非异步安全的操作导致程序卡死。这些问题如果不理解信号保存的原理排查起来只能靠猜。理解了原理之后所有现象都能用一句话解释信号没被处理是因为它被保存在了pending集合里还没有进入递送环节。这篇文章主要围绕三个系统调用展开sigprocmask修改阻塞集合、sigpending查看未决集合、sigaction注册信号处理函数。这三者组合起来就是一套对信号生命周期进行“控制-查看-消费”的完整工具箱。配套的代码我都实际编译运行过不依赖任何第三方库你可以直接复制到自己的Linux环境里验证。2. 信号从哪来、到哪去一张位图说清保存原理想弄明白信号保存先要建立一个小模型。每个进程内部都维护着两张核心位图blocked集合和pending集合。blocked集合表示哪些信号被当前进程屏蔽阻塞pending集合表示哪些信号已经产生、但尚未被处理。在Linux的通用平台上信号编号从1到64其中1到31是标准信号SIGRTMIN到SIGRTMAX之间是实时信号。每个信号在这两张位图里只占一个bit这个设计直接决定了标准信号的一个经典特性不排队。信号的生命周期可以拆成三步产生、挂起、递送。产生信号的方式很多键盘输入CtrlC产生SIGINT调用kill或者killpg向目标进程发送信号进程自己调用raise向自身发信号硬件异常会带来SIGILL、SIGSEGV内核还会为特定事件生成信号比如SIGCHLD子进程退出、SIGALRM定时器到期。信号产生后内核不会立刻安排进程执行对应的处理逻辑而是先检查目标信号在blocked集合里是否被屏蔽。如果没被屏蔽信号直接进入递送阶段如果被屏蔽了内核就把对应的bit在pending集合里置位表示“这个信号已经被保存等待以后处理”。等到进程取消阻塞内核发现pending里有这个信号才会真正递送触发你注册的处理函数或者执行默认动作。这里有一个必须区分的细节pending也分两类。一类是进程级pending一类是线程级pending。在很多现代Linux系统使用NPTL线程库的情况下每个线程都有自己独立的blocked和pending集合。没有进行特殊设置时信号默认由主线程接收和处理。面试里经常追问的点就在这如果一个信号同时被进程和线程阻塞线程级的pending优先级更高会先于进程级pending被处理。新手不需要把全部细节背下来但要记住一个核心结论决定信号能不能递送看的是当前线程的blocked集合记录有没有迟到的信号看的是pending集合。用生活里的事来类比更容易理解。想象你正在开会手机上收到一条紧急消息如果开了免打扰这条消息不会立刻响铃而是出现在通知栏里这相当于信号被保存到了pending免打扰就是阻塞集合等会议结束你关掉免打扰看到通知再决定要不要回复这个动作就是信号递送。而且通知栏里相同来源的推送只占一条位置一下来十条也一样显示一条处理和一次显示同等效果。这就是标准信号不排队的直观解释。还有两个信号非常特殊SIGKILL和SIGSTOP。它们不能被阻塞、不能被捕获也不允许被忽略。内核把它们当作最后的手段用于强制终止进程和暂停进程。无论你怎么构造blocked集合sigprocmask都会悄悄忽略对这两个信号的设置。所以不要试图通过屏蔽信号来阻止kill -9规划和面试时都要记住这个边界。3. 信号保存三件套sigprocmask、sigpending、sigaction理论模型建立之后就要落地到接口。围绕信号保存和简单使用最核心的三个系统调用是sigprocmask负责修改blocked集合sigpending负责读取pending集合sigaction负责注册或修改信号处理函数。把这三个接口配合起来就能覆盖“屏蔽信号→查看信号是否被保存→取消屏蔽→信号递送处理”的完整链路。3.1 sigprocmask修改阻塞信号集sigprocmask的原型是这样的int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);how有三个取值这是最容易搞混的地方SIG_BLOCK把set集合中的信号加入当前阻塞集合已有的阻塞项保留。适合“追加屏蔽”的场景。SIG_UNBLOCK把set集合中的信号从阻塞集合里移除。适合“解除屏蔽”的场景。SIG_SETMASK直接用set集合替换当前阻塞集合不管之前阻塞了什么。oldset参数用于保存修改前的阻塞集合方便之后恢复现场。比如你先用SIG_SETMASK读取当前集合完成修改最后再用SIG_SETMASK把oldset还原回去这是一种很常见的临时屏蔽信号手法。需要额外提醒的是Post和POSIX标准都明确了一点在多线程程序里sigprocmask的行为是未定义的。别看单线程下一切正常一旦引入pthread就一定要改用pthread_sigmask这个函数参数和sigprocmask完全一致只是针对线程的独立阻塞集合操作。我见过不少线上问题就是单线程代码里用了sigprocmask后面加了多线程改造结果信号处理全部乱套。3.2 信号集操作先清空再添加sigprocmask的set参数类型是sigset_t使用前必须先初始化用sigemptyset把集合清空或者用sigfillset把集合全部置位然后用sigaddset往集合里添加指定信号用sigdelset从集合里移除指定信号用sigismember查询某个信号是否在集合中。这是新手最容易踩的坑声明一个sigset_t变量后不初始化就直接传给sigprocmask里面是随机值导致意外阻塞了一堆信号。记住一个顺序先初始化和清空再逐信号操作。sigset_t set; sigemptyset(set); sigaddset(set, SIGINT); sigprocmask(SIG_BLOCK, set, NULL);这三行就是“屏蔽SIGINT”的标准写法。3.3 sigpending查看未决信号sigpending的原型也很简单int sigpending(sigset_t *set);内核把当前线程对应的pending集合拷贝到set参数里程序随后可以用sigismember逐个检查哪些信号处于未决状态。这里要特别注意sigpending只是“查看”不会清除pending状态。如果想主动丢弃某个已保存的信号需要另外的思路比如把该信号的处理方式设置为SIG_IGN然后让它在阻塞期间产生等恢复阻塞时内核发现该信号被忽略会直接放弃递送。这个技巧在处理一些周期性但无意义的信号时能派上大用场。3.4 sigaction注册可靠的处理函数注册信号处理函数建议直接用sigaction而不是signal。原因在于sigaction的行为是可预测的而signal在不同glibc版本、不同编译选项下的语义并不统一。sigaction的原型是int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);struct sigaction里面值得关注的字段有三个。sa_handler是普通处理函数指针赋值为SIG_IGN表示忽略信号SIG_DFL表示恢复默认行为sa_mask指定执行处理函数期间要额外屏蔽的信号集合sa_flags支持SA_RESTART等重要标志设置后如果进程正在阻塞的系统调用如read、accept被信号打断内核会自动重启该系统调用而不是返回错误。如果面试官问signal和sigaction的区别抓住两个核心点就行sigaction可以明确控制处理期间的屏蔽信号集合支持附加参数行为稳定可控。4. 实操亲手把信号“封存”再“释放”纸上谈兵做到这一步该动手了。下面用一个完整的C程序演示信号保存的全过程。程序逻辑分四步注册SIGINT的处理函数用sigprocmask屏蔽SIGINT循环多次向自己发送SIGINT并用sigpending观察信号是否被保存最后取消屏蔽观察处理函数只在恢复后执行一次。#include stdio.h #include signal.h #include unistd.h #include stdlib.h #include string.h static void handle_sigint(int sig) { char msg[] \n[handler] caught SIGINT\n; write(STDOUT_FILENO, msg, sizeof(msg) - 1); } static void show_pending(void) { sigset_t pending; sigemptyset(pending); sigpending(pending); if (sigismember(pending, SIGINT)) { printf([info] SIGINT is pending (saved but not delivered)\n); } else { printf([info] no SIGINT pending\n); } } int main(void) { struct sigaction sa; sigset_t block_set; memset(sa, 0, sizeof(sa)); sa.sa_handler handle_sigint; sigemptyset(sa.sa_mask); sa.sa_flags 0; if (sigaction(SIGINT, sa, NULL) 0) { perror(sigaction); exit(1); } sigemptyset(block_set); sigaddset(block_set, SIGINT); if (sigprocmask(SIG_BLOCK, block_set, NULL) 0) { perror(sigprocmask); exit(1); } printf([demo] SIGINT blocked. Sending 3 SIGINT signals...\n); for (int i 0; i 3; i) { kill(getpid(), SIGINT); show_pending(); sleep(1); } printf([demo] unblocking SIGINT now...\n); if (sigprocmask(SIG_UNBLOCK, block_set, NULL) 0) { perror(sigprocmask unblock); exit(1); } printf([demo] after unblock, handler should have run.\n); sleep(1); return 0; }编译和运行gcc -Wall -o signal_demo signal_demo.c ./signal_demo真实输出如下[demo] SIGINT blocked. Sending 3 SIGINT signals... [info] SIGINT is pending (saved but not delivered) [info] SIGINT is pending (saved but not delivered) [info] SIGINT is pending (saved but not delivered) [demo] unblocking SIGINT now... [handler] caught SIGINT [demo] after unblock, handler should have run.看到没有连续发送3次SIGINT每次sigpending都显示信号被保存但处理函数没有执行。取消阻塞后handle_sigint只运行了一次。这就是标准信号不排队的实证同样的信号在pending阶段只保存一份同时到达的多个实例会被合并。如果你把这套代码的SIGINT换成SIGRTMIN1并注册带siginfo_t参数的信号处理函数就能看到相反的效果每个实时信号都会被独立保存、独立处理这也是大并发场景下信号偶尔也需要“上了保险丝”的原因。4.1 实时信号与标准信号的本质差异标准信号1到31的pending集合只是一张位图每个信号一个bit所以多次发送同一标准信号pending集合里只有一次记录。实时信号SIGRTMIN到SIGRTMAX就不同了Linux内核为它们维护了一个真正的队列每次发送都会在pending队列里增加一个实例排队递送。用代码验证只需要两步把示例中的SIGINT改成SIGRTMIN1然后在struct sigaction里用sa_sigaction字段注册函数并设置sa_flags | SA_SIGINFO。处理函数原型变成void rt_handler(int sig, siginfo_t *info, void *context);这种差异意味着什么如果你关心信号的“次数”而不是仅关心“有没有信号”就必须选择实时信号或者使用管道、消息队列等机制承载信息。很多程序只屏蔽SIGINT一次两次没感觉但一旦遇到高频信号标准信号丢事件的问题就会暴露理解这个差异能帮你少走不少弯路。4.2 信号处理函数里该做什么、不该做什么示例里我特意用了write而不是printf来打印信息这不是随手之举。在信号处理函数中调用printf、malloc、fopen这类非异步信号安全的函数是生产环境中很常见也是很隐蔽的隐患。原因很简单信号随时可能中断主流程主流程如果刚好在执行printf内部已经拿到了相关锁信号处理函数再次调用printf就会尝试拿同一把锁造成死锁。信号处理函数可能中断malloc的内部状态导致堆损坏。正确的做法是把信号处理函数当作一个“事件记录指针”在里面用write系统调用写入少量字节或者把处理逻辑所需的变量标记为volatile sig_atomic_t仅仅置一个标志位真正的业务逻辑放在主循环里检查标志后执行。这样虽然多了一次循环轮询的开销但把不确定性严格限制在最小范围内程序行为可预测得多。还有一个常见误区是递归触发。如果处理函数执行期间又收到同一个信号根据系统默认行为该信号会被临时阻塞直到处理函数返回。这本身是一次保护但如果你在sa_mask里又添加了别的信号处理期间这些信号都会被屏蔽。需要精确控制时务必用sigaction的sa_mask字段显式声明而不是随便用signal函数加个handler完事。5. 常见问题与排查技巧实录信号保存机制在实战中踩坑极多。这里把我的排查经验整理成一张速查表方便你在项目里对照使用。现象可能原因排查建议阻塞后发多个相同信号取消阻塞只处理一次标准信号不排队pending集合是位图需要计数语义就用实时信号或改用消息队列/管道sigpending始终为空但程序确实收到了信号信号根本没被阻塞已经直接递送检查sigprocmask的返回值确认how参数和集合内容程序不响应CtrlCSIGINT被忽略或屏蔽检查是否把SIGINT设置成了SIG_IGN检查阻塞集合屏蔽信号后进程仍然崩溃导致崩溃的不是你以为的SIGSEGV可能是SIGABRT用core dump或gdb catch定位具体信号恢复阻塞后没有立即看到处理效果pending信号在处理函数执行期间被同信号再次屏蔽检查sa_mask是否包含当前信号必要时调整5.1 不看代码也能查信号状态运行中的进程可以通过/proc文件系统直接查看信号相关的集合信息。进入/proc目录下的进程目录在status文件里有三个关键字段SigBlk当前阻塞集合SigPnd当前进程未决集合SigCgt已捕获的信号集合查询方式grep -E Sig(Blk|Pnd|Cgt) /proc/1234/status输出是一串十六进制数每一位对应一个信号编号bit0对应信号1依次类推。把十六进制转成二进制就能精确知道某个信号当前处于什么状态。这条命令在生产环境极为好用不改动代码、不打断服务就能回答“我的信号到底存没保存”这类问题。5.2 用gdb直观观察信号递送时机如果觉得十六进制麻烦还可以用gdb来验证信号的处理时机。在gdb里执行handle SIGINT print然后运行程序从另一个终端向该进程发送SIGINT。gdb会在信号递送的那一瞬间中断程序此时用bt查看调用栈如果栈顶还在主循环说明信号尚未递送如果栈顶已经进入handle_sigint说明正在处理。反复用SIG_BLOCK和SIG_UNBLOCK切换你就能亲眼看到信号从保存到递送的完整轨迹。这个方法比口头解释直观得多适合用来教学或者清晰定位问题。5.3 给开发者的几条忠告处理信号相关问题多年实践下来我总结出几条铁律。第一信号处理函数里少做事能write就write能置标志就置标志绝不碰堆操作和锁。第二阻塞和忽略是两回事阻塞意味着延迟处理信号还保存着随时可能递送忽略意味着永不处理信号来了直接丢弃两者的调试方式完全不同。第三多线程程序里不要直接用sigprocmask管理全局信号要用pthread_sigmask配合sigwait做集中处理。第四警惕SIGPIPE和SIGALRM的默认动作SIGPIPE默认终止进程很多网络服务没处理它导致写已关闭连接的socket时进程静默退出SIGALRM默认也是终止进程如果代码里无意间使用了alarm进程就可能定时暴毙日志里什么都查不到。这几条每一条都是生产环境里的真实教训。6. 面试与日常使用中的心得先解决一个很多人没想透的问题信号保存和信号处理函数的注册之间是什么关系信号保存是内核态的状态记录只要信号产生且被阻塞无论你有没有为它注册处理函数它都会进入pending集合。信号处理是用户态的动作发生在递送阶段。即使你从头到尾没调用sigactionSIGINT也有默认行为照样会先经历pending过程只不过递送时执行的是默认动作终止进程。理解了先后关系面试题“SIGINT被阻塞时按CtrlC进程会怎样”就不难回答了进程不会退出信号被保存取消阻塞后信号进入递送阶段这时才触发默认动作或处理函数。面试官如果问到“信号被保存的位置”你需要能给出清晰的回答在内核的进程控制块task_struct中维护了pending链表和blocked信号集用户态无法直接访问只能通过sigpending和sigprocmask这类系统调用间接访问。如果追问线程场景可以补充说每个线程也有自己的pending集合NPTL实现中线程级pending的优先级更高。能把这些讲清楚信号相关的问题基本能拿住大部分分数。6.1 实际项目中的信号应用场景信号保存机制绝不是面试题里的摆设。守护进程启动时通常先屏蔽掉SIGINT、SIGTERM等信号完成配置文件加载和资源预分配后再解除屏蔽避免中途被打断导致状态不一致。嵌入式Linux项目里父进程可以把SIGCHLD延迟到统一时机处理减少频繁上下文切换的开销。高并发网络服务里普遍会屏蔽或忽略SIGPIPE否则客户端断开连接后的一次写操作就足以让整个服务进程退出。我自己就踩过SIGPIPE的坑。某次线上服务不定期消失日志无异常重启后能跑一阵之后又消失。排查到最后用/proc/status里的SigCgt字段对比发现SIGPIPE没有被捕获。原来路由节点主动断开连接时服务端写socket触发了SIGPIPE的默认终止动作。从那以后我写服务端程序的第一件事就是列一张项目里可能出现的信号清单逐个确认处理策略忽略的、捕获的、保留默认的。这个习惯帮我避免了很多半夜被叫醒的烦恼。关于信号还有一个很值得继续探索的方向signalfd。等你理解了本文讲的保存机制再去看signalfd会突然豁然开朗它本质上就是把内核的pending集合转换成了文件描述符上的可读事件让你可以用读文件的方式消费信号并且能无缝整合进epoll事件循环。能走到这一步说明你对信号的理解已经不只是停留在调用API而是真正看到了机制背后的设计思路。这也是我觉得Linux信号最迷人的部分几千行代码的背后是一个把异步处理抽象成“保存-递送-消费”的简洁模型值得我们反复琢磨。
