忽略sigpipe(sig_ign)后，触发该信号的系统调用（如write、send）立即失败并返回epipe错误，进程本身继续运行。
直接忽略 SIGPIPE 是最常用、最稳妥的排查起点，而不是等它崩了再翻日志。真正要查清进程为何收到 SIGPIPE，关键不在“信号本身”，而在“谁在往已断开的连接或管道里写数据”。
确认进程是否真因 SIGPIPE 终止
很多崩溃看似是 SIGPIPE，实则是其他原因。先验证：
- 用 kill -l $pid 或 cat /proc/$pid/status | grep SigCgt 查看进程当前是否已屏蔽 SIGPIPE（位图中对应 bit 是否为 0）
- 检查系统日志：dmesg | tail -20 看是否有 “pipe”、“broken”、“EPIPE” 相关记录
- 运行时加 strace -e trace=write,send,sendto,close -p $pid，观察最后一次 write/send 是否返回 -1 且 errno=32（EPIPE）
定位触发 SIGPIPE 的具体写操作
SIGPIPE 总发生在对端关闭后仍执行第二次写操作时。重点查：
pain-to-pip-package
下载
完整流程：Reddit 痛点扫描 → 聚类 → 构建 pip 可安装的 CLI 工具 → 推送到 GitHub。使用此模式已交付 5 款工具，经验证 343 条痛点。
- socket 层：是否在 recv() 返回 0（对端 FIN）或 connect() 失败后未检查就直接 send()
- 管道/子进程场景：是否用 pipe() + fork() 后，父进程未 close 读端，子进程退出后父进程继续 write()
- HTTP 客户端类逻辑：是否复用连接但没做 keep-alive 心跳，导致服务端超时关闭，客户端 unaware 下发下一次请求
快速验证与临时修复
不改代码也能快速判断是不是 SIGPIPE 导致退出：
- 启动前加：signal(SIGPIPE, SIG_IGN)（C/C++）或 import signal; signal.signal(signal.SIGPIPE, signal.SIG_IGN)（Python）
- Shell 启动时加：trap '' PIPE，然后运行程序，若不再崩溃，基本可锁定问题根源
- 若使用多线程（如 libevent/pthread），需确保 sigprocmask 或 pthread_sigmask 在主线程初始化时屏蔽 SIGPIPE，否则仅 main 中 signal() 不生效
长期健壮性必须做的两件事
忽略信号只是防崩，不能替代正确处理连接生命周期：
- 所有 write/send 调用后必须检查返回值：等于 0 表示对端关闭；小于 0 且 errno == EPIPE/ECONNRESET 表示连接异常；需主动 close socket 并清理资源
- 配合 SO_KEEPALIVE 或应用层心跳：避免长时间空闲连接被中间设备静默断开，等到发数据才暴露问题
