搞懂EINTR：Linux信号捕捉与慢系统调用实战

搞过Linux服务端开发的，基本都遇到过这么一幕：程序跑得好好的，一按Ctrl+C没反应，或者网络守护进程莫名其妙挂掉，查日志发现read()调用返回了-1，errno是EINTR。其实这背后就是Linux进程信号处理机制在起作用，而信号捕捉和中断这两个话题，恰恰是信号处理中最容易踩坑、也最值得搞透的部分。我整理了一下自己实际项目中处理这几个问题的经验，从信号捕捉的基本设计到慢系统调用的中断恢复，配合代码讲一遍。

这篇主要面向正在学Linux应用编程、以及写过一些信号处理代码但对行为细节不太确定的开发者。内容聚焦在信号捕捉的函数选型、内核如何处理信号与系统调用的冲突，以及几个高频问题的排查方法。如果能把这篇吃透，后面遇到daemon进程的优雅退出、自己的框架被信号“打乱”这类问题，思路会清晰很多。

1. 信号捕捉的整体设计思路：从“默认处理”到“自己接管”

1.1 信号从产生到处理的完整旅程

先过一遍信号的完整生命周期，这样才能理解我们“捕捉”的到底是哪个环节。一个信号从产生到交给进程处理，大致经历这么几步：首先是信号的产生，可能来自终端按键（Ctrl+C产生SIGINT、Ctrl+\产生SIGQUIT）、硬件异常（段错误产生SIGSEGV）、软件条件（alarm()定时超时产生SIGALRM），也可能是另一个进程用kill()或者我们自己在代码里调用raise()主动发出来的。

信号产生之后，内核会为它做两个记录动作：标记这个信号为“未决（pending）”，同时把它放到目标进程的信号队列里，但此刻信号不一定马上被处理。真正去执行信号处理逻辑的时机，发生在进程从内核态返回用户态的那一刻。这包括三种典型场景：系统调用或中断返回、进程被调度获得CPU继续运行时、以及从阻塞状态被唤醒时。也就是说，只要进程还在用户态跑普通代码，信号就会一直处于pending状态，直到下一次陷入内核再返回时才会被检查并处理。

这里有个容易误解的点：信号的“捕捉”发生在内核态切换到用户态这关键时刻。内核检查未决信号集合，如果发现某个信号没有被屏蔽，就会根据信号处置方式去执行相应的动作。处置方式如果不是“忽略”或“默认处理”，而是我们自己注册的信号处理函数，那进程就会先保存当前上下文，然后跳到用户态执行处理函数，处理完再恢复现场继续执行被打断的事情。

1.2 三种处理方式：忽略、默认、自定义

每个信号都有独立的处置方式，核心就是信号处理函数指针。Linux支持三类处理行为：默认处理（SIG_DFL）、忽略处理（SIG_IGN）和自定义处理函数。默认处理不是每个信号都一样，SIGINT会终止进程、SIGCHLD会被忽略、SIGSEGV会产生core dump、SIGSTOP会暂停进程，所以“默认”只是一组由内核预设好的行为模板。忽略处理则比较简单，即内核在检查到进程对该信号是SIG_IGN时，直接把pending标记清理掉，不做任何多余动作。

自定义处理函数是我们的工作重心。注册一个处理函数，本质上是告诉内核：当你准备处理信号SIGXXX时，不要直接终止进程或忽略，而是跳转到地址为handler()的代码去执行。处理函数执行完之后，如果没调用exit()或_exit()，控制权会回到之前被中断的位置继续执行。

1.3 自定义处理函数的执行上下文

需要注意的是，信号处理函数运行在这样一个特殊上下文里：它是异步执行的，可能发生在主程序执行到任意一条指令之时。这意味着处理函数里访问的全局变量，和主程序里的访问之间存在时序竞争。我在实际项目里处理这种竞争，用的是一个简单原则：处理函数里只做两件事——修改volatile sig_atomic_t类型的全局标志位，或者直接调用异步信号安全函数。其它操作，尤其像malloc()、printf()、std::cout这种库函数，都不要出现在处理函数里。

很多新手第一次写出的信号处理代码，习惯直接在handler里打印一句话来验证信号收到没有，这在简易demo里能跑通，但放到生产环境就是定时炸弹。因为printf内部会申请锁、调用write()，如果信号正好在主程序执行printf的过程里到达，而printf的内部锁又被主程序占着，处理函数里的printf会去抢同一把锁，于是自己卡死自己，这就是经典的死锁现场。

2. signal()与sigaction()：捕捉接口的选型实战

2.1 signal()的历史包袱

Linux提供的最简单注册接口是signal()，一个调用就能完成注册。它的原型是typedef void (*sighandler_t)(int); sighandler_t signal(int signum, sighandler_t handler);，注册时传信号编号和处理函数，注册成功后返回之前的处理方式。但signal()的真正问题不在参数，而在于不同Unix系统对它语义的差异。System V上signal()注册的处理函数在一次触发后会被重置为SIG_DFL，也就是说处理完一次，第二次信号来了又按默认行为终止进程了；BSD则在处理函数执行期间自动屏蔽当前信号，并且处理完不会被重置，行为更接近预期。

Linux的signal()实际采用的是BSD语义，这看起来还好，但问题在于不同平台的移植性不可控。另外signal()没有提供精细的flag控制，比如你想让某个被中断的系统调用自动恢复、想让子进程停止时不触发SIGCHLD通知，signal()都做不到。所以我在自己代码里几乎不用signal()，只把它当作教学里帮助理解概念的入口。

2.2 sigaction()的结构体与flags详解

生产级的信号注册，要用sigaction()。它的核心是struct sigaction结构体，成员包括处理函数指针sa_handler、备选处理方式sa_sigaction（配合SA_SIGINFO使用）、信号屏蔽集sa_mask、标志位sa_flags，以及一个保留字段sa_restorer。

sa_flags是精华所在，我实际用到最多的有三个：SA_RESTART用于让某些被信号中断的系统调用自动重启，避免每次都要判断EINTR；SA_SIGINFO声明使用三参数的sa_sigaction处理函数，可以拿到发送者PID、信号编号和更多附加信息；SA_NOCLDWAIT配合SIGCHLD使用，让子进程终止后不被僵尸化，也不需要手动wait。此外还有SA_ONSTACK、SA_NODEFER、SA_RESETHAND等，各有用途，但频率较低。

这里用一个实际模板做参考。正常注册SIGINT和SIGTERM，为后续优雅退出做准备：

c复制#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <unistd.h>

static volatile sig_atomic_t g_running = 1;

static void handle_term(int signo)
{
    // 只做标记，不做复杂事情
    g_running = 0;
}

static void set_signal_handler(int signo, void (*handler)(int))
{
    struct sigaction sa;
    memset(&sa, 0, sizeof(sa));
    sa.sa_handler = handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_RESTART;

    if (sigaction(signo, &sa, NULL) == -1) {
        perror("sigaction");
        exit(EXIT_FAILURE);
    }
}

int main(void)
{
    set_signal_handler(SIGINT, handle_term);
    set_signal_handler(SIGTERM, handle_term);

    while (g_running) {
        sleep(1);
    }

    printf("shutdown triggered by signal\n");
    return 0;
}

这段代码虽然简单，但代表了可工程化信号处理的最基本形态：处理函数轻量、注册时清空屏蔽集、设置SA_RESTART。实际我会在此基础上扩展，比如把所有需要处理的信号放进一个数组统一注册，下面第5节会提到这个封装思路。

2.3 处理函数执行期间的自动屏蔽

进程在处理一个信号的时候，如果同型号的第二个信号又来了，会怎么处理？如果用户没有在sa_mask里额外增加屏蔽信号，内核默认会在进入处理函数前，自动把当前正在处理的这个信号加入到进程的屏蔽字里。也就是说，在处理SIGINT的过程中再收到SIGINT，它不会被立即重入执行，而是变成pending状态，等当前处理函数退出后再次被递达。这个默认机制避免了绝大多数信号重入造成的资源竞争。

如果确实需要处理函数不屏蔽同型号信号，可以设置SA_NODEFER，但这就等于允许递归重入，我基本不这么干，除非有极其特殊的需求。与之配套的是SA_RESETHAND，设置后处理函数执行一次即被重置为SIG_DFL，这本质上是复刻System V的signal()行为，一般不推荐。

这里还要提醒一下，sa_mask里额外屏蔽的信号，只在处理函数执行期间生效，处理函数返回后，屏蔽集自动恢复原状。所以通过sa_mask临时屏蔽其他信号，是一个窗口期控制手段，不是永久性的。

3. 信号中断与慢系统调用：EINTR 的来龙去脉

3.1 什么是慢系统调用

信号处理的复杂度一大来源就是慢系统调用。所谓慢系统调用，是那些可能被阻塞很久、或者一直等待某种条件的系统调用。经典例子包括：read()从终端、管道、socket等慢设备读取数据时没有数据可读；write()在管道或socket缓冲区满时写不进去；pause()无限期等待信号；sleep()和nanosleep()等待超时；wait()等待子进程状态变化。

相反，像read()从普通文件读数据这种操作，通常瞬间完成，属于快系统调用，即使被信号中断了也会以ERESTARTSYS等方式由内核自动处理，用户态一般感知不到区别。慢系统调用则不同，因为它们可能会让进程睡眠很长一段时间，所以内核在收到信号后，会选择把它唤醒并让信号优先处理。

3.2 被中断的调用如何返回：EINTR

慢系统调用被信号中断后的具体行为，以read()等待终端输入为例来说。进程调用read()阻塞在等待队列里，此时一个SIGUSR1信号到达，内核把这个进程叫醒，先不返回read()的调用结果，而是保存当前上下文，切换到用户态执行SIGUSR1的处理函数。处理函数返回后，进程重新进入内核，发现刚才的read()还处于未完成状态，内核这时有两种选择：要么让read()自动重新开始整个等待过程，要么直接给read()返回一个错误。

Linux的默认策略是后者，read()会返回-1，并设置errno为EINTR，表示“被信号中断了”。这种设计逻辑上非常干净，因为调用者无法预知处理函数执行了多久、外部数据状态是否已经改变，所以把控制权交还给用户态程序，让开发者自己决定是继续重试还是放弃调用，反而更安全。这就是为什么很多网络程序写while循环处理EINTR的原因。

看一个实际演示程序。下面这段代码阻塞等待终端输入，如果此时发送信号给它，read()就会被打断：

c复制#include <stdio.h>
#include <errno.h>
#include <signal.h>
#include <string.h>
#include <unistd.h>

static void on_alarm(int signo)
{
    // 什么都不干，只是让信号发生一次
}

int main(void)
{
    signal(SIGALRM, on_alarm);
    alarm(3);  // 3秒后触发SIGALRM

    char buf[64];
    printf("blocking on read()...\n");
    ssize_t n = read(0, buf, sizeof(buf));

    if (n == -1 && errno == EINTR) {
        printf("read() interrupted by signal, errno = EINTR\n");
    } else if (n == -1) {
        printf("read() error: %s\n", strerror(errno));
    } else {
        printf("read %zd bytes\n", n);
    }
    return 0;
}

编译运行后，什么都不输入，等3秒alarm触发，就会看到read()返回-1且errno是EINTR。这个实验建议新手一定要亲手做一遍，因为它能帮助建立“信号会打断阻塞调用”的直观印象。我最早看文档时对EINTR的理解是模糊的，直到跑了这个demo，才真正明白内核在这一瞬间做了什么。

3.3 SA_RESTART：让内核帮你重启

被信号打断后，直接在调用处判断EINTR并重新发起调用，是一种办法。但每个阻塞调用处都写一遍循环，代码堆起来很难看。sigaction()的SA_RESTART标志，就是为了解决这个问题而生的。

设置了该标志后，内核在慢系统调用被信号中断时，不直接返回EINTR，而是自动重新发起该系统调用，用户态完全感知不到。比如read()被中断后，内核会把它重新放到等待队列里继续等待数据。这样我们的编程模式就从“每次处理EINTR”简化成“注册时加个标志位”。

但SA_RESTART不是万能的，它只覆盖部分系统调用。man手册里明确列出不受SA_RESTART影响的接口，比如sem_wait()、sem_timedwait()这类同步原语，poll()、select()、epoll_wait()、nanosleep()、pause()、clock_nanosleep()、recvmsg()的某些超时模式等。这些接口即使设置了SA_RESTART，也会照常返回EINTR。所以项目里如果线程代码用sem_wait()同步，又同时注册了信号处理函数，还是要保留EINTR判断逻辑，否则程序可能在某个隐蔽角落悄悄失败。

这也引出一个重要习惯：不要完全依赖SA_RESTART，关键的系统调用循环该判断EINTR还是要判断。以write()为例，它在慢设备上被信号中断后，返回的不是EINTR，而是已写入字节数（可能小于请求长度），这意味着你要基于写入字节数去重试剩余部分，不能简单判断负数。

3.4 信号到达的竞态窗口

还有一类问题常被归在信号中断范畴，其实本质是竞态条件。看这个场景：主程序先注册SIGUSR1处理函数，然后执行pause()等待信号。从注册完成到真正调用pause()之间，存在一个空窗期。如果信号恰好在这个窗口期内到达，处理函数执行完毕后，pause()还没被调用，于是进程继续执行pause()，但此时信号已经不再pending，于是进程永远睡过去。这类问题可以用sigsuspend()解决，它保证“解除屏蔽+等待信号”这两个操作原子完成。

c复制sigset_t set;
sigemptyset(&set);
sigprocmask(SIG_SETMASK, &set, &oldmask);   // 先解除对目标信号的屏蔽

sigsuspend(&oldmask);                        // 原子化等待信号
// ... 走到这里说明信号已递达且处理完成

正确姿势是先备份原屏蔽集，然后用sigsuspend()在原子操作中等待信号递达。高并发网络服务里，这种竞态处理得好不好，直接影响程序的可靠性。

4. 信号屏蔽字、未决信号与队列行为

4.1 屏蔽字与未决信号的关系

信号屏蔽字（signal mask）是进程级属性，表示当前有哪些信号被阻塞。阻塞不等于忽略，它只是推迟了信号的处理时机。被屏蔽的信号若在这期间到达，会被内核持续标记为未决状态，直到屏蔽被解除，才会被递达并触发处理逻辑。

这两个概念的区别很重要。我调试过一个看起来很奇怪的问题：程序里某个线程把SIGTERM加到了阻塞集里，主线程往它发送SIGTERM，结果进程一切正常。后来才想明白，发送SIGTERM只是把未决信号置位，不会真正执行终止，因为目标线程阻塞了它。信号是否立即产生效果，取决于接收者当时的屏蔽状态，而不是发送方的意图。

4.2 sigprocmask与sigpending的使用

一个完整使用屏蔽字和未决状态检查的例子：

c复制#include <stdio.h>
#include <signal.h>
#include <unistd.h>

static void on_int(int signo)
{
    printf("received SIGINT\n");
}

int main(void)
{
    struct sigaction sa;
    sa.sa_handler = on_int;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    sigaction(SIGINT, &sa, NULL);

    // 屏蔽SIGINT
    sigset_t block_set, old_set;
    sigemptyset(&block_set);
    sigaddset(&block_set, SIGINT);
    sigprocmask(SIG_BLOCK, &block_set, &old_set);

    printf("SIGINT is blocked, press Ctrl+C...\n");
    sleep(5);

    // 检查未决信号
    sigset_t pending_set;
    sigpending(&pending_set);
    if (sigismember(&pending_set, SIGINT)) {
        printf("SIGINT is pending\n");
    }

    // 解除屏蔽，让SIGINT递达
    sigprocmask(SIG_SETMASK, &old_set, NULL);
    printf("SIGINT unblocked, wait...\n");
    sleep(2);
    return 0;
}

这段代码演示了完整闭环：屏蔽信号、等待信号到达后置为pending、检查pending、解除屏蔽、触发处理函数。注意sigprocmask在单线程进程里使用没问题，多线程程序则应该使用pthread_sigmask，因为信号屏蔽字是线程级的属性。

4.3 标准信号不排队

Linux信号分成普通信号和实时信号两类。普通信号（1到31号）有一个非常大的坑：它们不排队。当一个信号已经处于pending状态时，如果同样型号的信号再次到达，内核会把重复信号合并，也就是只记录一个。这意味着发送方发10次SIGUSR1给进程，处理函数可能只被调用1次。这在多线程、多进程协作场景里极易带来“丢消息”的错觉。

如果需要排队特性，要使用实时信号，也就是SIGRTMIN到SIGRTMAX范围的信号。实时信号支持按发送顺序排队，每个信号都能被可靠递达，同时还支持通过sigqueue()带附加数据传给接收方。

实际项目里如果需要传递实时状态信息，结合SA_SIGINFO的sa_sigaction处理函数来读取si_value，是一个很成熟的做法。但实时信号数量有限，设计协议时要做好分配规划。

5. 常见问题与排查技巧实录

5.1 信号处理函数里调printf崩溃

症状：处理函数里加了一行printf()，信号一多程序就崩溃，而且崩溃位置飘忽不定，gdb堆栈时经常莫名卡在锁相关函数里。

原因：printf()不是异步信号安全函数。它内部要获取FILE锁，如果主程序此时恰好正在printf()的执行过程里持有锁，信号处理函数又尝试获取同一把锁，就造成死锁；更糟的是，处理函数里处理的堆状态可能和主程序不一致，导致各种内存破坏。

解决：处理函数里只调用write()这类异步信号安全函数，写全局标志位。如果需要记录更详细的信息，常用的套路是让处理函数只写一个结构体到预分配好的内存区域，主程序循环里去消费这些记录，把真正耗时的日志工作留给主程序。

5.2 高频信号丢失

症状：另一个进程高频向本进程发送SIGUSR1，期望每触发一次做一次业务处理，但实测处理函数执行次数远小于发送次数。

原因：标准信号不排队，同一信号在pending期间再次到达会被合并。尤其当处理函数本身耗时较长时，信号到达频率如果超过处理频率，丢失不可避免。

解决：高频可靠的业务通知应使用实时信号或直接改用eventfd、pipe等文件描述符通知机制。实时信号能排队，但内核队列长度也有限，不能无限堆积；文件描述符方式相对更可靠。我在实际项目里更倾向用eventfd配合epoll去做进程间高频通知，信号只负责“唤醒主循环”这种低频事件，职责分离，问题会少很多。

5.3 SA_RESTART“复活”了阻塞调用导致极端等待

症状：程序设置了SA_RESTART，但某个网络轮询却“卡死”了，发送信号后也没有按预期返回。

原因：poll()、select()、epoll_wait()不受SA_RESTART覆盖，它们被信号中断后照样返回EINTR。若设置SA_RESTART后没有保留EINTR分支，log里没有任何说明，看起来就像卡死。

解决：凡是使用poll、select、epoll_wait、nanosleep这类接口的地方，一律显式处理EINTR，不要期望SA_RESTART照顾它们。这个原则写死在团队编码规范里，能减少很多莫名其妙的“偶发卡顿”。

5.4 处理函数中的共享变量优化掉了

症状：主循环判断一个全局标志位来决定是否退出，信号处理函数修改了这个标志位，但实测进程不退出。

原因：编译器可能优化了对标志位的读取，把它缓存在寄存器里，导致每次循环都读到旧值。只要把标志位声明为volatile sig_atomic_t，问题就消失了。

这里再展开一点。sig_atomic_t是原子整型类型，保证对它的读写不被中断成两半，用于信号处理函数与主程序共享简单状态足够。如果共享的是复杂结构体或者需要多步操作才能一致的数据，光靠volatile不够，要么在处理函数里做严格受限的修改，要么用更多的同步手段。设计原则是：处理函数只做“置0”或“置1”这种简单赋值，复杂计算全部放主循环。

5.5 如何优雅地给程序收尾

我个人的做法是把下面这套注册思路封装成公共函数，所有daemon程序共用：统一数组列出需要处理的信号和对应处理函数；注册时设置SA_RESTART，按需添加sa_mask；主循环通过标志位退出，退出时统一做资源清理。

c复制typedef struct {
    int signo;
    void (*handler)(int);
} signal_entry_t;

int setup_signal_handlers(const signal_entry_t *entries, int n)
{
    for (int i = 0; i < n; i++) {
        struct sigaction sa;
        memset(&sa, 0, sizeof(sa));
        sa.sa_handler = entries[i].handler;
        sigemptyset(&sa.sa_mask);
        sa.sa_flags = SA_RESTART;

        if (sigaction(entries[i].signo, &sa, NULL) == -1) {
            return -1;
        }
    }
    return 0;
}

主程序里维护一个g_shutdown_fd或者g_running标志，SIGTERM/SIGINT处理函数统一把标志置0，主循环检测到后执行资源清理、通知工作线程退出、等待回收。这样每个信号的处理逻辑集中在一处，排查问题时只要看注册表和处理函数就够了。

最后分享一点实际体会

信号这套机制，单看每个API都简单，难点在于组合起来的时序关系。我在实际项目里最大的体会是：不要试图在信号处理函数里做“太多事情”，它更像一个“闹钟”，是用来通知主程序醒来干活的，而不是用来干活的。另外，任何使用阻塞接口的地方，问一句“信号能不能中断这里”，养成这个习惯，能帮你提前排除掉一大批线上才会暴露的间歇性问题。这篇文章里提到的几个示例，建议全部亲手跑一遍，尤其是EINTR那个实验，真正在终端里看到输出，和看文档理解，完全是两种感受。