Linux 进程收到 SIGPIPE 时怎么避免网络服务直接退出

Linux 网络服务在客户端提前断开后继续写 socket，进程突然退出，通常不是“网络抖了一下”，而是写入触发了 SIGPIPE。这个信号的默认处置是终止进程。生产服务更稳妥的做法是：先关闭这次写入带来的信号终止路径，再把 EPIPE 当作连接已经失效的明确结果，完成清理和记录。

SIGPIPE 为什么会让网络服务直接退出

SIGPIPE 最初描述的是向没有读端的管道写入。在面向连接的 socket 上，对端关闭后继续写，也可能落入同一类语义。Linux 手册把它的默认动作列为终止进程，所以只看到服务“偶发退出”而没有应用层日志时，应先检查是否存在未处理的断连写入。

这里有两个容易混淆的结果：SIGPIPE 是异步信号，负责影响进程是否继续活着；EPIPE 是写入接口返回的错误，负责告诉调用方这次写已经失败。即使把 SIGPIPE 忽略，EPIPE 也不会消失。

先决定是全局忽略还是单次 send 关闭信号

如果服务所有 socket 写入都经过统一封装，可以在初始化阶段使用 sigaction 将 SIGPIPE 的处置设为 SIG_IGN。这会改变整个进程的信号处置，所有线程都受影响，适合服务边界清楚、不会依赖 SIGPIPE 默认语义的程序。

更窄的选择是给每次 send 传入 MSG_NOSIGNAL。它只作用于当前调用，不会把策略扩散到其他库或线程，适合大型进程、插件较多或只想改造网络发送路径的场景：

#include 
#include 

ssize_t send_frame(int fd, const void *buf, size_t len) {
    // 只禁止本次 send 触发 SIGPIPE，不改变整个进程的信号处置。
    ssize_t n = send(fd, buf, len, MSG_NOSIGNAL);
    if (n 

两种方案都不是“忽略错误”。前者扩大了影响范围，后者缩小了影响范围；真正的选择标准是调用边界是否可控，以及团队是否能保证每条写路径都检查失败返回。

把 EPIPE 当成连接生命周期事件处理

收到 EPIPE 后，不要在原 socket 上无条件重试。对端已经关闭时，继续发送只会重复失败，还可能让连接对象、发送队列和日志数量一起膨胀。常见处理顺序是：标记连接不可写，取消待发送数据，关闭或回收连接资源，再把断连原因写入可聚合的指标。

如果发送的是分片数据，还要区分“部分写入”和“完全失败”：返回正数表示已有数据被接受，不能简单地把剩余内容当成完整新消息重发；返回 -1 且 errno 为 EPIPE，才是本次写入没有继续完成的明确分支。

#include 
#include 

int write_response(int fd, const void *buf, size_t len) {
    // write 也可能因对端关闭而失败，必须检查返回值。
    ssize_t n = write(fd, buf, len);
    if (n = 0 && (size_t)n 

对非阻塞 socket，还要把 EAGAIN 与 EPIPE 分开：前者表示当前发送窗口暂时不可用，后者表示连接生命周期已经结束。两者共用一个“重试队列”会造成无意义重试。

上线前检查线程、子进程与发布边界

Linux 的信号处置是进程级属性，多线程程序中的所有线程共享某个信号的处置；但每个线程有自己的信号掩码。因此，单独阻塞某线程的 SIGPIPE，并不等价于把整个进程设置为忽略。服务初始化、线程创建和第三方库加载的先后关系要在设计中写清楚。

还应注意 fork 会继承信号处置和掩码，execve 会把已处理的信号恢复为默认处置，而被忽略的信号保持忽略。带 worker、热重载或子进程执行器的服务，不能只在父进程里改完就假设所有执行路径都一样。

• 统一发送封装：确认 send、sendmsg、write 等路径没有漏掉错误检查。
• 日志字段：至少区分 fd、连接标识、EPIPE、EAGAIN 和 ECONNRESET，避免把正常断连当成服务故障。
• 灰度验证：让客户端主动提前断开，确认 worker 存活、连接资源回收、指标可聚合。

常见问题

只设置 MSG_NOSIGNAL 后还需要处理 EPIPE 吗？

需要。它只阻止本次调用触发 SIGPIPE，Linux 仍会把写入失败报告为 EPIPE。

把 SIGPIPE 忽略后，所有网络错误都会变成 EPIPE 吗？

不会。连接重置、暂时不可写和参数错误仍有各自的 errno，不能用 EPIPE 代替全部网络错误判断。

write 和 send 应该统一处理吗？

可以统一错误策略，但 send 的 MSG_NOSIGNAL 是显式的单次选项；使用 write 时要依赖进程级处置或其他适合当前平台的信号策略。

为什么服务没有崩溃但响应仍然丢失？

屏蔽 SIGPIPE 只改变进程存活结果，不会恢复已经关闭的连接；应用仍需清理连接并决定是否向新的连接重新生成响应。