从事Linux服务端开发这些年我见过太多同行在信号处理函数上栽跟头有的进程随机无响应有的日志写到一半卡死有的明明只是处理一个SIGINT程序却整个栈被压穿。这些问题的根源几乎都指向同一个点——很多人把信号处理函数当成一个能短暂插一脚的普通函数却没有真正理解它在内核视角下到底是什么。这篇博客我就从中断流程这四个字入手把信号处理函数从触发、进入、执行到返回的全过程拆开揉碎讲清楚也会把我实际排查过的三个典型故障完整复盘。如果你正在写守护进程、自研框架或者只想弄明白为什么处理函数里不能碰printf这篇文章应该能帮你省下不少弯路。1. 先搞清楚信号处理函数到底是怎么插队进来的1.1 信号从产生到被看到位图、挂起与屏蔽我们经常说进程收到一个信号但这个说法很容易让人误以为信号一到处理函数马上就跑。真实情况是信号到达之后最先生效的是进程内部的一组未决信号标记pending signal bitmap而不是处理函数本身。内核为每个线程维护一个pending位图和一个阻塞位图blocked mask。当信号产生时比如你执行kill(pid, SIGINT)内核做的事情仅仅是到目标线程的pending位图上把对应位点亮然后看这个信号是否在阻塞集合里。如果被阻塞了那就暂时搁置如果没被阻塞内核会设置一个TIF_SIGPENDING标志提醒该线程从内核返回用户态之前有个信号等着你处理。这里有个关键区别普通信号1~31号在未决状态是不排队的同一个信号连续来10次位图上仍然只有一个位。而实时信号32号以后会走独立的信号队列可以排队也能携带额外数据比如sigqueue传的 int 值。我见过有人用 SIGUSR1 统计某类事件数量结果漏了9次这就是位图合并导致的。若真想计数要么用实时信号要么用共享内存自己计数。1.2 真正的递送时机为什么它总在返回用户态那一刻发生了解了未决标记还不够真正容易让人困惑的问题是为什么信号处理函数执行的位置总是突然的有时程序明明在read()里阻塞信号一来 read 立刻返回EINTR有时程序明明在死循环里疯狂计算处理函数却像精确地插进了两条指令之间。答案在于内核的递送时机绝大多数信号不是在信号产生那一瞬间处理的而是在目标线程从内核态切回用户态的前夕被统一检查的。落在 x86-64 上就是系统调用返回到用户空间、或调度器切回该线程的那段路径上内核看到TIF_SIGPENDING后调用do_signal()把当前进程的 trap frame寄存器现场保存到一个精心准备的栈帧里然后修改指令指针RIP指向处理函数的入口。等 CPU 真正切回用户态程序看起来就像被打断了一样跳进了 handler。这就解答了一个经典的疑问为什么信号处理函数不会真正打断内核里的代码比如 syscall 内部正在把数据从内核缓冲区复制到用户缓冲区时你不用担心复制一半被信号拆散。它们要么在 syscall 返回后被打断要么在用户态任意两条指令之间被插入。这种异步插入模型和硬中断抢占执行流是完全不同的两种机制也是后面所有坑的源头。1.3 和硬中断的差别它并没有独立的中断栈不少刚接触嵌入式或驱动开发的同学会把信号处理函数和硬件中断处理程序类比但两者差别很大。硬件中断发生后CPU 会跳到中断门内核为了让当前执行流继续恢复会专门准备中断栈而信号处理函数运行时CPU 完全处于用户态它使用的是当前被中断线程的用户栈。换句话说信号处理函数并没有自己专属的栈空间除非你显式使用sigaltstackSA_ONSTACK。它就像一个不速之客直接搬进了主人家的客厅靠的是主程序栈上肯定还有空余空间这个假设。这个细节我在后面讲栈溢出的坑时会再展开这里先记住一点信号处理函数不是被调度器调度出来的线程它是插进你主调用栈里的一段临时上下文。2. x86-64 上进入处理函数前内核悄悄做了多少事2.1 sigframe把现场整个搬到用户栈我们常说信号处理函数是异步打断主流程那么这个打断具体体现在哪里呢从进程的用户态视角看你只看到了一个跳转。但从内核的视角看在跳转之前它就动手布置了一整个现场帧sigframe。以 x86-64 为例内核在准备递送一个带用户处理函数的信号时会调用setup_rt_frame它会把当时保存在 pt_regs 里的用户寄存器上下文连同信号编号、siginfo、旧的信号屏蔽字一起写入当前用户栈顶部。这个被写进去的区域在 glibc/内核代码里被称为rt_sigframe其中包含ucontext_t等结构。随后内核重新计算栈指针把 RIP 修改为 handler 的地址再往栈里压入一个特殊的返回地址——restorer。这里有个非常容易忽略的重点在进入处理函数的那一刻你当前指令位置、栈指针、寄存器现场并不是鲁棒地保存在内核里的。它们已经离开了内核查不到的、只属于用户态的寄存器被固化到了用户栈的sigframe里。内核只保留了一个极薄的层层状态剩下的全靠这个栈帧来续命。2.2 入口与 restorer谁收拾返回的残局上一节说的返回地址restorer很多教材没讲透但它恰恰是理解信号处理函数如何结束的钥匙。普通函数调用返回靠的是ret指令从栈里弹出一个调用者的地址。而信号处理函数结束的路径其实并不是直接回到主程序的断点——因为内核在改写寄存器时并没有像普通函数调用那样在栈里保存原调用者的返回地址。正确的机制是内核在布置 sigframe 时会把 handler 的返回地址设置成一个特殊函数这个函数通常叫__kernel_rt_sigreturn在 x86-64 上由 vdso 或由 glibc 通过 SA_RESTORER 指定。当 handler 执行到ret时CPU 跳转到这个 restorerrestorer 再发起一个rt_sigreturn系统调用把控制权交还给内核由内核根据 sigframe 里的内容恢复整个现场再切回原指令继续跑。如果你绕过 glibc用裸syscall注册 handler 而不提供 restorer大概率的结局是 handler 返回后跳进一个未知地址直接崩溃。这是很多自实现 runtime 的人踩过的大坑依赖 glibc 时sigaction封装会默默帮你搞定 restorer一旦脱离 glibc你就得自己准备一段汇编。2.3 屏蔽字与 SA_NODEFER防止自己打断自己当你注册处理函数时如果看过sigaction结构体一定注意到了sa_mask字段。它的作用是在进入处理函数之前内核会把这些信号追加到当前线程的阻塞集合里处理函数返回时再恢复。更微妙的是当前正在被处理的信号默认也会被自动阻塞——这就是为什么你在 handler 里再次触发同一个信号时通常不会立刻形成无限递归。如果你明确不希望如此可以设置SA_NODEFER标志这时同一个信号可以在 handler 里再次打断 handler。我很少建议别人这么做除非你对自己的处理函数有绝对的可重入性把控。大多数稳定架构的做法恰恰相反在 handler 里只做极小的事自动屏蔽反而是一道安全保险让处理动作不会被打断重入。顺带一提整个信号屏蔽字的状态也是保存在 sigframe 里的也就是说进入处理函数前你手工设置的sigprocmask结果以及进入后临时追加的自动阻塞都被固化在那个栈帧里等rt_sigreturn时统一恢复。理解这一点对调试为什么处理函数退出后程序信号屏蔽状态和我预期不一样很有帮助。3. 返回路径rt_sigreturn 如何把现场还原回去3.1 一个特殊的系统调用而不是普通 return前面提到了 restorer 会调用rt_sigreturn那这个系统调用到底做了什么如果说 setup_rt_frame 是把现场写进用户栈那么rt_sigreturn就是一个反向操作内核从当前用户栈上找到那个 sigframe把里面保存的寄存器上下文、信号屏蔽字、栈指针全部取出来恢复到当前线程的 pt_regs 里然后返回到用户态。这里有一个很重要的技术事实rt_sigreturn不仅恢复普通的通用寄存器还会恢复比如eflags、fs/gs基址等状态。由于恢复后线程的栈指针也跟着变了rt_sigreturn系统调用的返回地址并不可信所以内核在处理完恢复后直接走那条恢复现场然后返回用户态的路径指令流就落在原断点处继续执行。从用户程序的角度看read()可能刚刚返回一个-1/EINTR或者某条普通指令刚算完一次加法一切毫无察觉。值得强调的是正因为返回路径依赖于栈里的 sigframe所以 handler 内部如果破坏性地操作栈、或者主动改变栈指针会导致恢复时找不到有效的 sigframe结果往往是不可预期的崩溃或诡异的行为。凡是搞过协程/用户态切换库的人应该立刻意识到如果你想做用户态上下文切换绝对不能在一个信号处理函数活动期间的旧栈帧上做手脚否则整个rt_sigreturn通路会彻底错乱。3.2 现场恢复的粒度寄存器、eflags、屏蔽字有同事问过我这样一句话信号处理函数执行完了程序是从断点回来还是从下一条指令回来答案很干脆严格回到被中断的指令那里。因为信号的递送时机是返回用户态之前而内核保存的 RIP/RSP 就是即将被执行的那条用户态指令的位置。被中断的指令其实并没有执行恢复后它会重新从那一行开始像是根本没被打断过。当然根本没被打断只是用户态的假象几个副作用还是存在某些系统调用可能返回EINTR后面细说这是最显眼的证据。如果 handler 修改了 errno而主程序又没能恢复会看到一个凭空出现的错误码导致后续调用判断错乱。如果 handler 修改了全局变量、关闭了 fd、改变了信号屏蔽字这些都是长期副作用并不会因为返回而被自动撤销。3.3 对比普通函数调用中断式调用为什么留下这些后遗症把信号处理函数和普通函数调用放在一起看后遗症就显而易见了。普通函数调用时调用者和被调者之间有明确的约定栈帧按规范管理参数是主动传进去的调用前你清楚自己调了谁、什么时候结束、会修改哪些状态。而中断式调用是半路强行插入的主程序正在干任何事数据结构的修改可能处于中间状态某些库的内部锁可能正被抓在自己手里。所以处理函数里能调用哪些函数的唯一标准不是它看着简单不安全而是它是否具备异步信号安全async-signal-safe。标准里给出的安全函数白名单很窄基本都是对 fd 的直接write、read、_exit、kill、sigaction这类不依赖进程级共享状态的函数。诸如printf、malloc、pthread_mutex_lock、gettimeofday某些平台上都在危险名单里。这个约束我在第四节用一个真实死锁案例说明那是我印象最深的一次排查。4. 三个最容易踩的坑以及一次完整的死锁排查4.1 errno 被偷改看起来没错的代码只会欺骗你先看一个我帮人查过多次的诡异 bug。某程序在主流程里做文件写入while ((w write(fd, buf, count)) 0 errno EINTR) { // 重试 }逻辑看起来没问题但它偶尔会返回错误“write failed: Interrupted system call而且是发生在根本没有外部信号的时候。后来查来查去问题在一个 SIGALRM handler 上。handler 内部做了类似库调用顺手把 errno 写成了EINTR。主程序的 write 调用本身成功了可下次判断时读到的 errno 并不是本次 write 设置的而是 handler 里残留的错误码。这里要很清楚地解释 errno 的本质errno 本质上是线程局部存储中的一个 int它不是一个错误返回值而是一个上次某个库函数设置的错误状态。信号处理函数在执行时复用的就是当前线程的 errno。所以一个异步信号安全的 handler 的第一规范是进门先保存 errno出门前恢复 errno除非 handler 确实要主动传递错误信息。下面的模板至少保证了大部分场景下不污染主流程static void safe_handler(int sig) { int saved_errno errno; // 只做异步安全操作 errno saved_errno; }4.2 可重入性灾难某后台服务死锁的完整排查链路下面这个案例来自我给一个朋友的中间件项目做的远程排查过程相当典型。现象服务每运行一段时间某个 worker 进程就彻底无响应CPU 也不高网络连接也不收不发。刚开始以为是偶发死循环但长时间运行后必然复现。排查步骤大致如下用gdb -p pidattach 上去thread apply all bt看所有线程栈。结果发现主业务线程停在一次普通的日志打印调用里函数栈底是__lll_lock_wait。再看另一条看起来不太起眼的栈帧居然是 SIGTERM 的信号处理函数它也在__lll_lock_wait里等同一把锁。于是锁的归属立刻明确了主业务线程调用日志库写日志先拿到锁写到一半时进程收到 SIGTERM内核异步插入 handler而 handler 内部也尝试调用同样的日志接口或某个被同一把锁保护的重入不安全的函数于是它试图获取同一把锁——但锁的持有者正是它自己打断的那个线程永远不可能释放死锁就这么形成了。这里的细节值得多强调一句很多人觉得死锁只发生在多线程之间但实际上同一个线程也能被自己打断并死锁。信号处理函数不是另一个线程它是在同一个线程的栈上下文里运行的。如果它去抢一把当前线程已经持有的非递归锁就必然自锁到底。要避免这个问题只有两条路要么 handler 里绝不碰任何加锁操作要么用sigwait/signalfd把信号转给专用线程处理从机制上绕开异步插入执行。4.3 栈深度失控处理函数里的递归如何压穿线程栈第三个坑来自一次栈溢出崩溃。项目里有人写了一个很聪明的 handler收到 SIGURG 时在 handler 内部解析数据并间接调用了某个可能再次触达信号的逻辑。由于同一信号默认自动阻塞本不该递归打断但他们用了SA_NODEFER来追求实时响应结果某次峰值流量下信号密集到达handler 在 handler 里嵌套 handler一层层在同一个用户栈上叠加。最终进程直接段错误。查 log 里留下的栈回溯时能看到一长串重复的 handler 帧每一层都叠加了几百字节的栈空间直到把靠近栈顶的另一个映射踩碎。更隐蔽的是业务线程的栈如果本身已经很深比如递归解析日志或者深层调用链那么常规的 handler 即使不递归也可能把栈压穿。内核写 sigframe 时并不检查剩余栈空间够不够它只是在当前 RSP 上往下写写爆了就直接触发缺页异常。对这种场景标准解法是sigaltstack为处理函数准备一块独立的备用栈再配合SA_ONSTACK标志注册 handler。这样即使主调用栈已经很深handler 也跑在预设的备用栈上不至于炸穿。备用栈通常分配 64KB 或更大并根据 handler 实际需要的栈深去调优。坑典型症状根因规避手段errno 被污染明明成功却报错handler 内改变了线程局部 errno进入/退出时保存恢复 errno自锁死锁进程卡死打断主流程后又抢同一把锁handler 不加锁信号转线程处理栈溢出段错误递归 handler 或将 sigframe 叠进深栈SA_ONSTACK sigaltstack5. 和软中断和平共处的工程手段5.1 安全处理函数只做三件事标记、唤醒、异步安全调用理解了前面的机制一个清晰的结论就浮出来了绝大多数场景下在 handler 里做复杂业务逻辑是错的。我给出的硬性建议是信号处理函数里只做三件事——置位全局标志、唤醒被阻塞的主循环比如往管道里写一个字节、调用_exit处理致命错误。如果你需要在收到信号后做清理、落盘、发心跳、打日志那就把真正的逻辑全部留在主流程中处理。收到信号后handler 只负责“通知”主循环在一个可控的、非异步的位置去执行善后逻辑。这样做还有额外的好处主循环可以按自己的节拍处理多个信号避免信号风暴把进程拖垮。网上有个经典的说服性比喻信号处理函数就像有人在你的代码中间突然插播广告你不能在广告里开始整理房间。广告时间只够你记下该整理房间了。5.2 self-pipe 真实现一字节把异步信号变成 IO 事件self-pipe 是最古老也最稳的一招很适合没有 epoll 基础的老系统。原理一句话初始化时创建一对pipe把写端 fd 保存到全局变量信号处理函数里只用write(fds[1], c, 1)写入一个字节主程序则用poll/select监视读端 fd一旦可读就去读取并且知道某个信号发生了。static int g_pipe_write_fd -1; static void handler(int sig) { char c (char)sig; /* 也可以直接写成 x */ int saved_errno errno; write(g_pipe_write_fd, c, 1); /* 异步信号安全 */ errno saved_errno; } int main(void) { int fds[2]; if (pipe(fds) ! 0) return 1; g_pipe_write_fd fds[1]; struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler handler; sigaction(SIGINT, sa, NULL); sigaction(SIGTERM, sa, NULL); struct pollfd pfd { fds[0], POLLIN, 0 }; while (1) { if (poll(pfd, 1, -1) 0) { if (errno EINTR) continue; break; } char c; if (read(fds[0], c, 1) 0) { /* 主循环里做真正的处理 */ printf(got signal %d\n, (int)c); fflush(stdout); } } }注意这里有几个细节handler 里只用write不用printf异常情况下即使写端缓冲区满了也不阻塞可配合O_NONBLOCK读端最好也置为非阻塞防止poll返回后read时信号再次打断导致读不到数据。如果你担心不同信号信息丢失可以把信号编号当作那个字节内容写入一个字节足够表示常见信号了。多个信号并发时管道缓冲区能自然排队这也是我更喜欢 self-pipe 而不是只置一个标志位的原因——仅置标志位的话SIGINT 和 SIGTERM 一起到时你可能根本不知道哪个信号来过。自 Linux 2.6.27 起evensocketpair/eventfd也可以承担类似的角色eventfd 还能直接计数语义更简单。5.3 signalfd 与 epoll把信号推进事件循环现代 Linux 程序我更推荐直接用signalfd。它的思路不是注册 handler而是先把目标信号用sigprocmask阻塞掉然后打开一个 fd当有信号到达时这个 fd 变得可读。你只需要把 fd 丢进epoll或poll的事件循环信号就被彻底地事件化了。sigset_t mask; sigemptyset(mask); sigaddset(mask, SIGINT); sigaddset(mask, SIGTERM); sigprocmask(SIG_BLOCK, mask, NULL); /* 很重要先阻塞 */ int sfd signalfd(-1, mask, SFD_NONBLOCK); /* 把 sfd 加入 epoll监听 EPOLLIN */顺带一提使用 signalfd 时的一个前提因为信号已经被阻塞所以不会走传统的 handler 递送路径也就没有异步插入的问题。信号处理逻辑从异步打断变成了事件循环中的一次普通读取这几乎是根治前面所有坑的最优雅方式。唯一的注意点是阻塞信号之后如果程序调用了read()这样的慢系统调用通常情况下不会因为信号而返回 EINTR 了所以某些依赖 EINTR 触发重试的代码逻辑也需要重新审视。5.4 SA_RESTART 到底可不可靠慢系统调用的边界既然提到了 EINTR最后把SA_RESTART说一说。很多人在注册 handler 时习惯无脑加上SA_RESTART以为这样所有系统调用都会被自动恢复不用管 EINTR 了。实际上Linux 对SA_RESTART的支持有清晰的边界对于像read、write这类可能被信号中断的慢系统调用如果数据尚未到达/缓冲区未准备就绪SA_RESTART 会让内核在信号处理完成后自动重启该系统调用但如果已经传输了一部分数据read/write仍然返回已传输的字节数不会重启。更麻烦的是poll、epoll_wait、nanosleep等在 Linux 上并不是所有都受 SA_RESTART 影响不同内核版本表现还有过变化。与其猜测某个调用是否会被 SA_RESTART 覆盖不如把手动处理 EINTR 当作释放信号后的标配。我的习惯是该设的 SA_RESTART 仍设上同时任何涉及慢系统调用的代码都写被 EINTR 就重试的循环。两条腿走路才不会在某个冷门系统调用上被咬一口。处理这个问题没有银弹但把信号处理函数从业务执行者降级为事件通知者、把逻辑量降到最低几乎能规避九成以上的麻烦。我在实际项目里的最后一道底线永远是那条只包含write、_exit或标志位赋值的最小 handler。