你写了一个跑着的程序按下 CtrlC终端立刻蹦出^C程序应声退出。这个动作背后就是系统给进程发了一个SIGINT信号。很多人听说过 signal 和 SIGINT但真到自己动手捕获信号、做优雅退出时往往会踩进 printf 崩溃、信号丢失、处理函数不生效这些坑里。这篇文章就围绕signal与SIGINT展开从信号是怎么来的到怎么用代码接管它再到为什么很多老手推荐用sigaction替代signal最后给你一套可以直接抄的优雅退出模板。1. 信号是什么进程世界里的紧急通知1.1 信号的本质信号本质上是一条非常短的消息用来告诉进程有一件重要的事情发生了。它不携带复杂的数据只有一个编号以及一些额外的上下文信息比如哪个进程发来的。操作系统内核负责把信号投递给目标进程进程可以选择忽略、捕获并处理或者按默认方式处理。我把信号理解成电话铃电话铃一响你没法决定对方要说啥但你可以决定接起来听、不接、直接挂断。进程对信号也是这样SIG_IGN表示不接电话SIG_DFL表示按系统默认规则挂断自己写一个处理函数则相当于专门接起来听一听。信号和异常、中断不是一回事。硬件中断由内核处理进程通常感知不到异常是程序自己执行出错比如除零信号则既可以来自内核比如段错误也可以来自其他进程比如kill命令还可以来自终端比如 CtrlC。理解这个区分后面排查问题会省很多时间。1.2 信号的来源与生命周期信号从产生到被处理大致经历三个阶段产生、传递、处理。产生信号的源头主要有四类终端驱动程序用户按下 CtrlC 产生 SIGINT按下 CtrlZ 产生 SIGTSTP。软件条件比如定时器到期SIGALRM、子进程退出SIGCHLD、管道写端关闭SIGPIPE。硬件异常除零触发 SIGFPE访问非法内存触发 SIGSEGV。显式调用kill()系统调用或者命令行里的kill -2 PID。信号产生之后并不会立刻被进程接住它会先待在进程的 pending 信号队列里。如果当前进程正在执行一个优先级更高的操作或者信号被阻塞了就等一等。Linux 里进程描述符中有一个位图记录着哪些信号 pending信号实际被处理的时机是进程从内核态返回用户态前的那一瞬间。也就是说你的程序在用户态跑得正欢信号不会凭空打断你得等一个合适的切换点。1.3 SIGINT 是怎么产生的从键盘到内核的完整链路按下 CtrlC 的那一刻终端驱动就把这个输入解释为中断字符。终端处于 canonical 模式默认模式时驱动检测到INTR字符默认就是 CtrlC会清空当前输入行然后向前台进程组发送 SIGINT。这里有个容易忽略的概念SIGINT 不是发给某一个进程而是发给整个前台进程组。所以你在终端运行myapp再按 CtrlCmyapp 以及它同组的子进程都会收到 SIGINT。如果前台跑的是a | b这种管道命令管道两端都能收到。默认情况下收到 SIGINT 的进程会被终止。这个终止不是简单地退出而是内核在进程处理完信号后执行默认动作——结束进程并产生一条exit(code)记录。这也是为什么你不做任何处理CtrlC 就能把程序按死。提示kill -2 PID和 CtrlC 发的是同一个信号但前者是显式指定目标进程后者是由终端驱动向整个前台进程组广播。两者在处理方式上没有本质区别都属于 SIGINT。2. 第一个信号处理程序signal() 函数入门2.1 signal() 函数原型刚接触信号处理时signal()是最简单、最直接的入口。它的原型长这样#include signal.h typedef void (*sighandler_t)(int); sighandler_t signal(int signum, sighandler_t handler);第一个参数是信号编号比如SIGINT、SIGTERM第二个参数是处理函数指针返回void接收一个int参数就是信号编号本身。函数返回值是上一个处理函数的指针或者是SIG_ERR表示设置失败。调用signal(SIGINT, SIG_IGN)表示忽略这个信号signal(SIGINT, SIG_DFL)表示恢复默认行为。真正自定义时就传自己的函数名void on_sigint(int sig) { printf(catch signal %d\n, sig); }2.2 一个能停住的死循环程序直接看一个完整的例子。下面这个程序会进入死循环每秒打印一次计数按下 CtrlC 后它打印一行提示然后继续跑而不是退出。#include stdio.h #include signal.h #include unistd.h static int running 1; void on_sigint(int sig) { printf(Caught SIGINT [%d], keep going...\n, sig); } int main(void) { signal(SIGINT, on_sigint); int count 0; while (running) { printf(count %d\n, count); sleep(1); } return 0; }编译命令gcc -Wall -O2 sigint_demo.c -o sigint_demo运行后按 CtrlC你会看到进程没有退而是打印了一行Caught SIGINT ...继续打印计数。这个行为说明两件事第一你的处理函数确实被调用了第二处理完之后程序回到之前中断的位置继续执行。对初学者来说感受到信号处理函数是异步执行的这一点非常重要——它可能发生在主循环的任何一条语句之间。2.3 signal() 返回值与常见误用signal()的返回值经常被忽略但实际排查问题时很有用。你可以用返回值判断之前谁占了这个信号void (*old_handler)(int) signal(SIGINT, on_sigint); if (old_handler SIG_ERR) { perror(signal failed); }还有一类非常常见的误用在程序初始化时用signal(SIGINT, on_sigint)设置了一次但处理函数里没有重新设置。这在某些系统上会导致第二次按 CtrlC 时行为不一致。至于为什么下一节展开。3. 不按套路出牌signal() 的跨平台语义差异与隐患3.1 SysV 与 BSD同一个函数两种语义signal()最大的历史包袱是不同 Unix 系统对它的语义解释不同。在 System V 上信号处理函数执行完后该信号的处置方式会被重置为默认行为即SIG_DFL。也就是说第一次按 CtrlC 调用了你的处理函数第二次再按程序直接退出。在 BSD 上则不同signal() 安装的处理函数会一直生效不会自动重置。Linux 的signal()实际行为是兼容 BSD 的安装后不会自动重置。但这里的问题在于如果你写的代码将来要移植到别的 Unix 系统或者你手头的编译环境对 signal 的实现恰好是 SysV 风格那就会遇到第一次能捕获第二次直接死的诡异现象。为了避免这个不确定性最稳妥的做法是在处理函数开头重新调用一次signal(SIGINT, on_sigint)void on_sigint(int sig) { signal(SIGINT, on_sigint); // 重新安装兼容 SysV printf(Caught SIGINT\n); }但这样做又引入了新的隐患在进入 on_sigint 到重新安装 signal 之间存在一个时间窗口。如果这个窗口内第二次 CtrlC 来了进程会按默认行为直接终止。很多生产系统不让用 signal()这是原因之一。3.2 处理函数里调用 printf一场赌博前面的示例代码用了printf但严格来说在信号处理函数里调用printf是不安全的。原因在于信号处理函数是异步执行的它可能在代码的任何位置插入执行。举一个实际可能崩掉的场景主程序正在执行printf执行到一半比如已经往 stdio 缓冲区写了部分字节时SIGINT 来了处理函数里的printf再次进入 stdio访问同一个缓冲区。两个printf在同一个线程里交替执行但 stdio 的缓冲区状态不是原子的轻则输出乱序重则触发断言或段错误。同样的道理适用于malloc、free、fopen、strtok这类非可重入函数。它们在执行过程中可能修改全局状态信号一来打断再一进来内部数据结构可能已经不一致。3.3 可重入函数与 sig_atomic_t那处理函数里到底能干什么标准答案是调用 async-signal-safe 函数比如write、read、_exit、signal等如果只改标志位要用volatile sig_atomic_t修饰。volatile sig_atomic_t是个组合sig_atomic_t保证读写是原子的通常就是 intvolatile告诉编译器不要把这个变量优化到寄存器里每次使用都从内存读。这样主循环才能及时看到新值。volatile sig_atomic_t g_stop 0; void on_sigint(int sig) { g_stop 1; }注意g_stop只能是简单赋值不能做g_stop这种读改写操作即便它本身是 volatile。有些平台上不是一条指令可能被中断穿插语义就会出错。注意信号处理函数里最常见的合法操作就是设置标志位。所有复杂的清理工作都放到主循环里做不要在信号处理函数里做全套清理。4. 更稳妥的方案用 sigaction 接管信号4.1 sigaction 结构体既然signal()的语义在不同平台上飘忽不定现代推荐的做法是用sigaction()。它参数多但每个参数都有明确用途#include signal.h int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact);涉及两个结构体核心是struct sigaction { void (*sa_handler)(int); sigset_t sa_mask; int sa_flags; void (*sa_sigaction)(int, siginfo_t *, void *); };sa_handler处理函数指针和 signal() 里的 handler 一样。sa_sigaction如果sa_flags设置了SA_SIGINFO就使用这个扩展版本能收到发送方 PID、信号序号等更多信息。sa_mask在调用处理函数之前内核会额外阻塞这一组信号防止它们递归插入。sa_flags控制各种细粒度行为。使用前必须memset结构体否则未初始化的字段会带来随机行为。4.2 用 sigaction 重写 SIGINT 处理#include stdio.h #include string.h #include signal.h #include unistd.h volatile sig_atomic_t g_stop 0; void on_sigint(int sig) { g_stop 1; } void setup_signal_handler(void) { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler on_sigint; sigemptyset(sa.sa_mask); if (sigaction(SIGINT, sa, NULL) -1) { perror(sigaction); _exit(1); } } int main(void) { setup_signal_handler(); int count 0; while (!g_stop) { printf(count %d\n, count); sleep(1); } printf(cleaning up...\n); return 0; }这段代码与前面用signal()的版本相比行为是确定的处理函数一直有效不会自动重置处理期间 SIGINT 被自动阻塞不会递归触发主循环通过轮询g_stop实现优雅退出。4.3 sa_flags 里值得关注的几个选项SA_RESTART很多系统调用比如read、sleep、wait在进程收到信号后会被中断返回EINTR。设置SA_RESTART后内核会在信号处理函数返回后自动重启这些调用。不设置的话你的sleep可能提前结束read可能报错需要自己判断errno EINTR。SA_SIGINFO改用sa_sigaction可以获得siginfo_t里面有si_pid谁发来的、si_code什么原因等。SA_NOCLDSTOP只对SIGCHLD有用表示子进程停止不是退出时不通知父进程。我实际项目里的习惯是能用SA_RESTART就尽量用省掉一大堆EINTR判断。但有些场景你必须故意不设置比如你在实现超时控制希望read能被信号打断这时就不要设置它。提示sigaction的安装是一次性的不需要在函数里重复安装。这也是它优于signal()的重要一点。5. 实战写一个能优雅退出的命令行程序5.1 需求梳理下面的场景很典型你写了一个服务型程序不断监听事件或处理数据CtrlC 不能直接暴力终止它得先保存进度、关闭文件、释放资源再退出。用前面几节的知识可以做一个完整模板。需求列出来主循环持续处理任务第一次收到 SIGINT进入准备退出状态停止接受新任务第二次收到 SIGINT强制执行退出给用户一个想好了的机会退出前完成清理动作。5.2 代码实现#include stdio.h #include string.h #include signal.h #include unistd.h static volatile sig_atomic_t g_stop_requested 0; void on_sigint(int sig) { if (g_stop_requested 1) { // 第二次 CtrlC直接退出不再等待清理 _exit(130); // 128 SIGINT } g_stop_requested 1; } void setup_signal_handler(void) { struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler on_sigint; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART; if (sigaction(SIGINT, sa, NULL) -1) { perror(sigaction); _exit(1); } } void do_cleanup(void) { printf([cleanup] saving progress...\n); sleep(1); // 模拟写盘 printf([cleanup] closing files...\n); } int main(void) { setup_signal_handler(); printf(service started, press CtrlC to stop\n); int task_id 0; while (!g_stop_requested) { task_id; printf([task] processing task %d\n, task_id); sleep(2); } printf([main] stop requested, no new tasks will be accepted\n); do_cleanup(); printf([main] exiting\n); return 0; }5.3 验证步骤编译运行模拟场景gcc -Wall -O2 graceful_stop.c -o graceful_stop ./graceful_stop第一次按 CtrlC[task] processing task 1 ^C[main] stop requested, no new tasks will be accepted [cleanup] saving progress... [cleanup] closing files... [main] exiting程序并没有立刻退出而是走完了清理流程。第二次 CtrlC 场景需要改一改代码让第一次进入退出状态后程序还留在主循环里才能测得到。实际应用中如果你在清理阶段再按一次 CtrlC第二次信号会直接触发_exit(130)达到强杀效果。这个模式解决了一个很实际的问题用户第一次按键是请求停止第二次按键是确认强杀。很多优雅停机方案都是这个思路的变体。5.4 为什么退出码用 130退出码 130 是 bash 里约定俗成的程序被 SIGINT 终止标识。计算方式是 128 加信号编号SIGINT 编号是 2所以是 130。这样外部脚本可以通过退出码判断进程是不是被中断杀掉的而不是正常执行的return 0或exit(1)。顺手补充一个细节在主循环判断g_stop_requested时如果当前阻塞在sleep或read上可能不会立即返回。此时SA_RESTART会在处理函数返回后恢复阻塞调用程序看起来像卡住了其实不是它是在等阻塞调用自己结束。如果想让程序立刻响应就别设SA_RESTART并且在阻塞调用返回后判断errno EINTR。6. 常见问题与排查技巧实录6.1 为什么我按 CtrlC 程序直接死了最常见的原因有三类没调用signal或sigaction信号走默认行为你调用signal(SIGINT, SIG_DFL)显式恢复了默认行为程序在信号处理函数执行完之后又被重置了默认行为这在 SysV 语义的系统上容易出现尤其是在没重新设置 signal 的情况下。排查思路先用strace -e tracesignal或 gdb 在on_sigint上打断点确认处理函数到底有没有被调用。如果断点没命中说明信号根本没走到处理函数这一层如果命中了但程序还是退出再看是不是处理函数里调用了不安全函数并触发崩溃。6.2 处理函数里到底能不能打日志能但别用printf直接用write(2)写无缓冲的文件描述符这是异步信号安全函数#include unistd.h void on_sigint(int sig) { static const char msg[] got SIGINT\n; (void)sig; write(STDOUT_FILENO, msg, sizeof(msg) - 1); }write内部不依赖 stdio 缓冲区也不调用非可重入函数。日志量少时用write足够了。如果非要打完整日志我一般是在处理函数里设置标志位主循环里检测到标志位后再用常规方式写日志、做清理。6.3 信号处理函数和主循环的竞态标志位方案有一个隐含问题主循环检查g_stop_requested和后面执行逻辑之间信号可能刚刚到达程序又做了一步工作才退出。这在很多场景下可以接受因为 SIGINT 本身就无法保证精确到每条指令。更严格的控制需要阻塞信号让信号在临界区结束后才被递送。用sigprocmask()或后面的pthread_sigmask()配合sigsuspend()可以处理这种场景。不过对入门阶段来说volatile sig_atomic_t加主循环轮询已经是最常用的方案先把它完全理解透再进阶。6.4 多线程环境下收到 SIGINT多线程程序的信号处理是个大坑。信号虽然发给了进程但内核会把信号递送给任意一个未阻塞该信号的线程。你无法保证一定是主线程收到也无法保证处理函数在哪个线程里执行。稳妥做法是在main()中、创建任何线程之前用pthread_sigmask()阻塞SIGINT带上SA_RESTART的 sigaction 也要在此前配好然后单独用一个线程执行sigwait()或sigtimedwait()来同步获取信号再按业务逻辑响应。这样信号处理动作就变成了同步函数调用避免了异步打断的问题。6.5 SIGINT 与 SIGTERM 的差异很多人会把 SIGINT 和 SIGTERM 混在一起处理。区分一下SIGINT 通常是终端交互产生的语义是请求中断SIGTERM 是kill命令默认发送的信号语义是请求终止。服务型程序往往同时捕获这两个信号用同一套清理逻辑收尾但退出码可以不同SIGINT 对应 130SIGTERM 对应 143128 15。将它们分开处理日志里记录信号种类事后排查会方便很多。7. 关于 signal 与 SIGINT我最后想说的我在实际项目里用信号处理的次数不算少每次都会先想清楚一个问题这个信号来了我要不要给进程一个收拾东西走人的机会。如果只是个临时脚本signal(SIGINT, SIG_IGN)省事如果是持续运行的工程我就直接用sigaction加标志位配上第二信号强杀机制再多留一个日志出口。处理函数里永远只做最轻量的操作重活在主循环里干。这个思路不是我一开始就会的是踩过几次printf 崩在信号处理函数里、第二次 CtrlC 莫名退出的坑之后总结下来的。你写代码时不一定要立刻用上所有细节但至少记住一条进程真正能安全做的事远比你想象中少而你能让它安全做到的事只要安排合理也能远超你的预期。
