unix - 什么会导致自发的 EPIPE 错误而不结束调用 close() 或崩溃？

Question

我有一个应用程序，它由两个进程(我们称它们为 A 和 B)组成，它们通过 Unix 域套接字相互连接。大多数情况下它工作正常，但一些用户报告以下行为:

A 向 B 发送请求。这是有效的。 A 现在开始阅读 B 的回复。

B 向 A 发送回复。相应的 write() 调用返回 EPIPE 错误，结果 B 关闭套接字。但是，A 没有关闭()套接字，也没有崩溃。

A 的 read() 调用返回 0，表示文件结束。 A 认为 B 过早地关闭了连接。

用户还报告了这种行为的变化，例如:

A 向 B 发送请求。这部分工作，但在发送整个请求之前，A 的 write() 调用返回 EPIPE，结果 A close() 套接字。但是 B 没有关闭()套接字，也没有崩溃。

B 读取部分请求，然后突然得到一个 EOF。

问题是我根本无法在本地重现这种行为。我试过 OS X 和 Linux。用户使用各种系统，主要是 OS X 和 Linux。

我已经尝试并考虑过的事情:

Double close() 错误(close() 在同一个文件描述符上被调用两次):可能不会导致 EBADF 错误，但我还没有看到它们。

增加最大文件描述符限制。一位用户报告说这对他有用，其余的人报告说它没有。

还有什么可能导致这样的行为？我肯定地知道 A 和 B 都没有过早地关闭()套接字，而且我肯定地知道它们都没有崩溃，因为 A 和 B 都能够报告错误。就好像内核出于某种原因突然决定从 socket 中拔出插头。

Answer 1

也许您可以按照以下内容尝试 strace:http://modperlbook.org/html/6-9-1-Detecting-Aborted-Connections.html

我假设您的问题与此处描述的问题有关:http://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable

不幸的是我有一个 similar problem我自己，但无法通过给定的建议修复它。然而，也许 SO_LINGER 的东西对你有用。