多进程服务器里跑着几十个子进程父进程一个accept()阻塞在监听套接字上突然返回 -1errno一看是EINTR。这种画面凡是写过 C/Socket 服务的人多少都见过不是网络断了不是客户端没来而是某个信号恰好在这个节骨眼上把阻塞的系统调用打断了。处理不好轻则多写几行不痛不痒的重试代码重则在日志里刷出满屏假错误甚至让整个服务在信号风暴里反复空转。这篇东西会把EINTR的来龙去脉、多进程场景下哪些信号特别容易捣乱、以及我从实际项目里换来的处理经验和坑一次讲透。适合正在写多进程网络服务、或者被这类偶发-1困扰过的人参考看完你大概能少走很多弯路。1. 先搞清楚 EINTR 在系统调用层面的位置1.1 慢速系统调用与信号的中断机制EINTR全称 Interrupted system call中文常叫系统调用被信号中断。问题出在慢速系统调用这类阻塞型操作上。像accept()、read()、write()、wait()这类调用可能在很长一段时间内都处于阻塞状态等着某种条件满足。accept()等的是新连接到来read()等的是对端发送数据。当进程阻塞在这种调用里的时候信号到达了。内核不会默默等这个信号被处理它会立刻把当前正在阻塞的进程拉起来切换到用户态去执行信号处理函数。信号处理函数执行完返回时进程需要决定刚才那个阻塞的系统调用还要不要继续等下去。内核在这里给了一个非常关键的设计选择直接返回-1并把errno设成EINTR让应用层知道你刚才被信号打断了。这就是我们看到的那个错误的来历。从内核角度看accept()被信号打断并不是说监听套接字出了什么问题。连接队列还好好地在那边新连接也没丢等你重新调用accept()那个等着被接受的连接还是会立刻取出来。所以EINTR本质上不是套接字错误而是内核强制把控制权还给了你的应用代码。理解到这一步遇到EINTR时你至少不该慌更不该去 close 监听套接字。1.2 EINTR 存在的理由内核把控制权塞回给你有人会问为什么内核不直接把被打断的系统调用重新启动让进程继续阻塞就完了那样对写代码的人来说不是更省事吗答案在于如果内核直接重启了系统调用信号处理函数里设置的一些关键标志位你的业务代码可能永远没有机会及时响应。举个最常见的例子你用小工具给进程发一个SIGTERM信号处理函数里把全局变量g_stop 1;期望主循环跳出、程序优雅退出。如果此时主循环正阻塞在accept()上而内核又默默把这次accept()重启了主循环会继续阻塞在accept()里g_stop 1完全没人去看程序退不出去。你必须再发一个信号才可能把进程从阻塞里踢出来而且此时EINTR才能让主循环跑回检查g_stop的代码。所以EINTR其实是一次信号事件通知内核通过一个异常返回把控制权强行交回给应用层让你有机会检查信号处理函数设置的标志位、做必要的清理或者干脆退出。这个设计意图是理解后续所有处理方案的前提。你要是把它当成一个纯粹的错误那么所有的处理姿势都是错的。2. 多进程服务器里谁在打扰你的 accept()2.1 SIGCHLD子进程退出是最常见的元凶在多进程网络模型下父进程通常只干两件事调accept()接收新连接把连接分发给子进程处理或者父进程直接accept()之后fork()出一个子进程去处理。不管是哪种子进程在某个时间点都会退出。子进程一退出内核就会向父进程发送SIGCHLD信号。这个信号几乎是多进程服务里打断accept()的头号选手。假设父进程此刻正阻塞在accept()上等待新连接SIGCHLD到达后父进程被拉起来执行信号处理函数处理完返回时accept()就以EINTR收场。我之前维护过一个老项目父进程没有设置任何针对SIGCHLD的处理用的是默认行为。结果线上日志里隔几分钟就蹦出来一条accept: Interrupted system call排查了一番才确认根因就是偶尔有子进程异常退出SIGCHLD打断了父进程的accept()。所以如果你发现自己服务的日志里EINTR出现频率和子进程退出频率高度吻合基本可以锁定SIGCHLD是元凶。2.2 定时器、外部通知与 SIGPIPE 的连带反应除了SIGCHLD还有一帮潜在选手也会触发EINTR。比如用setitimer()或alarm()设置的定时信号SIGALRM到了时间点一样会把阻塞的accept()打断。再比如运维想要实现配置热加载给进程发SIGHUP或者架构上用一个SIGUSR1通知父进程重新拉起一批子进程这些信号全都能打断accept()。SIGPIPE的情况稍微绕一点。它通常和write()到对端已关闭的 socket 相关但一旦进程收到SIGPIPE默认行为是直接终止进程这样反而不会产生EINTR。如果你用了signal()或者sigaction()屏蔽了SIGPIPE又恰好这个信号在accept()阻塞期间到达——虽然少见但技术上同样可能触发中断。所以不要觉得我只关心连接处理不关心信号。这里有个容易忽略的点不只是业务信号会打断accept()任何一个没有被屏蔽的、到达该进程的信号在对应时刻阻塞的系统调用都会被打断。信号越多EINTR出现的概率就越高。设计多进程服务时一个很实用的原则是尽量收窄进程里活跃信号的种类能屏蔽的屏蔽掉能不注册处理函数的就别注册从源头上减少被中断的机会。2.3 多进程场景下的另一个盲点多个进程同时 accept父进程派生出多个子进程所有子进程同时阻塞在同一个监听套接字的accept()上这是经典的 pre-fork 模式。这个模式下EINTR发生得不比单accept()模型少因为任何一个子进程收到信号只影响它自己但关键是当一个连接到来时内核只会唤醒等待队列里的某一个进程。如果那个被唤醒的进程正在被信号打断没及时回来accept()内核可能会唤醒另一个进程这其实是内核的自动补偿。真正要注意的是EINTR在 pre-fork 模式下很可能叠加惊群现象让多个进程同时从accept()中醒来其中某些进程拿到EINTR另一些可能拿到连接。当信号频率较高时accept()会频繁产生EINTR导致部分连接接受延迟。所以很多框架后来引入了accept4()以及EPOLLEXCLUSIVE等方式目的就是减少这种无谓的竞争。不过对大多数场景来说只要accept()里正确做了重试性能影响是可以接受的。3. 处理 EINTR 的两条路自己重试 与 让内核重来3.1 应用层封装循环重试的标准写法最直接、可移植性最好的处理方式是在应用层把accept()包一层遇到EINTR就重试。这也是我会在几乎所有项目里采用的做法因为我吃过不求甚解的亏只看文档说SA_RESTART能自动重启accept()但没意识到SA_RESTART对某些系统调用不生效结果换个模块就踩坑。与其依赖内核的承诺不如自己在代码里把逻辑写死。标准写法长这样int accept_with_retry(int listen_fd, struct sockaddr *addr, socklen_t *addrlen) { int conn_fd; while (1) { conn_fd accept(listen_fd, addr, addrlen); if (conn_fd 0) { return conn_fd; // 成功拿到新连接 } if (errno EINTR) { // 被信号打断重新阻塞在 accept 上 continue; } if (errno EAGAIN || errno EWOULDBLOCK) { // 非阻塞模式下当前无新连接 return -1; } // 其余情况属于真正的错误比如 EMFILE、ENFILE、EBADF return -1; } }这段代码的核心逻辑只有一句errno EINTR就继续循环。我特意把EAGAIN和EWOULDBLOCK单独拎出来判断是因为很多人会用非阻塞模式加超时此时没有连接可接受是正常情况不能死循环重试。如果是阻塞模式EAGAIN基本不会出现但写上无害还能让函数更通用。这里有个技术细节值得注意先检查返回值再检查errno。errno是一个线程全局的概念虽然单线程或多线程下每线程有独立的errno但调用成功时它并不会清零。如果你先看了errno发现有EINTR再去检查返回值可能在异常逻辑里把一次成功的accept()误判成失败。标准做法永远是先判断返回值conn_fd 0再深入解读errno。3.2 sigaction 的 SA_RESTART到底能不能省心除了应用层重试内核也提供了自动重启的开关。在注册信号处理函数时通过sigaction()的sa_flags参数设置SA_RESTART告诉内核这个信号处理完如果中断了某些系统调用帮我自动把它们重启。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);设置之后被SIGCHLD打断的accept()不会返回EINTR内核会替你重新阻塞。看起来省心很多。但事情没那么简单。SA_RESTART的语义在 POSIX 里是可选的不同的系统调用、不同的操作系统上表现并不完全一致。在 Linux 上SA_RESTART对大部分线下场景是可靠的但有几个著名的例外poll()、select()、epoll_wait()这些多路复用调用即使带SA_RESTART也照样返回EINTR。这意味着如果你的主循环用的是epoll_wait()而不是accept()那SA_RESTART帮不上太多忙。对accept()本身来说Linux 上的SA_RESTART是生效的。但我会建议不要把宝全押在这一项上因为一旦你把代码迁移到别的平台或者将来改用epoll_wait()统一事件循环SA_RESTART的行为会变。最稳妥的组合是注册信号处理函数时设置SA_RESTART作为兜底同时accept()仍然保留重试逻辑。两者并存不会出问题如果SA_RESTART生效EINTR根本不会出现重试逻辑闲置如果SA_RESTART失效重试逻辑立刻接管。这种双保险的设计写代码时多花十秒钟线上能省好多事。3.3 两种方式怎么选一张表讲清对比维度应用层循环重试SA_RESTART 自动重启实现成本需要自己封装逻辑透明注册信号时加一个 flag 即可适用范围所有平台、所有系统调用只对部分系统调用生效可移植性一般对accept()的支持完全可控Linux 上支持但依赖平台实现对后续切换 epoll 的影响仍然适用对epoll_wait()无效风险点重试逻辑写错会导致死循环或误判如果信号处理里有全局状态的更新自动重启会掩盖某些状态变化我的建议主推必写作为补充不要依赖我个人实践下来的结论很简单应用层重试是通解SA_RESTART是优化项不能反过来。如果你是在一个还没落地的项目里设计网络层直接封装重试函数然后在信号注册处顺手写上SA_RESTART这就是最省心的组合。4. 线上排查 EINTR 的实操经验与翻车现场4.1 把 EINTR 当成错误打日志日志直接爆炸我见过最典型的翻车现场是把EINTR当作严重网络错误打日志而且没有做频率限制。正常情况下EINTR在业务量大的服务器里并不罕见尤其是使用定时器信号配合短连接时几分钟内就能积累成百上千条。日志系统本身又会产生磁盘 I/OI/O 又触发调度信号再打断更多的系统调用形成恶性循环。整个服务 CPU 和磁盘都会被日志拖垮真正的异常信息反而被海量假错误淹没。正确的处理思路是EINTR不应该出现在 ERROR 级别的日志里最多在 DEBUG 粒度下记录而且必须带计数、限制采样频率。我实际项目里的做法是用一个单调递增的计数器统计EINTR次数只有在一段时间内次数异常增长时才打一条 WARN。这个计数的增长趋势本身反而能帮你判断是不是有信号频率异常的问题。4.2 信号处理函数里碰了不安全的库函数信号处理函数的限制经常被忽视。它只被允许调用异步信号安全函数async-signal-safe比如write()、read()、_exit()这类。像printf()、malloc()、free()、pthread_*这类内部存在锁或者共享状态的库函数在信号处理函数里调用是有风险的。如果信号打断的恰好是一次malloc()内部操作那么信号处理函数里再次调用malloc()就可能造成死锁或堆内存结构损坏。我早年踩过一次坑在 SIGCHLD 处理函数里为了调试直接用了printf()去打印子进程 PID 和状态。结果服务在高并发下频繁卡死压测怎么都过不去后来用 gdb 挂上去才发现是卡在 printf 内部的锁上。EINTR本身不会杀进程但你在信号处理函数里做危险操作会让整个进程陷入更麻烦的局面。信号处理函数里最安全的动作只有两个给一个volatile sig_atomic_t标志位赋值或者调用write()写一小段纯文本到日志 fd。4.3 errno 判断的经典误用不检查返回值只看 errno一个很普遍的错误写法是调用accept()之后没有先判断返回值直接去看errno EINTR。这种逻辑在错乱时会出现两个问题。第一errno在成功时不会清空可能残留上一次调用的旧值导致误判。第二信号处理函数里如果再调用任何会改变errno的库函数比如write()errno可能早就被覆盖了。所以嵌在信号打断的上下文里时errno的可靠性就更加依赖先判返回值再查 errno这个顺序。我建议在封装函数里把errno暂存到局部变量int conn_fd accept_with_retry(listen_fd, addr, addrlen); if (conn_fd 0) { int err errno; // 此时 err 才是你该用来判断错误类型的值 }这里还有一个容易被忽略的细节EINTR和部分临时性错误如ENETDOWN、EPROTO、ENOPROTOOPT、EHOSTDOWN、ENONET、EHOSTUNREACH、EOPNOTSUPP、ENETUNREACH在有些系统上如果SA_RESTART没有生效accept()返回EINTR后重试即可其它错误种类则不该盲目重试否则可能在同一个真实错误上死循环。封装函数里分类判断就是这个原因。4.4 一套可复用的 accept_with_retry 封装建议封装不要只做遇 EINTR 就 continue这么简单。项目里对内存、文件描述符上限也要有预判。accept()在文件描述符耗尽时会返回EMFILE如果这时候你用遇 EINTR 就 continue的思路去处理EMFILE那就麻烦了——每次循环都会立刻返回EMFILE忙循环空转CPU 被打满。所以一个工程上完整的封装里至少要对EMFILE、ENFILE做特殊处理通常做法是短时休眠或等待一小段时间后重试而不是立即重试。虽然这属于文件描述符层面的问题但它和EINTR往往同时出现在accept()的返回判断里不处理好就会出现前面说的每次重试都失败的情况。下面是一个稍微完整一点的版本int accept_with_backoff(int listen_fd, struct sockaddr *addr, socklen_t *addrlen) { for (;;) { int conn_fd accept(listen_fd, addr, addrlen); if (conn_fd 0) return conn_fd; if (errno EINTR) { continue; } if (errno EAGAIN || errno EWOULDBLOCK) { return -1; // 非阻塞模式无连接可接受 } if (errno EMFILE || errno ENFILE) { // fd 耗尽短暂休眠后再试 struct timespec ts {0, 100 * 1000 * 1000}; // 100ms nanosleep(ts, NULL); continue; } return -1; // 其他错误一律认为是致命的 } }这个封装的优点是把EINTR、EAGAIN、资源耗尽三种情况分开处理每一类都有自己的策略。后面在实际项目里基本上只需要一行替代原来的accept()调用整条主循环就都安全了。5. 更现代的思路绕开 EINTR把信号变成事件5.1 经典解法SIGCHLD waitpid 的正确回收姿势多进程服务里父进程如果不回收子进程就会积累僵尸进程。SIGCHLD处理函数里应该调用waitpid()把所有退出的子进程收干净用循环配合WNOHANGvoid handle_sigchld(int sig) { int saved_errno errno; while (waitpid(-1, NULL, WNOHANG) 0) { // 循环回收直到没有可回收的子进程 } errno saved_errno; }waitpid()在SIGCHLD处理函数里是异步信号安全的可以放心用。这里还有个容易被忽视的心机如果主逻辑里在同一时刻也在调用waitpid()或者其他会改变errno的函数信号处理函数执行完可能顺手把errno改掉了那样accept()返回错误时查到的errno就可能是假象。所以很多经典代码里第一步int saved_errno errno;存下来最后再errno saved_errno;恢复就是这个道理。这也是信号处理函数里最需要养成的好习惯。5.2 signalfd让 epoll 管理信号主循环不再被打断到了高并发阶段越来越多的服务采用epoll事件循环主循环里根本不再直接阻塞在accept()上而是用epoll_wait()同时监听监听 socket、连接 socket 以及其他 fd。前面说过epoll_wait()在SA_RESTART下照样会返回EINTR所以如果你已经迁到事件循环也应该在epoll_wait()那里做重试。更彻底的办法是把信号也变成一个 fd。Linux 提供了signalfd()你可以把感兴趣的信号比如SIGCHLD、SIGTERM都塞进一个 fd 里然后用epoll统一监听。信号到达时epoll_wait()会正常返回read()这个signalfd拿到信号信息完全不需要打断任何阻塞调用也不需要处理EINTR。这种设计在多进程高并发服务里能显著降低信号对主循环的干扰。sigset_t mask; sigemptyset(mask); sigaddset(mask, SIGCHLD); sigaddset(mask, SIGTERM); sigprocmask(SIG_BLOCK, mask, NULL); // 屏蔽信号不让它们打断系统调用 int sfd signalfd(-1, mask, SFD_NONBLOCK | SFD_CLOEXEC); // 把 sfd 加入 epoll统一事件循环这个方案的核心逻辑是与其被信号打断再重试不如先屏蔽信号让它们在信号 fd 上排队等到事件循环主动去读取。主循环里只有事件没有意外的EINTR代码逻辑清晰很多。代价是需要额外处理signalfd这个 fd而且它只在 Linux 上可用。如果你的项目要在多平台跑self-pipe trick自管道技巧是更通用的方案即用一个管道把信号处理函数变成向管道里写一个字节事件循环监听管道读端的 fd。5.3 方法论总结EINTR 不可怕可怕的是每次都临时处理从老式的阻塞accept()到后来的epoll事件循环再到signalfdEINTR的处理方式不断演变但底层逻辑一直没变你要回答一个问题——信号打断后程序下一步该怎么办是重试系统调用还是先去检查标志位还是干脆退出我的经验是这个问题应该在设计网络层的第一天就给出答案而不是等线上冒出问题再来补。方案就两种取向一种是在每个阻塞调用点都做EINTR重试简单粗暴、通用另一种是把信号屏蔽掉统一走事件循环更现代、更可控。两种并不互斥封装一个带重试的accept()再配一个事件循环可以让整个服务面对信号时始终处于可控状态。从最开始把EINTR当成一个讨厌的干扰项到后来理解它是信号机制给应用层的通知机会——这个过程其实是网络编程经验提升的标志之一。我自己的习惯是无论SA_RESTART是否设置都写重试逻辑信号处理函数只做标记不碰任何复杂库函数能用signalfd的地方一定用signalfd让信号从打断者变成事件源。这套组合拳打下来EINTR就不再是坑而是多进程服务器里一个可以预期、可以驾驭的常规现象。最后再分享一个小技巧在项目里做一个统一的accept_with_retry()工具函数全部入口都走这一个封装以后不管是排查日志还是调整重试策略都只需要改一个地方比到处散落着if (errno EINTR)舒服太多了。