都说 C 语言网络编程是“一年入门五年踩坑”这话一点不假。最近帮一个老项目做压力测试日志里突然刷出一整屏的accept error: Interrupted system call紧接着客户端那边连接成功率直线下降。第一反应是“这不就是个 EINTR 吗重试一下就好”但真正追下去才发现多进程服务器里的 EINTR 远不是“捕获-重试”这么简单它牵扯到信号投递时机、进程组行为、子进程回收策略甚至还会和SIGCHLD、waitpid纠缠在一起形成一个连环坑。这篇文章就围绕多进程服务器里accept()被信号打断这件事把底层原理、处理方式、常见误区和排查手段一次讲透。无论是刚接触 socket 编程的初学者还是已经写了几年服务端逻辑但没细究过信号机制的开发者这篇文章应该都能给你一些新东西。1. 从一次压测事故说起accept 返回 -1 之后发生了什么1.1 事故现场的日志与现象先还原一下当时的情况。压测工具开了 200 个并发连接服务端是多进程模型一个主进程监听派生出 8 个子进程每个子进程都阻塞在accept()上等待新连接。压测刚开始几分钟程序日志里开始大量出现accept error: Interrupted system call初始判断是“偶发的小问题”毕竟教科书上写得清清楚楚信号打断系统调用时accept()会返回 -1errno被设为EINTR重试一次就行。所以当时改了一版代码遇到EINTR就continue。改完重新压测日志确实少了但没消失更麻烦的是连接建立的平均耗时从 2ms 涨到了 30ms97 分位的延迟惨不忍睹。这就有意思了重试逻辑明明加了为什么延迟反而变高了1.2 为什么“重试就好”解决不了多进程场景再深入排查才发现打断accept()的信号不是别的正是SIGCHLD。多进程服务器的子进程完成一个客户端请求后就会退出内核给父进程发送SIGCHLD信号而每个子进程自己也是一个“父进程”——当它的子进程如果有退出时同样会给它发信号。更关键的在于信号到达的时机。压测场景下请求高频发生子进程疯狂 fork、执行、退出SIGCHLD信号几乎是持续不断地产生。如果程序对信号的处理方式不对——比如在主循环里只做了accept()而没有正确回收子进程——那信号会反复打断accept()每次打断都强制执行一次信号处理函数、再返回用户态、再次重试accept()。这中间多出来的上下文切换和调度延迟直接反映在连接建立的耗时上。换句话说accept()返回EINTR只是表象真正的问题是信号处理机制设计得是否健康尤其在多进程环境下信号不是零星的而是像下雨一样密集的。处理 EINTR 的正确姿势绝不是在accept()那一个点上加循环而是要把整条信号链路理顺。2. EINTR 的底层机制慢系统调用为什么会被信号打断2.1 从“慢系统调用”的定义说起要理解EINTR必须先理解“慢系统调用slow system call”。这一概念出现在 POSIX 规范里指的是一类可能永久阻塞的系统调用比如读终端、读管道、等待 socket 连接。这类调用的共同特征是——它们没有明确的完成时间上限可能一直等下去。accept()在阻塞模式下就是典型的慢系统调用如果没有新连接进程会进入睡眠状态挂起在 socket 的等待队列上。注意这个“睡眠”不是忙等而是主动让出 CPU等条件满足后由内核唤醒。当一个信号比如SIGCHLD、SIGINT在进程阻塞于慢系统调用时到达内核的处理流程是这样的内核唤醒进程把信号递送到用户态。进程返回用户态先执行注册的信号处理函数。信号处理函数执行完毕后进程并不一定自动回到刚才的系统调用继续执行。对于被中断的系统调用内核会返回 -1并设置errno EINTR。一句话总结信号强制把进程从“内核态的系统调用”中拽出来先处理信号再决定系统调用是否继续。这个“决定”就是我们要手工处理的逻辑。2.2 内核里的 ERESTARTSYS一个用户态看不到的中间码很多人不知道EINTR只是用户态看到的最终结果。在那之前Linux 内核里还有一个过渡错误码——ERESTARTSYS。当系统调用被信号打断时内核并非直接提交EINTR而是先提交一个“是否重启该系统调用”的决策请求。系统调用返回ERESTARTSYS后内核信号处理逻辑会检查对应信号的处置方式如果信号处理函数是用sigaction()注册且指定了SA_RESTART标志内核在信号处理完毕后自动重新启动刚才被中断的系统调用。如果没有SA_RESTART则向用户态提交EINTR。这个细节有助于理解后面章节的SA_RESTART行为它并不是魔法而是内核在ERESTARTSYS层面做的自动重启。而 strace 工具也能直接看到这个中间态输出类似accept(3, {...}) ? ERESTARTSYS (To be restarted if SA_RESTART is set) --- SIGCHLD {si_signoSIGCHLD, si_pid1234} ---看到ERESTARTSYS时说明这个调用实际上是被信号打断过、但等待内核决定是否重启的。这是一个很关键的调试信息后面章节详述。2.3 为什么阻塞与非阻塞行为完全不一样EINTR主要是阻塞模式下的故事。对于非阻塞 socketaccept()在没有连接时直接返回EAGAIN或EWOULDBLOCK进程并没有睡眠所以不存在“被唤醒再打断”的过程。但这里有个边界情况值得注意如果非阻塞accept()在调用过程中恰巧有一个信号需要递送内核同样会先处理信号。此时该调用可能返回EINTR也可能返回EAGAIN取决于信号在系统调用内部哪个阶段到达。我在实际项目中就见过一种 bug有人写非阻塞accept()时只处理了EAGAIN忘了EINTR结果明明是高效的非阻塞模型却在某个时刻被一个信号反复打断连接积压。所以保险的做法是无论阻塞还是非阻塞errno EINTR都必须显式处理。非阻塞模型下EAGAIN表示“当前没有事件”而EINTR表示“刚才发生了信号”两者在语义上是不同的混为一谈会埋雷。3. 处理 EINTR 的核心代码逻辑重试的关键不在于“重试”3.1 教科书式重试代码真的够用吗先给出最常见的写法int accept_or_retry(int listen_fd) { int conn_fd; for (;;) { conn_fd accept(listen_fd, NULL, NULL); if (conn_fd 0) { return conn_fd; } if (errno EINTR) { continue; // 被信号打断重试 } if (errno EAGAIN || errno EWOULDBLOCK) { break; // 非阻塞模式下暂时没有连接 } // 其他错误例如 EMFILE、ENFILE perror(accept); return -1; } return -1; }这段代码看着没什么问题EINTR时重试其他错误退出。但放到多进程服务器里它至少有三个隐患。3.2 隐患一重试前不检查退出标志多进程服务中主进程通常需要响应退出信号比如SIGTERM、SIGINT做优雅关闭。一个常见的协作模式是信号处理函数里只置位一个全局标志主循环检查标志后退出。如果把EINTR当成普通情况直接continue就会出现一个经典问题管理员发送了停止命令进程却还坚挺地运行——因为每一次accept()被打断后代码都“聪明”地重试了而错过检查标志的机会。修正方式是重试前先检查全局退出标志int accept_or_retry(int listen_fd, volatile sig_atomic_t *stop_flag) { for (;;) { if (*stop_flag) { return -1; } int conn_fd accept(listen_fd, NULL, NULL); if (conn_fd 0) { return conn_fd; } if (errno EINTR) { continue; } if (errno EAGAIN || errno EWOULDBLOCK) { return -1; } return -1; } }volatile sig_atomic_t是信号处理函数与主循环之间最简单的协作方式它保证读写在单次机器指令内完成不会因为编译器优化或寄存器缓存导致主循环看不到信号处理函数里的更新。这个细节很重要因为 C 标准里普通全局变量在信号处理函数中修改、主流程读取其行为是未定义的。3.3 隐患二把其他致命错误也当成 EINTR 兜住accept()返回 -1 的错误码中EINTR之外还有一个非常折磨人的错误EMFILE进程文件描述符表已满和ENFILE系统文件描述符表已满。在连接密集的多进程服务器里如果子进程没有及时释放连接描述符或者线程模型中的某个环节泄漏了 fdEMFILE出现的频率并不低。有些代码图省事把 -1 统一当成“临时错误”写一个sleep(1)再重试结果把问题掩盖了fd 表爆满说明有资源泄漏重试只能临时缓解解决不了根本问题。正确做法是区分EINTR和资源类错误——前者重试无代价后者需要先处理资源问题。更隐蔽的坑在于EMFILE还有一个衍生效应当前进程没有可用 fd 时accept()会进入一个特殊行为——如果监听队列里有新连接到达内核会主动丢弃这个连接而不是继续阻塞等待。也就是说你永远等不到“下一个能成功 accept 的时机”因为新连接本身就被丢弃了。这种情况下重试再多次也没用必须先把泄漏的 fd 回收掉。3.4 隐患三信号处理函数的执行时间被算进重试延迟回到压测事故。日志里accept error少了但延迟变高原因在于信号处理函数本身执行了太长时间。当时排查发现项目里的SIGCHLD处理函数中竟然调用了system(rm -rf /tmp/xxx)——一个极端错误的写法但很多人确实会在 handler 里做“清理工作”。信号处理函数的执行是同步的它在进程返回用户态后、accept()重试之前执行。你在 handler 里耗时越多accept()被阻塞的时间就越长。规范里信号处理函数应当只做“异步信号安全”的操作最合理的通常是置标志位、写一个管道字节、或者直接调用_exit()。把业务逻辑放进去等于把信号中断变成一次同步的额外开销每一波信号都会放大。压测场景下SIGCHLD密集到达延迟自然爆炸。4. SA_RESTART 不是银弹能自动重启但自动不了全部4.1 sigaction 的正确写法很多人刚认识EINTR时听到“信号打断系统调用”的第一反应是那我给信号处理函数加上SA_RESTART标志内核自动重启accept()这不就彻底不用管 EINTR 了吗这个理解大方向没错但细节里全是坑。SA_RESTART的语义是对于支持自动重启的系统调用内核在信号处理后自动重跑一次用户态根本看不到 EINTR。而且它针对的是“注册信号处理函数那一个信号”对“当前进程正在执行的那个系统调用”的组合。正确写法#include signal.h #include string.h struct sigaction sa; memset(sa, 0, sizeof(sa)); sa.sa_handler handle_sigchld; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART; sigaction(SIGCHLD, sa, NULL);设置了SA_RESTART后阻塞中的accept()在SIGCHLD到达时会被内核自动重启——strace 里能看到ERESTARTSYS而不是返回EINTR。但问题在于不是所有系统调用都能享受这个待遇。4.2 哪些调用能重启哪些不能Linux 的signal(7)手册对可重启和不可重启的系统调用有明确区分。大致情况如下可自动重启SA_RESTART 生效不可自动重启无论是否设置 SA_RESTARTaccept()、read()、write()、recvfrom()等epoll_wait()、poll()、select()wait()、waitpid()nanosleep()、clock_nanosleep()sem_wait()等部分同步原语sem_timedwait()、mq_receive()等这一条非常关键。如果你用accept()SA_RESTART解决了一部分EINTR但主循环里还有epoll_wait()或者select()它们照样会被信号打断并返回EINTR。有些项目正是“accept 阶段没问题一接入事件循环就让连接事件丢失”因为有个别poll()返回值被当成无事件少做了一次重新注册。所以更稳健的架构认知是SA_RESTART可以开但它只是“减少一层 EINTR 干扰”的手段你的代码依然要做好“任何系统调用都可能返回 EINTR”的防御准备。不要因为它存在就放弃手工处理。实际项目中最安全的策略是两者都做在能开SA_RESTART的地方开核心循环里依然保留对EINTR的显式检查。4.3 终极武器让信号处理函数“少干活”说到底EINTR产生的前提是有信号递送给进程。如果一种设计能让信号处理函数做的事情尽可能少、执行尽可能快那么即使系统调用被频繁打断恢复成本也会很低。最常用的两种做法信号处理函数里只置位一个volatile sig_atomic_t标志或者往一个自写管道里写入一个字节。完全不注册信号处理函数使用signalfd()把信号转换为一个普通文件描述符上的可读事件交给事件循环统一处理。第二种做法是现代 Linux 服务端编程中比较推荐的方案它把信号处理和 IO 事件统一到一个模型里从根源上消除了“系统调用被信号打断”的问题——因为信号不再异步递送到用户态而是变成一个 fd 可读事件。代价是需要额外维护一个signalfd并且要屏蔽掉对应信号避免默认行为触发。5. 多进程服务器的连环坑SIGCHLD、waitpid、ECHILD5.1 子进程退出是一个持续不断的信号源多进程服务器的典型模型是父进程 fork 出一批子进程每个子进程循环接受并处理连接。当一个子进程完成一个请求后如果选择了“处理完一个连接就退出再让父进程重新拉起”的模式那么每一次连接处理完毕都会向父进程发送一个SIGCHLD。更隐蔽的是主进程和子进程的信号掩码是共享 fork 时的快照。如果不小心在 fork 之前设置了信号处理函数子进程里也会继承。这就可能导致一个“信号风暴”子进程的业务逻辑里也触发了某个信号自己打断自己的accept()。排查时要特别注意继承问题。5.2 waitpid 在信号处理函数内外的取舍SIGCHLD的默认行为是忽略但子进程退出后如果不waitpid()就会变成僵尸进程。所以多进程服务器的父进程必须负责回收子进程。常见写法有两种模式一信号处理函数内回收void handle_sigchld(int sig) { pid_t pid; int status; while ((pid waitpid(-1, status, WNOHANG)) 0) { /* 记录子进程 pid 和退出状态 */ } }模式二主循环里回收void handle_sigchld(int sig) { g_child_exited 1; } // 主循环里 if (g_child_exited) { while ((pid waitpid(-1, status, WNOHANG)) 0) {} g_child_exited 0; }这两种模式都没有错但混用会出事。比如 handler 里回收了一批子进程主循环里又因为误判标志执行了一次waitpid()结果返回 -1errno ECHILD——表示没有需要回收的子进程。如果代码没有预判ECHILD就会输出一条无意义的错误日志干扰排查。正确做法是二选一。如果追求极简推荐模式二信号 handler 只置位主循环检查标志后再收拾子进程。因为waitpid()本身也是一个可能被信号打断的系统调用你放在 handler 里调用时固然用WNOHANG避免了阻塞但主循环里再调用一次就可能因EINTR或ECHILD产生多余分支。流程越简单越不容易出错。5.3 僵尸进程与信号掩码的传染还有一个细节很容易被忽略fork 出来的子进程会继承父进程的信号处理设置和信号掩码。如果父进程自己注册了SIGCHLD的 handler子进程里也有这个 handler。假设子进程没有正确处理自己的子进程退出那么它的waitpid()同样会收到EINTR或返回ECHILD。实际经验多进程服务器中最好在 fork 之后、业务逻辑开始之前统一把无关信号的处理重置为默认或忽略。比如子进程通常只关心业务相关信号其他信号一律SIG_DFL或SIG_IGN。这样能有效减少“信号跨进程扩散”带来的连锁反应。5.4 SIGPIPE 与信号处理的边界多说一句。socket 编程里默认会有一个信号让新手崩溃——SIGPIPE。当你向一个已经关闭的对端write()时内核不会直接给你EPIPE错误码而是先给进程发送SIGPIPE默认行为是终止进程。多进程服务器里一个子进程因为客户端异常断开而被SIGPIPE杀死这个子进程的退出又会给父进程发送SIGCHLD然后SIGCHLD又可能打断父进程正在做的事情。所以规范做法是启动时设置signal(SIGPIPE, SIG_IGN);忽略SIGPIPE后write()到已关闭的连接会返回 -1 并设置errno EPIPE这就变成一个可以控制的普通错误。这个操作虽小但能避免大量莫名其妙的进程退出。6. 实际排查与验证手段怎么确认你的 EINTR 处理是健全的6.1 strace 是最直接的“照妖镜”排查信号与系统调用的关系strace 是首选工具。运行strace -f -e traceaccept,waitpid,rt_sigreturn -o trace.txt ./your_server然后去观察 trace 文件。正常情况下你可能会看到这样的输出accept(3, {sa_familyAF_INET, sin_porthtons(54321), ...}, [16]) 7 wait4(-1, 0x7ffd..., WNOHANG, NULL) 1234如果看到ERESTARTSYS标记说明系统调用被信号打断、内核正在判断是否重启如果用户态代码最终得到了EINTR那说明该信号没有设置SA_RESTART或者这个系统调用根本不支持自动重启accept(3, 0x..., 0x...) ? ERESTARTSYS (To be restarted if SA_RESTART is set) --- SIGCHLD {si_signoSIGCHLD, si_pid1234} ---这个信息量巨大你能直接看到是哪个信号打断了哪个系统调用进程 PID 是什么从而判断信号源是哪个子进程。strace -f会跟踪所有子进程所以配合-o保存到文件里逐行分析非常高效。6.2 用故障注入把 EINTR“打出来”验证代码如果线上 EINTR 很难复现可以主动制造一个“信号风暴”来验证处理逻辑。思路是写一个小程序定期给 target 进程发送两个信号一个用来打断系统调用比如SIGUSR1一个用来模拟业务退出比如SIGCHLD的替代。一种实用的测试脚本思路不断 fork 短命子进程让它们立即退出于是父进程会持续收到SIGCHLD。这相当于给服务端一个密集的 EINTR 压力。观察目标进程是否依然稳定接受连接、延迟是否增加、日志中是否出现非预期错误。如果处理逻辑健全连接不会闪断日志不会刷错如果存在 handler 执行过重或缺少重试等问题压测下会立刻暴露。6.3 儿时的“教训”一个微不足道的日志掩盖了整个事故最后说点个人经验。那次压测事故最终定位出来的根因不是我开头猜的“EINTR 重试不够”而是项目里的一段“微不足道”的日志代码信号处理函数里调用了一个库函数来打印子进程退出状态。这个库函数内部用到了非异步信号安全的机制比如内部锁信号密集到达时触发了重入问题导致进程卡死在一个信号处理函数的内部。这个“重入问题”是信号处理函数最常见的隐藏炸弹主流程可能正在调用同一个库函数信号打断了它handler 里又调用了这个库函数相当于同一把锁被同一个线程连续锁了两次——死锁就这样发生在信号处理函数内部而accept()永远等不到恢复。从此之后我的信号处理函数铁律是只置volatile sig_atomic_t标志。最多往自写管道写一个字节。不做格式化输出、不调用任何可能加锁的库函数、不调用malloc和free。这个规则看似保守但能挡住绝大多数诡异的“随机崩溃”。7. 现代服务端如何处理 EINTRsignalfd 与事件循环的统一7.1 signalfd 的思路如果不想处理“信号异步打断系统调用”这一整套机制Linux 提供一个更现代化的接口signalfd()。它把一个信号集转换成文件描述符然后挂到epoll里。信号到达时自动投递信号epoll 返回可读事件你从 signalfd 里读出一个结构化的信号描述符。这样信号处理和普通 IO 事件完全统一没有 EINTR 问题。用法大概如下#include sys/signalfd.h sigset_t mask; sigemptyset(mask); sigaddset(mask, SIGTERM); sigaddset(mask, SIGINT); sigprocmask(SIG_BLOCK, mask, NULL); // 阻塞这两个信号 int sfd signalfd(-1, mask, SFD_NONBLOCK); // 之后把 sfd 加入到 epoll 中注意用signalfd前必须先阻塞对应信号否则默认行为依然会触发。在这套模型下主循环只需要处理 epoll 事件不需要担心epoll_wait()本身被信号打断——因为信号已经被阻塞不再参与异步投递。7.2 信号屏蔽与 pselect 的原子性还有一个经典技巧pselect()/ppoll()。它们和select()/poll()的区别在于可以传入一个信号掩码调用期间先原子地把掩码设置到进程中等系统调用返回后再恢复。这在“我们需要保证某个信号不会在 select 等待期间打断阻塞”的场景下非常有用。它的价值在于“原子性”普通编程中“先屏蔽信号再检查条件再进入 select再恢复屏蔽”这几步无法保证不被打断而pselect()把这套操作合并成一次系统调用从机制上消除了检查与等待之间的竞态窗口。只是它支持的平台不如select()广项目里做跨平台时需要注意。7.3 到底该用哪套方案结合多进程服务器的实际情况我给出一套比较务实的选型建议场景推荐方案进程少、逻辑简单、追求可移植性sigaction SA_RESTART核心循环保留 EINTR 重试进程多、信号密集、需要集中管理sigprocmask 屏蔽信号 signalfd epoll有较复杂的退出协调逻辑信号 handler 只置标志主循环统一处理事件循环中同时使用 poll/select/epoll_wait一律显式处理 EINTR不依赖 SA_RESTART需要提醒的是signalfd是 Linux 特有的接口如果项目要跨 BSD 或 macOS还是得老老实实回到传统信号处理。另外signalfd在多线程模型下也需要配套pthread_sigmask做全进程信号屏蔽否则信号仍可能被其他线程处理掉。8. 一点经验谈最后两个容易踩的小坑第一个坑accept()返回 -1 时千万不要用printf(%s, strerror(errno))顺手记录。这么做本身没错但它会掩盖一个事实——如果日志里刷大量Interrupted system call说明系统调用正在被高频打断这是信号风暴的前兆。最好的做法是记录一个计数器统计单位时间内的 EINTR 次数治理信号源而不是压制日志。第二个坑判断EINTR时不要用errno EINTR一个条件走天下。有些代码把errno EAGAIN || errno EWOULDBLOCK和EINTR混在一个重试分支里这在非阻塞模式下会把“暂时无连接”和“被信号打断”混为一谈可能在连接空闲时疯狂空转。正确的语义是EAGAIN表示“现在没有资源等会儿通知我”而EINTR表示“刚才发生了一件事帮我重试”。两者分开处理代码意图才清晰。写网络服务的这些年我越来越觉得EINTR 本身不难难的是它背后的信号机制和多进程交互。真正稳健的服务端代码不是碰巧没遇到信号而是把信号当作一个“随时可能发生的正常事件”来设计。把这段逻辑理顺了accept()这个第一道门槛就算真正跨过去了。