我正在使用域套接字从另一个进程获取值,比如从B中获取一个值给A。这个方法已经运行了几个月,但最近,A在向B发送“sendto”消息时偶尔失败,并显示“errno 111,连接被拒绝”的错误信息。
我检查了B的域套接字绑定文件,它存在。我还在另一台机器上进行了一些测试,也正常工作。所以,有人之前遇到过这个问题吗?有没有人能够提供一些线索,可能是什么原因导致了这种情况?非常感谢。
当我在使用unix域套接字时看到这个错误,通常是因为进程B没有运行,或者连接路径不匹配。(如果B死了,它会自动重启吗?是不是可能在B死了但还没有重新启动的情况下发生故障?)另一个可能性:是否有多个A副本同时运行?如果B的未接受连接队列已满,则可能会出现ECONNREFUSED错误。
我建议在以下两个进程A和B上运行strace
:
strace -o A.log A
或者,如果该进程已经在运行中,
strace -o B.log -p <process-id-of-B>
netstat -na
这个命令将会给你展示系统中所有UNIX域套接字的状态。
/proc/<pid-B>/fd
下的内容,看看B是否正在用尽文件描述符。如果是,那么您有一个资源泄漏问题,需要清理。对于UDP程序来说,这不应该是一个问题,但也有可能会出现奇怪的情况。另一个可用的工具是lsof
。
否则,您可以考虑其他人提供的合理建议 - 特别是netstat
应该会有所帮助。
进程B已不再位于您(可能是DGRAM)套接字的另一侧 - 可能已死亡,或关闭了文件句柄等。
在Linux上,对UNIX域套接字的SOCK_DGRAM或SOCK_SEQPACKET进行sendto(2)
调用,如果接收端已经停止,则会返回ECONNREFUSED。 (SOCK_STREAM UNIX套接字不会这样做 - 它们将返回ENOTCONN。)
netstat -nap
命令还会显示连接到这些套接字的进程。 - bstpierre