写这文章之前我想先问一句你写Linux程序的时候有没有遇到过这种情况——程序跑得好好的按下CtrlC没反应或者进程莫名其妙就没了连个core dump都没留下又或者你明明在代码里写了signal(SIGCHLD, handler)子进程退出时回调就是不触发如果你点头了那说明你对Linux信号的理解还停留在会用几个API的层面。这篇文章我会从内核视角把信号的发送、捕获、阻塞、递达这些机制讲透最后给一个完整的优雅退出实战代码。系统编程这行信号这块属于那种看起来简单、用起来到处是坑的知识点值得花点时间把它啃下来。1. 信号到底是什么从内核视角看异步通知机制先别急着翻手册咱们把概念先理清楚。信号Signal在Linux里是进程间通信IPC的一种方式但它和管道、共享内存、消息队列完全不是一类东西。管道那种是数据交换信号本质上是一种异步事件通知机制——内核告诉某个进程你家里出事了你自己看着办。1.1 信号不是中断它是内核发给进程的异步通知很多初学者会把信号和硬件中断搞混这个误会得解开。硬件中断是CPU级别的机制由中断控制器发给处理器处理器硬件级别响应而信号是内核在软件层面维护的一套待处理事件标记发给进程而不是CPU。整个信号的生存周期大致是这样产生某个事件发生内核或用户调用kill()等接口把一个信号登记到目标进程的PCB里。注册内核在目标进程的task_struct里把对应的信号位图置位。注意这里只是置位不是立刻执行。递达在进程从内核态返回用户态的前夕内核检查这个进程的未决信号集合如果发现有待处理的信号就修改用户态的指令指针让进程先跑去执行信号处理函数或者执行默认动作完了再回到原来的指令位置继续跑。也就是说信号的执行时机是进程从内核态返回用户态的那一刻。这个过程每时每刻都在发生——你写的每次read()、每次系统调用返回、每次时钟中断都可能触发一次信号检查。1.2 信号家族图谱你迟早会碰到的十几个常见信号Linux标准信号一共31个1-31没有0下面这些是你写程序时一定会遇到的列个表记下来信号编号默认动作典型触发场景SIGHUP1终止进程终端挂断、控制终端关闭SIGINT2终止进程终端CtrlCSIGQUIT3终止并产生core终端Ctrl\SIGILL4终止并产生core非法指令SIGTRAP5终止并产生core断点陷阱SIGABRT6终止并产生coreabort()调用SIGBUS7终止并产生core总线错误SIGFPE8终止并产生core除零等算术异常SIGKILL9终止进程不可捕获kill -9SIGUSR110终止进程用户自定义SIGSEGV11终止并产生core段错误、非法内存访问SIGUSR212终止进程用户自定义SIGPIPE13终止进程写管道但读端已关闭SIGALRM14终止进程alarm()定时器到期SIGTERM15终止进程kill命令默认信号SIGCHLD17忽略子进程停止或退出SIGCONT18继续进程继续已停止的进程SIGSTOP19停止进程不可捕获暂停进程SIGTSTP20停止进程终端CtrlZSIGWINCH28忽略终端窗口大小变化我特意把SIGPIPE列出来了这个信号是新手最容易翻车的地方你往一个已经关闭读端的管道或者socket写数据第一次写可能触发SIGPIPE默认动作是终止进程。很多网络服务程序莫名其妙挂掉查了半天发现是对端断开后自己还在疯狂write。2. 信号的发送kill、raise、alarm及其他信号产生之后你得知道怎么精准地把它送出去。这一节我把常用的发送手段掰开揉碎了说。2.1 kill系统调用不只是Shell里的那条命令Shell里的kill -9 12345大家都用过但那个命令底层只是包了一层kill()系统调用。系统调用原型是#include sys/types.h #include signal.h int kill(pid_t pid, int sig);这里有个细节值得展开pid参数不是只能传一个具体进程ID。它有一套约定pid 0信号发给指定进程pid 0信号发给当前进程组内的所有进程pid -1信号发给调用者有权发送的所有进程除init和自身pid -1信号发给进程组ID等于abs(pid)的所有进程实战里用到pid -1的极少但pid 0这个很实用——我经常用它来给同一个进程组里的多个协作进程广播信号比如让一组worker同时退出。还有权限问题。不是你随便向哪个进程都能发信号你要么是root要么是目标进程的ownerUID相同否则kill()会返回EPERM。另外还有个冷知识kill(pid, 0)不发送任何信号但会做完整的权限校验和存在性检查。你完全可以用它来判断一个进程是否还活着、自己有没有权限管它。2.2 alarm定时器与SIGALRM廉价但粗糙的计时工具alarm是很多程序员最早接触信号的入口#include unistd.h unsigned int alarm(unsigned int seconds);它做的事情很简单让内核在seconds秒后给当前进程发送SIGALRM。返回值为之前尚未到期的定时器剩余秒数如果没有之前的定时器则返回0。为什么说它廉价但粗糙因为一个进程同一时刻只能有一个alarm定时器。你再调一次alarm()之前的就被取消了。而且要计时到微秒、纳秒级别得换成setitimer()或者POSIX定时器timer_create()。alarm适合什么场景比如超时保护——你的程序要等一个外部操作完成但不能无限等下去就设个alarm超时直接SIGALRM干进去。注意SIGALRM的默认动作是终止进程。如果你只是想要超时提醒而不是超时杀死记得在进程启动时就注册SIGALRM的处理函数否则alarm到期的那一下你的进程直接就没了。2.3 给自己的进程发信号raise与实际身份问题有时候你不需要发给别人就想在当前进程内部触发某个信号。两个选择#include signal.h int raise(int sig); // 给当前进程发信号 int kill(getpid(), sig); // 等价操作raise()在多线程环境下有点讲究它发送信号的目标是调用线程而kill(getpid(), sig)发送的是给整个进程。对于进程级信号处理来说绝大多数情况下效果一样但如果你在用线程级别的信号管理比如pthread_sigmask这个区别就会暴露出来。2.4 一套更现代的接口sigqueue与实时信号标准信号的问题在于不携带数据——就是一个数字int值。你SIGUSR1和SIGUSR1没什么区别完全不知道谁发的、为什么发。如果跨进程需要传递简单信息可以考虑用sigqueue#include signal.h int sigqueue(pid_t pid, int sig, const union sigval value);union sigval里可以塞一个int或者一个指针接收方在信号处理函数的siginfo_t结构里能取到这份数据。这一下子就把信号从一个干巴巴的通知变成了带附件的通知。不过要说明的是只有实时信号SIGRTMIN到SIGRTMAX编号32-64吃这套排队携带数据机制标准信号那个队列是内核里的一个位图根本不存数据。3. 捕获与处理signal是坑sigaction是答案信号发出来了进程要接住它。接住的方式有两种默认动作可能终止进程、可能忽略、可能产生core或者你自己注册一个处理器函数。注册API有两个老掉牙的signal()和推荐的sigaction()。我强烈建议你写新代码一律用sigaction。3.1 信号处理函数为什么会打断你的代码理解这个问题之前先看一个很反直觉的事实你正在main()里读一个文件、算一个表达式突然SIGINT来了内核把处理函数拉起来执行处理函数里又做了一堆事跑完才回到你刚才的代码继续执行。你的程序没有任何感知仿佛什么都没发生过。这就意味着信号处理函数是一个异步插入的并发执行流。它和你主线程的正常代码共享同一份全局数据但它可能在任意指令位置插入。如果在处理函数里访问了主逻辑正在修改的同一个非原子变量数据竞争就来了。这是信号编程里最隐蔽也最危险的坑。3.2 signal函数的旧时代缺陷语义差异与回调重置signal()的经典用法是#include signal.h typedef void (*sighandler_t)(int); sighandler_t signal(int signum, sighandler_t handler);这个函数有两个知名缺陷第一行为在历史上有分歧。在System V的Unix上信号处理完之后处置方式会被重置为默认行为下次再收到相同信号就按默认动作走而BSD的实现里处理完之后会保持用户注册的handler。Linux的glibc默认跟着BSD走但你没法保证所有平台行为一致。第二处理函数执行期间相同信号会被自动阻塞。这看起来是好事对吧但问题是行为同样因平台而异有人觉得应该设计成处理期间别来烦我有人觉得应该允许重入。在实际编程中这些歧义会直接导致你的程序在A发行版上跑得好好的换到B发行版上信号处理函数执行到一半又来一个信号进程直接崩了。3.3 sigaction的完整打开方式字段与flags详解sigaction()是POSIX提供的、语义明确的接口#include signal.h struct sigaction { void (*sa_handler)(int); void (*sa_sigaction)(int, siginfo_t *, void *); sigset_t sa_mask; int sa_flags; void (*sa_restorer)(void); }; int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);逐个字段说sa_handler普通处理函数只接收信号编号。sa_sigaction如果sa_flags里有SA_SIGINFO用这个函数指针能拿到siginfo_t谁发的、为什么发、附加数据。两个字段是共享内存的联合体只能选一个用。sa_mask在处理函数执行期间额外阻塞的信号集。注意这里是在原有基础上追加阻塞不是替换。默认情况下触发当前处理的那个信号在执行期间会被自动阻塞防重入。sa_flags一堆开关常用的有几个——SA_RESTART让被信号打断的系统调用自动重启比如read()刚读到一半来信号了处理完了自动重新发起read。SA_SIGINFO使用sa_sigaction回调。SA_ONSTACK在备选信号栈上执行处理函数配合sigaltstack用对付栈溢出场景。SA_NOCLDWAIT针对SIGCHLD让子进程退出后直接不进入僵尸态。下面是一个标准的注册代码我写项目基本都是从这段开始抄的#include stdio.h #include signal.h #include string.h #include stdlib.h #include unistd.h static volatile sig_atomic_t g_flag 0; static void handle_term(int signo) { g_flag 1; } 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; if (sigaction(SIGTERM, sa, NULL) -1) { perror(sigaction); exit(EXIT_FAILURE); } while (!g_flag) { pause(); } printf(received SIGTERM, exiting gracefully\n); return 0; }3.4 volatile sig_atomic_t到底在防什么你看上面的代码我用了volatile sig_atomic_t。这两个修饰词拆开来说volatile告诉编译器这个变量可能在它看不到的地方被修改对它的读写不能优化掉不能缓存在寄存器里。从编译器视角看main()里的while循环和信号处理函数是两个独立的代码块它根本不知道处理函数会改g_flag如果不加volatile编译器可能把g_flag优化到一个寄存器里死循环永远跳不出来。sig_atomic_t这是一个保证原子读写的整数类型在几乎所有平台上就是int。信号处理函数里只能用保证原子操作的变量用普通int或者更复杂的结构体存在读到半截状态的风险。注意volatile sig_atomic_t只保证读写是原子的不保证先改标志再改数据的顺序。如果你的处理函数要置多个标志、传递多个值请老老实实用sigprocmask后面会讲或者sigwait别在异步上下文里搞复杂逻辑。4. 阻塞、未决与可靠信号被误解的排队问题信号会丢这事很多人第一次遇到都很懵。我教书和带人的时候至少被问了二十次SIGCHLD明明注册了处理函数为什么子进程退出了函数没跑十个里有八个最后排查下来都跟信号屏蔽字或者未决信号的合并有关。4.1 阻塞不是丢弃pending位图与信号屏蔽字每个进程有信号屏蔽字signal mask说明当前阻塞哪些信号。被阻塞的信号不是没了而是进了未决集合pending set——就是之前说的那个位图。流程是这样的信号产生内核检查当前屏蔽字如果没被阻塞就立刻递达执行处理函数或默认动作。如果被阻塞了就把信号登记在pending集合里一直等着。等到进程解除对该信号的阻塞比如调sigprocmask把它从屏蔽字里去掉信号马上递达。这里有个关键点pending是个位图一个信号最多占一位。如果信号$x$已经pending了又有新的信号$x$到达后面的信号就直接被丢弃了。这跟快递柜满了放不下不同更像是门牌号重复了后面来的那件快递直接不要了。4.2 为什么标准信号会丢实时信号不会这就是标准信号和实时信号的本质区别标准信号1-31每个信号对应一个位不排队。相同信号累积了多个也只算一个。实时信号32-64内核为每个进程维护一个信号队列每个实时信号都单独入队带的数据也会按到达顺序排列。对比维度标准信号实时信号编号范围1-3132-64排队机制位图不排队队列按FIFO排队携带数据不能带通过sigqueue携带递达顺序未定义编号从小到大同样信号多次产生合并为一个各算一个所以如果你需要每个事件都不丢必须用实时信号配合sigqueue。用标准信号做高频率事件通知本来就是设计上的错配。4.3 sigprocmask手动控制临界区挡住信号的侵入sigprocmask让你能在关键代码段里临时屏蔽信号防止异步打断干完了再解开#include signal.h int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);how有三种取值SIG_BLOCK把set里的信号追加到当前屏蔽字里简单的并集。SIG_UNBLOCK把set里的信号从当前屏蔽字里移除。SIG_SETMASK直接把当前屏蔽字设置为set。典型场景是更新共享数据结构时不希望信号处理函数插进来看到半成品sigset_t block_set, old_set; sigemptyset(block_set); sigaddset(block_set, SIGUSR1); sigprocmask(SIG_BLOCK, block_set, old_set); /* 这里放心地修改全局链表、写文件SIGUSR1不会打断 */ sigprocmask(SIG_SETMASK, old_set, NULL);最后那句SIG_SETMASK恢复很重要——不能野着把屏蔽字留在那里否则SIGUSR1就一直阻塞了。这里再补充一个小技巧解除阻塞之后pending的SIGUSR1会立刻递达如果你的处理函数还没准备好比如全局资源还没初始化完这个时序可能踩雷。稳妥的做法是初始化阶段保持屏蔽等一切就绪后再统一解锁。这个模式在写服务端程序时非常实用。5. 完整实战实现一个可优雅退出的信号驱动C服务讲了一堆原理不动手等于没学。下面我用一个真实场景把前面的知识点全部串起来写一个监听socket的服务进程收到SIGTERM时优雅退出——关闭监听、释放资源、保存状态而不是裸死。这个需求在几乎所有后台服务里都会出现。5.1 需求拆解为什么Naive的写法会出事先看一个反面教材。很多人会这么写static void on_term(int signo) { printf(got signal, exit now\n); exit(0); }这代码的问题在哪儿exit(0)会让进程直接走C运行时的收尾流程但此时你可能正握着锁、正写到一半文件、正有网络连接没关。强制exit并不会帮你做这些清理。尤其是多线程程序在信号处理函数里直接exit极易碰到线程A持锁等待线程B在exit里等待线程A退出的死锁。而我们期望的流程是收到SIGTERM后不再接受新的连接。关闭监听socket。通知正在工作的线程/子进程让它们处理完当前任务。等所有人退出后保存必要状态再整个进程exit。要实现这个流程信号处理函数里就不能做太重的活它应该只负责置一个标志位真正的清理逻辑放主循环里做。5.2 代码实现标志变量、屏蔽字与主循环协作下面这段代码是基于Linux单进程多路复用场景的完整示例#include stdio.h #include stdlib.h #include string.h #include signal.h #include unistd.h #include errno.h static volatile sig_atomic_t g_running 1; static volatile sig_atomic_t g_stop_requested 0; static void signal_handler(int signo) { if (signo SIGTERM || signo SIGINT) { g_stop_requested 1; } } static int setup_signals(void) { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler signal_handler; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART; if (sigaction(SIGTERM, sa, NULL) -1) return -1; if (sigaction(SIGINT, sa, NULL) -1) return -1; /* 忽略SIGPIPE避免写socket时被信号杀死 */ signal(SIGPIPE, SIG_IGN); return 0; } int main(void) { if (setup_signals() -1) { perror(setup_signals); return 1; } while (g_running) { /* 模拟主循环poll / epoll / select 都在这 */ struct timespec ts { .tv_sec 1, .tv_nsec 0 }; nanosleep(ts, NULL); if (g_stop_requested) { printf(stop requested, draining remaining tasks...\n); /* 这里可以做真正的清理关闭监听fd、保存状态、通知worker */ g_running 0; } } printf(service exited cleanly\n); return 0; }这段代码你可以直接编译跑。CtrlC发的是SIGINTkill发的是SIGTERM两个信号都会把g_stop_requested置1。主循环每次醒来检查标志一旦发现就进入清理流程。5.3 进程通信场景延伸父子进程的SIGCHLD与waitpid信号实战里另一个高频场景是管理子进程。父进程需要知道子进程什么时候退出——这就要处理SIGCHLD信号。常见写法static void handle_sigchld(int signo) { int saved_errno errno; while (waitpid(-1, NULL, WNOHANG) 0) ; errno saved_errno; }这里有两个细节循环waitpidSIGCHLD可能因为多个子进程同时退出而合并如果一个waitpid只回收一个子进程可能漏掉别的僵尸进程所以要用while循环配合WNOHANG回收所有可回收的。保存errno信号处理函数会破坏主流程的errno。处理函数里如果调了系统调用像waitpid、read这些会改写errno回到主代码后你的错误码就错了。标准做法进入函数先保存errno退出前恢复。5.4 进阶思考sigwait与signalfd比异步处理函数更稳的路径上面说的都是异步信号处理函数——处理代码和主逻辑并发执行限制多、容易出错。还有一个更可控的思路同步信号处理。思路很简单把信号屏蔽掉然后用专门的线程/主循环去sigwait()拿信号。信号不打断你的任何代码路径它就像消息队列里的一条消息你主动去取。这就不存在处理函数插到一半主逻辑的问题了所有共享数据都不用考虑异步竞争。sigset_t set; int signo; sigemptyset(set); sigaddset(set, SIGTERM); sigaddset(set, SIGINT); sigprocmask(SIG_BLOCK, set, NULL); /* 先把信号都挡住 */ while (1) { sigwait(set, signo); /* 阻塞等待信号 */ if (signo SIGTERM || signo SIGINT) { /* 这里是正常代码上下文想干什么干什么 */ cleanup_and_exit(); } }Linux下还有个更现代的选择signalfd()。它能创建一个fd把信号变成文件描述符上可读的事件直接塞进你的epoll/select循环里。这个方案在单线程事件驱动架构里尤其好用——你不用开专门的信号线程信号处理和网络事件统一走同一个事件循环业务代码完全同步化。比如我们团队在生产环境跑的一个网关程序就是signalfd epoll的组合把所有信号、网络IO、定时器统一管理代码清晰度提升了一个量级。如果项目允许依赖Linux特有接口我强烈推荐这个路线。6. 我这些年踩过的信号坑写下来给你避雷前面章节把机制讲得差不多了最后聊一点真正来自工程现场的教训每条都是真金白银堆出来的。第一信号处理函数里禁止调用printf、malloc、fprintf这些函数。printf内部涉及缓冲区操作和加锁malloc涉及堆管理这些函数不保证可重入。如果信号在主线程执行printf的时候插进来处理函数里再去printf可能直接死锁。我见过一个线上事故现象就是按下CtrlC程序卡死不动最后排查出来就是信号处理函数里的printf和主流程的printf抢同一个FILE锁。第二把SIGKILL和SIGSTOP不可捕获这件事记牢。SIGKILL连接到内核的强制终止路径SIGSTOP是强制暂停路径它们不经过用户态的处理函数任何捕获代码对它们都是无效的。kill -9杀不掉的进程只有一个可能——它处于不可中断的内核态等待D状态比如等磁盘IO这时候你只能等内核返回。第三多线程程序的信号管理跟你想象的不一样。默认情况下进程级信号会投递给任意一个未阻塞该信号的线程。你想让某个专门线程处理信号就得在其他所有线程里把这个信号屏蔽掉。用sigwait模式的同志请务必在创建其他线程之前就设好屏蔽字否则竞态会让你偶尔漏掉信号。第四EINTR问题虽然老生常谈但真的会坑你。传统系统调用read、write、accept在等待期间被信号打断可能返回-1并置errno为EINTR。SA_RESTART标志能解决大部分问题但注意某些系统调用比如poll、epoll_wait、nanosleep即使设置了SA_RESTART也可能不自动重启。所以代码里对这类调用看到EINTR就重试是个好习惯。第五alarm和settimer在信号处理里的重入问题。你没细看的话alarm到期触发处理函数处理函数里又调了alarm时间设置可能被自己打乱。定时器相关的信号逻辑先想清楚当前处理的是哪一次到期下一次到期是什么时候。有复杂定时需求的直接用POSIX timer别在alarm上硬扛。整套信号机制虽然从Unix诞生之初就存在但它的设计其实很精巧用好了能写出非常优雅的进程协同逻辑。我现在的习惯是能不用异步处理函数就不用优先sigwait或signalfd走同步的逻辑处理信号程序出问题的概率低很多。至于系统编程里其他难啃的骨头——文件IO、进程管理、线程并发——那是另一个长篇了有机会我们接着聊。