写后台服务时间长了你迟早会撞上这么一件让人挠头的事进程明明还在top 里也好好的但该响应的接口就是不回包你怀疑死锁、怀疑内存膨胀最后 strace 一跟发现是一条信号处理写得不对把关键路径堵死了。这类问题在 Linux 服务端、嵌入式守护进程和运维脚本里尤其隐蔽。信号这套机制表面上看就是“进程收到一个通知然后去做点啥”实际从内核的异步通知、信号屏蔽、排队丢失到处理函数的重入限制到处是坑。我写这篇文章不打算把信号列表抄一遍了事而是想把信号从产生、送达、处理到应用实战这条链路拆开讲清楚底层逻辑再把我在真实项目里踩过的坑和验证过的写法一并放出来。不管你是刚开始写 Linux 程序的初学者还是已经带过几个项目的工程师应该都能从中找到对自己有用的那一段。1. 信号的本质它不是你想的那种“中断”1.1 信号到底是怎么从内核送到进程的信号本质上是一种软件层面的异步事件通知机制。你可以把它想象成“内核往进程的门口贴了一张纸条”进程本身并不需要时刻盯着门。但这里有个关键点信号的送达时机并不是立刻的。进程在用户态跑代码时内核并不会强行打断它去执行信号处理函数而是在进程从内核态返回用户态的那个瞬间检查一下当前进程的 pending 信号集合如果有信号就先跳转到对应的处理函数执行完再恢复原来的执行上下文。这个“从内核态返回用户态时处理”的细节特别重要。很多初学者以为信号一到进程就像被插播广告一样立刻被打断其实不是。我举个实际例子你写一个死循环做纯计算不发任何系统调用然后另开一个终端向它发送 SIGTERM你会发现它并不会马上退出而是要在某个时间片结束、内核调度器切换它出去又切回来时才真正去处理信号。这也就解释了为什么网络程序里常常出现“明明发送了 kill进程半天没反应”的假象——如果进程正卡在一个不可中断的内核态操作里信号就可能被推迟。1.2 我更愿意拿信号跟轮询和中断做对比网上很多文章把信号叫“软件中断”我觉得只对了一半。硬件中断确实会打断 CPU 当前的执行流信号则很少直接打断用户态代码它更像是“内核在进程的固定检查点处理待办事项”。这也是我们写代码时理解信号的关键轮询主动、确定、可预知但费 CPU硬件中断完全异步、强制打断由内核处理信号异步但“软”的处理时机由内核调度和系统调用返回路径决定。正因为信号的处理时机不确定我们才需要特别注意竞态、重入这些破事。Linux 内核为每个进程维护了一个信号 pending 位图以及一张信号处理函数的 action 表也就是struct sigaction。进程每次从内核态返回时都会检查TIF_SIGPENDING这个标志位如果置位就进入信号处理流程。弄清这个机制后面所有的坑你都能自己推出来。2. 一份能直接用的信号业务清单该处理的信号和该躲开的信号2.1 从 SIGINT 到 SIGTERM我最常打交道的那批信号服务端程序跑起来以后真正需要我亲手处理的信号其实就那几个。第一梯队是SIGTERM、SIGINT、SIGHUP、SIGUSR1/SIGUSR2、SIGCHLD。SIGTERM是系统管理员最常用的“请你优雅退出”的信号也是我们写服务时唯一的正当退出通道。SIGINT是终端 CtrlC 产生的在前台程序里也等同于“请求退出”。而SIGHUP在传统意义上表示“控制终端挂断”——很多守护进程利用它来做配置重载这个习惯从 sysvinit 时代一直延续到今天我自己的服务就习惯让SIGHUP触发重新读取配置文件而不是直接退出。第二梯队是SIGKILL和SIGSTOP。这两个信号不可捕获、不可忽略是内核给系统管理员留的“最后手段”。任何业务代码都不该尝试去拦截它们因为拦也拦不住。第三梯队是各种“出错类”信号比如SIGSEGV、SIGBUS、SIGFPE这些默认都是 core dump。出于调试便利我偶尔会在测试程序里临时给SIGSEGV挂一个 handler 打印调用栈但在生产代码里绝不会碰。2.2 我常背的那张信号表格下表是我自己总结的常用信号清单为了方便记忆我把编号、默认动作和典型触发场景都揉进来了信号编号默认动作典型触发场景SIGHUP1终止进程控制终端挂断、守护进程重载配置SIGINT2终止进程终端按 CtrlCSIGQUIT3终止进程并 core dump终端按 Ctrl\SIGKILL9不可捕获强制终止kill -9SIGSEGV11终止并 core dump非法内存访问SIGPIPE13终止进程向已关闭的 socket/管道写数据SIGTERM15终止进程kill 默认发送的信号SIGCHLD17忽略子进程终止通知父进程收尸SIGUSR110终止进程用户自定义事件SIGUSR212终止进程用户自定义事件SIGRTMIN34终止进程实时信号起点支持排队实战的时候我最常对新人强调三点一是SIGPIPE一定要处理或忽略。网络服务里如果对端关闭了连接你还继续写数据进程会直接收到SIGPIPE然后死掉很多人排查“为什么进程莫名其妙退出”第一个查漏的就是它。二是SIGCHLD几乎每个多进程服务都必须接否则子进程退出后会一直挂在僵尸状态。三是SIGUSR1/SIGUSR2这种自定义信号别在业务逻辑里压太多含义信号本身不带优先级塞太多状态进去就是给自己埋雷。3. 手写信号处理程序别再用老掉牙的 signal() 了3.1 用 sigaction 替换 signal() 的三个理由我发现现在很多入门的 C 代码还在用signal()注册处理函数新手拿着书照抄问题是这套 API 的历史包袱太重。signal()的行为在不同 Unix 实现上差异非常大有些系统在 handler 执行完之后会把处理函数重置为默认行为有些不会有些系统被信号打断的系统调用会自动重启有些不会。Linux 上的signal()虽然等同于带SA_RESTART的sigaction但你要是把代码移植到别的平台很容易踩“第一次信号能收到第二次信号就恢复默认退出”这种坑。sigaction()才是 POSIX 推荐的正路。它让你显式地控制三件事处理函数是哪种类型普通 handler 还是带siginfo_t详情的高级 handlerhandler 执行期间要屏蔽哪些其他信号通过sa_mask指定被信号打断的系统调用是否自动重启SA_RESTART。这三个参数直接决定了进程在高并发、多信号场景下的稳定性。我举个例子你在一个网络服务里只注册了 SIGTERM 的处理函数但没设置sa_mask当 SIGTERM 处理函数正在执行时突然又来一个 SIGUSR1那 SIGUSR1 就会嵌套打断当前的处理函数。如果两个 handler 里都操作同一个全局状态那恭喜你解锁了“信号重入竞态”副本。3.2 一段能扛住多信号冲击的示例代码下面这段代码是我的标准模板用一个volatile sig_atomic_t类型的全局变量标记退出请求主循环里轮询这个标记。volatile是必须的否则编译器可能把全局变量优化到寄存器里导致 handler 改了值主循环却看不见。#include signal.h #include stdio.h #include unistd.h #include stdlib.h static volatile sig_atomic_t g_running 1; static void handle_sigterm(int sig) { (void)sig; g_running 0; } static int install_handler(void) { struct sigaction sa; sigemptyset(sa.sa_mask); sigaddset(sa.sa_mask, SIGUSR1); /* handler 执行时屏蔽 SIGUSR1 */ sa.sa_flags 0; sa.sa_handler handle_sigterm; if (sigaction(SIGTERM, sa, NULL) 0) { perror(sigaction); return -1; } return 0; } int main(void) { if (install_handler() 0) exit(EXIT_FAILURE); printf(Server started, pid%ld\n, (long)getpid()); while (g_running) { sleep(1); /* 正常工作 */ } printf(Server shutting down gracefully\n); return 0; }你注意到我特意在sa_mask里加上了SIGUSR1意思想表达一个常见业务场景我不想在处理退出信号的时候再被一个和业务强相关的信号插入干扰。代码里的 sleep 会不断被信号打断但只要你在sa_flags里不设置SA_RESTARTsleep 被打断后会返回剩余秒数循环自然也会继续检查g_running所以退出响应非常及时。3.3 如果要用高级信息还能怎么写有时候光知道“哪个信号到了”不够我还想知道信号是谁发的、出自哪个进程这时候就要靠SA_SIGINFO配合siginfo_t参数。举个场景主进程给工作进程发送 SIGUSR1让它处理某个任务工作进程最好知道“是谁让我干活的”以便回传结果。此时 handler 写成三个参数static void handle_sigusr1(int sig, siginfo_t *info, void *context) { (void)sig; (void)context; printf(signal %d from pid %ld uid %ld\n, sig, (long)info-si_pid, (long)info-si_uid); }注册的时候sa_flags要写成SA_SIGINFO。这个功能在实现进程协作、任务分发时特别有用。比如我维护过的一个嵌入式项目里主进程通过给不同子进程发送带si_value的信号来触发不同类型的采集任务子进程在 handler 里直接把sival_int当作任务编号省掉了重量级的 socket/共享内存通信。信号承载不了大数据但承载一个表示“事件类型”的整数绰绰有余。4. 生产环境里的信号陷阱一个一个讲给你听4.1 信号不是排队公交车丢失与合并问题敲黑板普通信号是不排队的。什么意思假设进程给另一个进程连续发送三次相同的 SIGUSR1而目标进程因为某些原因还没来得及处理实际最终处理次数很可能只有一次。内核里维护的是“信号集合”而不是“信号计数”只要 pending 集合里该信号位已经置为 1再发相同信号就不会再置一次。这个特性在统计场景里特别坑。以前我有个项目想用信号通知工作进程“数据文件来了有空去读”结果生产环境连续收到三份数据进程只处理了一份剩下两份丢得不明不白。解决这个问题常规办法是换成实时信号。以SIGRTMIN开头的实时信号支持排队每个信号都有独立的 pending 队列还能通过sigqueue()附带整数或指针值。缺点是实时信号数量有限你得提前规划好用途别把整条SIGRTMIN~SIGRTMAX范围当撒芝麻一样用。4.2 为什么我从来不建议在 handler 里写 printf这是信号处理里最经典的大坑。你在 handler 里调用printf、malloc、pthread_mutex_lock这些函数的时候进程可能正卡在某个库函数的临界区域里。比如主程序正在执行malloc内部链表处于一个脆弱状态此时信号来了handler 里又调一次malloc两步操作直接互相踩踏轻则脏数据重则死锁崩溃。这类函数有个专门名词叫“非异步信号安全函数”。C 标准只保证很小一部分函数可以在信号处理函数里安全调用我们熟知的write、open、close、read、_exit、sigaction等系统调用是安全的printf、sprintf、malloc、free、strtok基本都不是。为了便于记忆我把常用且安全和不安全的函数整理如下信号处理函数中安全信号处理函数中不安全read / write / open / closeprintf / fprintf / sprintfpread / pwrite / readlinkmalloc / free / reallocsigaction / sigprocmaskpthread_mutex_lock / unlockkill / raise / waitpid / _exitstdio 库任何函数time / getpid / getuidsyslog / 很多网络库函数我的个人经验是与其背这张表不如定一个铁律——handler 里不写、不算、不锁只做两件事改一个 volatile 变量或者往一个管道写端 write 一个字节。如果业务逻辑复杂就把事件交给主循环做。4.3 自管道self-pipe技巧怎么把信号变成数据流我前面提到 handler 里只写管道正好展开讲讲。这个技巧叫 self-pipe原理很简单程序初始化时创建一个管道handler 里用write(fd, , 1)把信号事件转成一个字节写进去主循环里用read(fd)阻塞等待收到字节再判断是哪个信号可以写不同字节值代表不同信号。这样一来信号处理就从异步回调变成同步的消息读取。竞态没了锁不用加printf 随便用因为真正干活的地方是主循环线程。我实际写服务时很喜欢这个模式。举个例子一台服务器同时要响应 SIGTERM 优雅退出、SIGHUP 重载配置、SIGUSR1 打印状态三个 handler 分别往同一个管道写T、H、S主循环依次读取并分支处理。代码结构非常清晰整个进程的状态切换都在一条主路径上有序完成绝不会出现 handler 打断 handler 的混乱局面。4.4 信号阻塞与解除阻塞sigprocmask 的正确用法还有一个容易被忽略的工具sigprocmask。它可以在不进 handler 的情况下临时屏蔽某些信号。比如一段临界区代码要连续修改几个文件不希望中间被 SIGTERM 打断导致状态不一致就可以先sigprocmask(SIG_BLOCK, set, NULL)屏蔽 SIGTERM处理完再SIG_UNBLOCK恢复。注意屏蔽不等于丢弃信号解除屏蔽后如果还在 pending内核会马上补送你一次。这个工具在守护进程的关停流程里非常有用我自己的服务在停止时会先屏蔽所有业务信号把状态落盘最后再解除屏蔽让退出信号生效确保“停止”这个动作本身是原子的。5. 信号在进程协作里的真实角色waitpid、守护进程与进程组5.1 SIGCHLD 和 waitpid处理僵尸进程的“收尸”链条多进程服务绕不开子进程管理。子进程退出时内核给父进程发一个SIGCHLD此时子进程的进程描述符还躺在系统进程表里直到父进程调用waitpid()才真正回收资源、释放进程号。如果父进程一直不关心子进程就变成僵尸进程挡在进程表里占着 pid一个大型服务运行几周你就能在 top 里看到成片defunct那基本就是 SIGCHLD 处理漏了。正确做法是在 SIGCHLD 的 handler 里循环waitpid(-1, status, WNOHANG)把能收的子进程全收掉。注意WNOHANG必须带上否则当所有子进程都已被收干净时该次调用反而可能阻塞把信号处理路径卡死。我这里给一个常用的处理片段static void handle_sigchld(int sig) { (void)sig; int saved_errno errno; /* 保存 errno尽量不破坏主流程的排错信息 */ pid_t pid; int status; while ((pid waitpid(-1, status, WNOHANG)) 0) { /* 记录 pid 和退出状态 */ } errno saved_errno; }这里有个小细节handler 里保存并恢复errno因为很多系统调用以返回值 errno 来报错如果 handler 里调用的 waitpid 修改了 errno而主流程刚好走到一个错误判断分支就会拿到被污染的 errno导致排查困难。这种细节通常不会写进课本但线上问题往往就藏在这些地方。5.2 进程组与会话kill 负数发送的对象不是你以为的那个进程另一个我经常提醒别人的点是kill(pid)里如果 pid 为负数比如kill(-1234)发送的对象不是 pid1234而是进程组 ID 为 1234 的整个进程组。想精确地只给某个进程发信号pid 就必须是正整数。很多脚本为了省事直接kill $(pgrep foo)但如果 pgrep 输出了多个 pid这条命令就会变成给多个进程发信号行为可能出乎意料。进程组和会话的坑在写守护进程时尤其致命。一个进程如果直接 fork 而不做setsid()它会留在原先的会话里控制终端一关闭内核就会向这个会话的所有进程发SIGHUP进程树当场倒下。这就是为什么标准守护进程化流程必须是 fork - setsid - 再次 fork可选- chdir - 重设文件权限掩码 - 重定向 stdin/stdout/stderr 到 /dev/null。我见过好些新手写“伪守护进程”就是缺了setsid()一关掉终端进程跟着死还以为是代码 bug。5.3 在我的一个项目里信号是如何撑起优雅关闭的最后说一个实际案例。我之前维护过一个嵌入式 Linux 采集服务主进程管理 8 个工作子进程每个子进程负责一路传感器数据采集。关停系统的要求是停止接受新任务把已采集数据落盘通知上层系统再退出。我设计了一套信号协作方案工作进程收到主进程发来的SIGTERM后置位g_running 0优雅退出主进程收到工作进程的SIGCHLD后waitpid收取退出状态管理端口把“所有子进程已安全退出”的状态上报最后主进程在收到第二个SIGTERM时如果第一次超时做一次强制清理退出。这套方案里信号承担了“事件提醒”的职责而真正的状态流转和数据交换都落在主循环的管道读取分支里。运行两年多没有再出现过进程卡死或者数据写坏的问题。如果非要给点个人建议我会说把信号当作门铃而不是当作搬运工。门铃响一下你就知道门口有事但开门接快递这种事还是让主循环里的人去干吧。