将stdin通过splice写入socket时偶现Broken pipe问题求助

在通过splice()将标准输入写入UNIX域socket时，客户端会小概率触发Broken pipe（EPIPE）错误，即便socket表面上处于打开状态。该错误的出现概率和系统负载等因素直接相关。

我一直搞不懂：按认知，EPIPE是向无监听的文件描述符写入时才会触发的错误，但这种间歇性出现的情况完全摸不着头绪。

已准备了最小复现案例，包含服务端代码（server.c）、客户端代码（client.c）及运行脚本。实际问题出在Go代码中，但通过C语言的复现案例验证了错误行为一致。

• 连接关闭的竞争条件：UNIX域socket的连接建立与关闭过程中可能存在竞争窗口。比如服务端处理连接时，因信号、资源不足等异常提前关闭了socket，但客户端此时还没感知到，仍在调用splice()写入。系统负载越高，进程调度延迟越大，这个竞争窗口被命中的概率就越高。
• splice()的特殊错误处理：splice()是零拷贝调用，它的错误触发逻辑和普通write()有区别。如果在splice()执行过程中，socket或管道的缓冲区状态突然变化（比如服务端意外关闭连接），就可能触发EPIPE——哪怕调用前检查socket状态是正常的。
• SO_LINGER选项的影响：如果服务端设置了SO_LINGER且linger时间为0，关闭socket时会直接丢弃未发送数据并重置连接，客户端写入时就会收到EPIPE。高负载下服务端处理不及时，更容易触发这种场景。
• 文件描述符管理疏漏：排查是否存在文件描述符被意外复用、误关闭的情况。比如服务端的连接fd被错误关闭，但客户端还持有该连接的引用，写入自然会触发EPIPE。

1. 在服务端和客户端加详细日志，记录socket的打开、关闭、splice()调用的时间点和返回值，定位错误发生时的上下文细节。
2. 检查服务端的连接处理逻辑：有没有未正确处理的错误分支导致连接提前关闭？比如accept()后没完成初始化就关了fd，或者处理过程中被信号中断直接退出。
3. 调整SO_LINGER选项：试试在服务端设置合理的linger时间（比如1秒），避免直接重置连接，看错误概率会不会降低。
4. 用普通read()+write()替换splice()测试：如果错误消失，说明问题和splice()的零拷贝机制相关，得进一步确认splice()的使用是否符合场景要求（比如源和目标fd的兼容性）。
5. 调整系统参数：高负载下内核socket缓冲区可能不足，试试调大net.core.wmem_max、net.core.rmem_max等参数，观察对错误概率的影响。

内容的提问来源于stack exchange，提问作者Runxi Yu