Question

我正在使用域套接字从另一个进程获取值，比如A从B获取值，它可以运行好几个月。但是最近，A在“发送”消息期间失败了，偶尔会出现“errno 111，连接被拒绝”的消息。

我检查了B域套接字绑定文件，它存在。我也在另一台机器上做了一些测试，也运行良好。那么，之前有没有人遇到过这个问题？任何人都可以找到一些可能在这种情况下可能出错的线索吗？非常感谢。

Answer 1

当我看到unix域套接字出现此错误时，通常是因为进程B没有运行，或者连接路径不匹配。（如果B死了，它会自动重启吗？B可能会在B已经死亡但尚未重启的情况下发生故障吗？）。另一种可能性：A的多个副本是否可能同时运行？如果B的尚未接受的连接队列已满，您可能会收到ECONNREFUSED错误。

我建议在strace下运行流程A和B，或者：

strace -o A.log A

或者，如果进程已在运行，

strace -o B.log -p <process-id-of-B>

此外，

netstat -na

将为您提供系统中存在的所有unix域套接字的状态。

Answer 2

考虑在/proc/<pid-B>/fd下查看并查看B是否用完了文件描述符。如果是这样，您有资源泄漏并需要清理。它应该不是UDP程序的问题，但有趣的事情已经知道。 lsof可能是另一种使用工具。

否则，您会得到其他人的合理建议 - netstat尤其应该提供帮助。

Answer 3

请记住，文件系统中的套接字在关闭它们的最后一个描述符时不会自动删除。试图在那时连接或发送将导致错误。服务器需要先删除文件系统中的套接字才能再次绑定。

Answer 4

进程B不再位于你的（可能是DGRAM）套接字的另一端 - 也许它已经死了，或关闭了文件句柄等。

如果接收端已经死亡，linux上的

sendto(2)将返回ECONNREFUSED以获取SOCK_DGRAM或SOCK_SEQPACKET unix域套接字。（SOCK_STREAM unix套接字不会这样做 - 它们将返回ENOTCONN。）