1. 先从一次诡异的进程消失说起信号到底是什么早些年做服务端运维的时候遇到过一件让我印象很深的事。某个监控采集进程每天凌晨固定时间消失日志里干干净净没有任何异常报错systemd 的状态栏只留下一句Main process exited with code139。当时的第一反应是查崩溃日志结果什么都没找到。后来同事提醒我看一眼退出码139 换算成二进制展开其实就是 128 加 11——进程是被编号为 11 的信号干掉的。那个信号叫 SIGSEGV段错误。这件事之后我才意识到很多开发者对信号的理解停留在kill -9 杀进程这个层面真到了排查问题的时候面对退出码、信号编号、核心转储这些概念脑子里是乱的。信号不是一句软件中断就能概括的东西它是 Linux 进程管理里最基础、也最容易被误解的机制之一。无论是守护进程崩溃排查、网络服务断连处理、多线程协作还是日常的进程控制信号都绕不开。这篇内容我打算把信号讲透它从产生到送达进程中间经历了哪些内核数据结构为什么有的信号会丢失阻塞和未决到底怎么运作多线程环境下信号会被谁接收以及我最想分享的——几次真实排查中积累的实战经验。适合对进程模型有一定了解、但还没系统梳理过信号链路的开发者也适合正在被诡异程序行为折磨的运维和后台开发。2. 信号的数学本质一套挂在进程头上的事件通知协议2.1 信号不是软件中断而是一套有编号的内核事件协议教科书上常说信号是软件中断这个类比上学的时候帮了忙工作之后反而会误导人。硬件中断有专门的中断控制器、优先级、中断向量表每次触发都会打断 CPU 的指令流信号虽然也能打断进程的执行流程但它是内核用来通知进程发生了某件事的一种事件协议而且通知的通道非常窄——就是一个整数编号加一点可选的数据。Linux 里信号有标准信号和实时信号之分。标准信号编号范围是 1 到 31实时信号是 32 到 64宏定义上分别对应SIGRTMIN和SIGRTMAX。标准信号每种在进程内只维护一个标志位也就是说同一类标准信号短时间内来了 100 次内核也只会在未决集合里置一次位进程最终只会收到一次处理机会。实时信号则不同它支持排队来几次就排几次队不会丢。这个差异在后面的未决信号部分会展开讲但先说结论标准信号适合传发生了某事这个事实不适合传发生了多少次。2.2 为什么需要信号这种机制进程之间协作的方式有很多种管道、套接字、共享内存、消息队列这些都是传数据的。但有些场景需要的不是传数据而是提个醒你的子进程退出了、你往一个没人读的管道写数据了、你闹钟到了。这类异步事件如果都要靠进程去主动轮询既浪费 CPU 又响应不及时。信号的设计目标就是让内核或者其他进程能够主动通知目标进程有情况目标进程可以选择忽略、执行默认动作或者调用自己注册的处理函数。打个比方管道和 Socket 像是两个人互相传纸条信号则像是有人拍了一下你的肩膀说快看那边。拍肩膀的动作不需要传递一大段文字也不打断你正在翻阅的文档内容只是让你知道有事情需要处理。信号处理函数在进程自己的地址空间里运行能访问进程的全局变量这一点和中断处理程序有本质区别——中断处理程序运行时的上下文约束极多而信号处理函数除了异步安全性约束外基本可以当作普通代码来理解。2.3 信号的分类视角同步与异步信号还有一个值得区分的角度同步信号和异步信号。同步信号是进程自己执行指令时触发的问题比如除零SIGFPE、非法地址访问SIGSEGV、非法指令SIGILL这类信号其实是因为 CPU 执行指令出错由硬件异常触发内核再把这个异常包装成信号发给当前进程。同步信号的送达时机是确定的——就在出错的那条指令上。异步信号则来自进程之外比如另一个进程调用kill()发过来或者内核检测到某种软件条件例如写管道发现对端关闭内核直接向写进程发出 SIGPIPE。异步信号可能在进程执行到任意位置时到达处理时机和进程当前运行状态有关这也是信号处理程序天生需要面对重入问题的根源。理解这两类信号的差异对你判断为什么这里会收到信号很有帮助——是代码写错了还是外部环境变了排查方向完全不同。3. 信号的一生从触发到进入进程处理的全链路3.1 信号的产生方式不止是 kill 命令聊产生方式之前先看一张表把常见的信号来源列清楚来源类型具体场景典型信号进程主动发送调用kill()、raise()、killpg()任意指定信号终端操作按 CtrlC、Ctrl\SIGINT、SIGQUIT硬件异常除零、非法访问、非法指令SIGFPE、SIGSEGV、SIGILL软件条件管道写端被读端关闭、子进程退出、闹钟到期、终端挂断SIGPIPE、SIGCHLD、SIGALRM、SIGHUP内核检测写一个已关闭的 socket、运行停止的任务SIGPIPE、SIGCONT你会发现信号产生的方式比想象中广得多。kill命令调用的底层接口是kill(2)但很多信号是内核顺手发的。比如SIGCHLD子进程退出时内核自动给父进程发一个这是 shell 能知道后台任务结束的根源再比如SIGPIPE你用cat file | head -1的时候如果 head 提前退出cat 的写管道操作就会触发 SIGPIPE默认动作直接终止进程很多初学者第一次看到管道命令莫名中断就是没搞懂这一层。3.2 未决、递达与处理信号的三个生命周期阶段一个信号从产生到被进程处理中间的路径可以拆成三个阶段。第一阶段是产生generation。不管是 kill 调用还是内核检测到异常此时信号已经被创建出来准备投递给目标进程。第二阶段是未决pending。所谓未决就是信号已经产生但还没来得及递达给进程。这个状态通常发生在信号被阻塞的时候进程用sigprocmask或pthread_sigmask把某个信号加进了阻塞集合此时内核会把信号挂到进程的未决队列里等待解除阻塞。第三阶段是递达delivery。信号真正被进程处理这时候有三种可能执行默认动作通常是终止进程、忽略或停止进程、被进程捕获后执行自定义处理函数、或者被忽略。理解这个链路核心是区分事件发生和事件被处理这两件事。阻塞不是丢弃只是推迟。很多人写程序在关键临界区里随手屏蔽了 SIGINT最后发现 CtrlC 无效就是因为信号卡在未决队列里等到解除阻塞的瞬间才补上了那一刀。3.3 默认动作为什么大多数信号一声不吭就把进程杀了很多信号的处理函数你没注册过但你一定感受过它们的后果——进程直接死掉。这是信号的默认动作在起作用。系统里每个信号都有默认动作主要分五类终止进程、终止并生成核心转储core dump、停止进程、忽略、以及继续运行已停止的进程。常见信号里SIGKILL 和 SIGTERM 都是终止差别在于 SIGKILL 连捕获的机会都不给属于直接击毙SIGTERM 则可以由进程自己注册处理函数优雅退出这也是系统关机和容器停止时优先发 SIGTERM、而不是直接 SIGKILL 的原因。SIGSEGV 和 SIGFPE 这类同步错误信号默认是终止并生成 core 文件。生产环境里排查崩溃经常能看到一个几百兆的 core 文件那个文件其实就是进程崩溃那一刻的内存镜像。配合 gdb 用bt命令看调用栈能直接定位到是第几行代码访问了非法地址。这个习惯值得从一开始就养成——看到进程退出码是 139 或者 134别急着骂系统先查 core dump 和信号编号多半能把问题摁在摇篮里。4. 内核怎么记这笔账task_struct 里的信号核心数据结构4.1 三个核心区域信号掩码、未决信号、处理动作写应用层代码的时候你不需要直接操作内核数据结构但理解它们能帮你解释很多诡异现象。Linux 内核里每个进程描述符task_struct内与信号直接相关的信息主要有三块。第一块是信号掩码对应字段是blocked。它是一个位图每一位代表一个信号记录当前进程阻塞了哪些信号。你调用sigprocmask(SIG_BLOCK, ...)屏蔽信号行为上就是把这个位图对应的位置成 1。第二块是未决信号集对应字段是pending。这个结构稍微复杂一点里面有一个signal位图记录哪些信号处于未决状态还有一个链表sigqueue用来携带信号附带的额外数据。标准信号在未决集合里只占一个位所以多个同种未决信号会合并成一次递达实时信号则会真正挂到链表上排队。第三块是信号处理动作对应字段是sighand指向的sighand_struct。这个结构体里有一个action数组数组下标就是信号编号每个元素是一个k_sigaction里面保存了处理函数地址、标志位和掩码信息。进程调用signal()或sigaction()注册处理函数本质上就是修改这个数组里的对应项。这三块数据相互配合构成了信号机制的完整骨架blocked决定此刻能不能递达pending记录有哪些还没处理sighand决定处理的时候做什么。4.2 标准信号与实时信号的队列差异标准信号的未决表示就是位图加一个简单的队列这个设计对性能友好但代价是数量信息会丢失。设想一个场景网络服务进程阻塞了 SIGTERM在阻塞期间系统又发了两三次 SIGTERM当进程解除阻塞时内核最多只会让它执行一次处理函数。因为位图里 SIGTERM 那一位置为 1 之后再来 SIGTERM 不需要重复置位直接忽略。实时信号则不同内核为每个实时信号维护了多个挂载点允许在sigqueue链表里排队甚至可以带上一个整型或指针值sigval用于传递简单的数据。这个能力在需要精确计数的场景里很有用比如自定义的线程间通知机制希望在 N 次事件里每次都触发处理那就用实时信号。再用一张表把这个差异说清楚维度标准信号实时信号编号范围1-3132-64SIGRTMIN 到 SIGRTMAX是否排队否同种信号合并为一个未决位是支持按序排队是否携带数据通常不带可携带整型/指针值处理顺序不保证严格顺序同种信号按发送顺序递增适用场景通用事件通知、默认动作精确计数、带数据通知4.3 一次 kill 调用的内核旅程从系统调用到信号被处理整个过程可以串起来看一眼。假设进程 A 调用kill(pid, SIGUSR1)通知进程 B内核的处理路径大致是这样的kill()进入内核后根据 pid 找到目标进程的task_struct同时做权限校验确认发送者有权限向目标发送信号一般要求相同用户或特权进程。接下来调用send_signal()在目标进程的pending结构里做登记。如果是标准信号且该信号已经被阻塞就在未决位图里置位如果没被阻塞就直接尝试递达。递达环节内核会看目标进程是否注册了SIGUSR1的处理函数。如果没有注册就按默认动作处理如果注册了内核需要在目标进程的上下文中安排处理函数执行。这里涉及一个机制目标进程从内核态返回用户态之前内核会检查它是否有未处理的信号有则先跳到信号处理函数处理完再恢复之前的用户态上下文。这个从登记到执行处理函数的过程是理解信号时机问题的关键。信号处理函数不是内核单独拉一个线程去跑的它是在目标进程原有的线程上下文里插队执行的。这意味着信号处理函数与主流程天然是并发关系这也是后面讲异步安全函数的前提。5. 阻塞与未决信号处理中最常踩的坑5.1 sigprocmask 与 blocked 掩码阻塞信号的操作接口是sigprocmask()不过在阅读老代码时你可能会看到sigmask()配合sigblock()的旧写法那是 BSD 时代的遗产建议新代码统一走 POSIX 的sigprocmask和sigaction路线。sigprocmask的用法很多人背不下来其实就三个动作SIG_BLOCK把指定信号加入阻塞集合SIG_UNBLOCK从集合里移除SIG_SETMASK直接整个替换当前集合。举个例子sigset_t set; sigemptyset(set); sigaddset(set, SIGINT); // 进入临界区前屏蔽 SIGINT sigprocmask(SIG_BLOCK, set, NULL); // ... do critical work ... // 退出临界区恢复原本掩码旧掩码可提前保存 sigprocmask(SIG_UNBLOCK, set, NULL);这个接口在信号处理代码里几乎无处不在。多线程程序里还得注意用pthread_sigmask()而不是sigprocmask()两者的关系后面单独讲。5.2 为什么程序卡死的时候还能被杀死有个常见的现象你写了个死循环程序CPU 跑满物业那边 CtrlC 无效但执行kill -9却能杀掉它。很多人困惑点在于——死循环里明明没地方去检查信号啊SIGKILL 是怎么生效的答案是信号的递达不依赖进程主动检查而是依赖内核在进程被调度到、并从内核态返回用户态时做检查。进程不管跑在哪里系统调用返回、中断处理后返回内核都会检查pending集合发现有未处理的信号且信号的掩码允许递达就会强制改变进程的控制流先执行信号处理逻辑。SIGKILL 更特殊它默认动作就是无条件的终止进程不给你注册处理函数的机会所以在任何状态下都能生效。但有个细节很多人没意识到如果进程阻塞了某一个信号这个信号就会一直挂在未决队列里直到你解除阻塞。比如 SIGINT 被阻塞后你按十次 CtrlC进程感知到的可能只是一次迟到的 SIGINT。这个延迟可能非常长——如果你在临界区里屏蔽了信号但因为逻辑 bug 一直没退出临界区信号就一直卡着看起来像是怎么按都杀不掉。这时候最容易被误认为程序失去响应实际原因在信号掩码。5.3 父进程 exec 之后的信号清空问题讲一个实际操作中特别容易踩的坑进程调用exec()执行新程序之后之前注册的信号处理函数全部丢失恢复为默认动作。但阻塞掩码和未决信号集合会保留下来除非你显式设置了SA_ONEXEC之类的行为。这意味着什么假设你的父进程屏蔽了某个信号然后exec()启动了子进程子进程会继承这个被屏蔽的状态却不知道这回事。如果后续有人向它发信号会被悄悄挂起造成诡异的信号丢失假象。这种问题在守护进程 fork 出子进程、子进程再 exec 新二进制的场景里非常常见。经验做法是fork 之后如果要 exec尽量在 exec 之前重置信号掩码和处理函数或者使用execve()之前把不需要的阻塞全部解除。子进程继承的环境越干净后续排查越轻松。6. sigaction 进阶处理函数背后那些容易被忽略的标志位6.1 从 signal 到 sigaction为什么推荐用后者早期代码里最常见的是signal()注册处理函数一行搞定看着清爽。但signal()的实现在不同系统上有不同的历史包袱在某些系统里它是一次性的——处理完一次信号后恢复默认动作下一次信号直接干掉进程。POSIX 不推荐用signal()做关键信号处理规范建议使用sigaction()。虽然现代 glibc 的signal()大多已经支持了稳定语义但为了跨平台可控性我建议一律走sigaction()。来看一段注册 SIGTERM 的典型写法struct sigaction sa; sa.sa_handler handle_term; sigemptyset(sa.sa_mask); sa.sa_flags 0; sigaction(SIGTERM, sa, NULL);sa_mask是另一个容易漏掉的细节在信号处理函数执行期间sa_mask里指定的信号会被自动阻塞防止处理函数执行到一半又被另一个信号打断。如果你希望在处理函数执行期间同时屏蔽其他几个信号就得在这里设置。否则处理函数运行中可能被同信号再次打扰形成递归调用栈很容易爆掉。6.2 SA_SIGINFO三参数处理函数与 siginfo_tsigaction结构里的sa_flags决定了很多隐藏行为。最值得掌握的是SA_SIGINFO。设置了它之后处理函数不再是一个参数的形式而是三参数版本void handler(int sig, siginfo_t *info, void *ucontext) { // sig: 信号编号 // info: 信号附加信息包含发送者 pid、uid、信号来源等 // ucontext: 被中断的上下文极少数场景用得上 }siginfo_t里能拿到不少平时不容易获取的信息si_pid告诉你信号是谁发的、si_uid告诉你是谁发的si_code表明信号产生的原因是用户调用 kill 发的还是内核因为硬件异常发的si_value则可以拿到通过实时信号传过来的整数或指针。很多多进程协作框架里发信号一方会把任务的编号或超时时间塞进si_value接收方无需额外通信就能知道来活了哪个活。6.3 SA_RESTART 与 EINTR被信号打断的系统调用这块是排查程序异常时的高频盲区。一个进程在read()或write()等阻塞系统调用里等待时如果有信号到达并捕获处理完毕这个系统调用可能被中断。如果没设置SA_RESTART系统调用会返回-1errno被设为EINTR。很多开发者写代码时没做EINTR的兼容处理结果程序一收到信号就莫名其妙地退出日志里只有read: Interrupted system call。SA_RESTART的作用就是让内核在处理完信号后自动重新启动被中断的系统调用对普通文件 IO 和部分慢速设备尤其有用。但注意并不是所有系统调用都能被自动重启。像select()、poll()、epoll_wait()、nanosleep()等函数即使设置了SA_RESTART也可能返回EINTR——这些函数在文档里明确说明它们不受SA_RESTART 控制。由此得出的工程经验是凡是会阻塞的系统调用都要显式处理EINTR返回值不能指望内核兜底。很多网络框架里常见的写法是ssize_t n read(fd, buf, sizeof(buf)); if (n 0 errno EINTR) { continue; // 或重新开始本次读操作 }这个判断看起来不起眼但缺了它一个正常的 SIGWINCH终端窗口大小变化信号就可能让你的网络服务以为连接出错了。7. 多线程环境怎么发信号线程组、掩码与异步安全的边界7.1 线程组模型共享的处理动作与独立的掩码Linux 的线程本质是轻量级进程LWP同一进程内的多个线程共享一个线程组 IDTGID但每个线程有自己独立的task_struct。信号机制在这个模型下有两个让人困惑的点信号处理动作sighand是线程组共享的任何一个线程用sigaction()注册了处理函数组内所有线程都生效但信号掩码和未决信号是每个线程独立的也就是说线程 A 可以阻塞 SIGINT线程 B 可以不阻塞 SIGINT。向进程发送信号用kill()时非定向信号如何选择接收线程是有讲究的内核通常会让某个未阻塞该信号的线程接收如果所有线程都阻塞了它信号就挂到进程级未决集合里等待。而线程定向信号用pthread_kill()或tgkill()则会直接投递给指定线程即使其他线程没有阻塞它。这带来一个实战指导多线程程序里做信号处理规划要先想清楚要通知谁。如果希望某个专用线程统一处理系统信号比如 SIGINT、SIGTERM那就应该在主线程里用pthread_sigmask()阻塞所有相关信号同时保证其他线程也都阻塞它们然后在专用线程里循环调用sigwait()或signalfd来接收。否则会出现信号被任意一个线程吃掉的随机行为逻辑完全不可控。7.2 异步信号安全函数为什么处理函数里不能乱调 printf前面说过信号处理函数是在主流程任意位置插队执行的这就意味着处理函数执行时主流程可能正好卡在某个库函数内部比如正在调用malloc()分配堆内存。如果处理函数里也调用malloc()同一个进程的堆分配状态就会被两个上下文同时修改轻则内存损坏重则直接崩溃。POSIX 定义了异步信号安全函数列表这些函数保证即使它们在主流程中被中断再次被调用也不会出问题。write()、read()、open()、close()、_exit()、sigaction()等都在列表里而printf()、malloc()、free()、pthread_*系列函数都不在列表里信号处理函数调用它们属于危险行为。这个限制让许多初学者初次接触时很不适应——打印个日志都不行工程上的标准做法是信号处理函数里只做最基本的标记比如用volatile sig_atomic_t变量记录信号到达主流程通过轮询这个变量来响应。如果需要传递更复杂的信息就用异步信号安全的管道或self-pipe机制处理函数里只往一个预先打开的管道写一个字节主流程在另一头用poll()监听这个管道。这确保了处理函数的执行时间极短逻辑极简单所有的复杂处理都回到主流程上下文里完成。7.3 一个实际例子用 signalfd 把信号当成文件来读说到自管道技巧Linux 内核其实已经提供了更优雅的封装——signalfd()。它能把信号变成可以读的文件描述符配合epoll使用就能在事件循环里统一处理网络 IO 和信号事件避免信号处理函数里的异步上下文问题。sigset_t mask; sigemptyset(mask); sigaddset(mask, SIGINT); sigaddset(mask, SIGTERM); sigprocmask(SIG_BLOCK, mask, NULL); // 必须先阻塞signalfd 才能收到 int sfd signalfd(-1, mask, SFD_NONBLOCK | SFD_CLOEXEC); // 然后把 sfd 加入 epoll当成普通 fd 处理 struct signalfd_siginfo fdsi; ssize_t n read(sfd, fdsi, sizeof(fdsi)); if (n sizeof(fdsi)) { int sig fdsi.ssi_signo; // 在主线程上下文里处理信号 }这个方案的优点是立竿见影的信号处理和业务逻辑跑在同一个线程上下文不需要考虑异步安全函数可以直接操作堆数据结构、打日志、做清理。我在自己写事件驱动服务的时候几乎全部用 signalfd 替代了信号处理函数。唯一的注意点是别忘记先阻塞对应信号否则 signalfd 会什么都读不到——因为这个文件描述符只在信号处于未决状态时才有已注册数据可读。8. 实战排查我遇到过的三个信号疑难杂症8.1 守护进程半夜崩溃SIGSEGV 与核心转储定位回到开头那个案例。退出码 139 说明进程被 SIGSEGV 终止这类崩溃十有八九是野指针、数组越界或者空指针解引用。先用系统工具确认$ kill -l 11 SEGV $ cat /proc/sys/kernel/core_pattern /home/core/core.%pcore_pattern指明核心转储文件位置。用 gdb 打开$ gdb ./a.out /home/core/core.1234 (gdb) bt看到调用栈的瞬间问题往往就清楚了。那次排查最终定位到一段代码在深夜切日历时访问了一个已经释放的结构体指针典型的 use-after-free。围绕信号排查我的建议是见到异常退出码第一反应查128 信号编号然后看 syslog 里的 signal 描述最后挂着 gdb 或读 core 拿栈。这套流程比对着日志猜效率高很多。8.2 Broken pipe 与 SIGPIPE网络服务的经典坑另一个高频问题是 SIGPIPE。当进程向一个已经关闭的 socket 或管道写入数据时内核直接发送 SIGPIPE默认动作是终止进程。很多网络服务在客户端主动断开后服务端再往 socket 写数据进程就静默退出日志里什么都查不到——因为根本没有日志。解决思路一般有两种要么统一忽略 SIGPIPE改用send()配合MSG_NOSIGNAL标志让写错误以错误码的方式返回要么注册 SIGPIPE 的处理函数在日志里记录到底哪条连接出了问题。我偏好后者尤其是在调试阶段它能暴露很多连接被对端重置的隐性情况。生产环境对稳定性要求更高时可以忽略信号并依赖epoll的出错事件来清理连接。8.3 信号竞态两次发送为什么只生效了一次最后一个案例讲一个比较隐蔽的竞态。某开发者写了一个用户态程序用标准信号 SIGUSR1 来做两个线程间的轻量通知每次事件触发就往处理器里增加计数。测试时发现事件触发了 100 次计数却不到 100总有丢失。这个问题的根子就在标准信号不排队内核只在未决位图里维护一位如果信号还在未决阶段比如处理函数还没跑完或信号还没递达新来的同类信号会被合并最后一次事件就丢了。解决方案有三个改用实时信号SIGRTMIN 往上让内核帮你排队或者改用不太依赖信号计数的机制比如原子变量加条件变量再或者每次发送时确保信号已被处理完成但这种同步通常比信号本身的开销还大得不偿失。我的经验是进程间或线程间的通知如果涉及计数、批量事件尽量不要依赖标准信号要么用实时信号要么走eventfd或条件变量这类专用机制。信号适合传达事实发生了不适合传达发生了多少次。9. 关于信号我建议你重新梳理的几个习惯信号机制的内容讲到这里核心链路已经串起来了。最后分享几点长期实践中沉淀下来的习惯。首先注册处理函数一律用sigaction()并且根据场景仔细设置sa_mask和sa_flags。不要嫌麻烦这份代码写的越仔细后期排查的成本越低。分布式系统里加个信号处理函数之前先想清楚它会打断哪些系统调用EINTR的兼容代码该补就补。其次把信号当成最后手段而不是主要通信工具。信号携带的信息量极低排队语义对标准信号又不友好凡是需要传数据的跨进程通信优先考虑 Unix Domain Socket、共享内存或eventfd。信号适合做控制面的事情比如优雅退出、重新加载配置、触发转储不适合做数据面的事情。最后养成读内核细节的习惯。遇到信号相关的问题多翻一下/proc/pid/status里的SigBlk、SigCgt、SigIgn、SigPnd字段。这些信息直接反映了进程当前的信号掩码、捕获动作和未决状态。用一条命令就能看进程信号层面的健康状况比对着代码猜测高效得多。信号这个机制从表面看只有几十个编号但真正把它放入进程模型、中断上下文和并发环境中理解就会发现它连接了内核调度、CPU 异常处理和用户态代码执行的多个层面。我这些年排查过的大量诡异问题最后都指向信号生命周期里的某个环节——要么是未决信号堆积要么是处理函数破坏了异步安全。把这些底层逻辑理清调试疑难杂症时心里会踏实许多。