我试图找出哪个进程正在持有 unix 域套接字的另一端。在一些strace
输出 我已经识别出一个给定的文件描述符,该文件描述符涉及我当前正在调试的问题,并且我想知道哪个进程位于该描述符的另一端。由于该套接字有多个连接,因此仅通过路径名是行不通的。
lsof
为我提供以下信息:
dbus-daem 4175 mvg 10u unix 0xffff8803e256d9c0 0t0 12828 @/tmp/dbus-LyGToFzlcG
所以我知道一些地址(“内核地址”?),我知道一些套接字号,并且我知道路径。我可以在其他地方找到相同的信息:
$ netstat -n | grep 12828
unix 3 [ ] STREAM CONNECTED 12828 @/tmp/dbus-LyGToFzlcG
$ grep -E '12828|ffff8803e256d9c0' /proc/net/unix
ffff8803e256d9c0: 00000003 00000000 00000000 0001 03 12828 @/tmp/dbus-LyGToFzlcG
$ ls -l /proc/*/fd/* 2>/dev/null | grep 12828
lrwx------ 1 mvg users 64 10. Aug 09:08 /proc/4175/fd/10 -> socket:[12828]
然而,这些都没有告诉我什么other我的套接字连接结束了。我如何知道哪个进程正在持有另一端?
类似的问题已被问到服务器故障 https://serverfault.com/q/252723/129921 and Unix 和 Linux https://unix.stackexchange.com/q/16300/20807。公认的答案是 Linux 上的用户空间无法可靠地获得此信息。
一个常见的建议是查看相邻的套接字编号,但是ls -l /proc/*/fd/* 2>/dev/null | grep 1282[79]
这里没有给出结果。也许输出中的相邻行netstat
可以使用。似乎存在一种带有或不带有关联套接字名称的连接模式。但我想要某种确定性,而不仅仅是猜测。
一个答案 https://unix.stackexchange.com/a/16447/20807建议使用一种工具,它似乎能够通过挖掘内核结构来解决这个问题。使用该选项需要内核的调试信息,由CONFIG_DEBUG_INFO
选项并由某些发行版作为单独的包提供。根据该答案,使用提供的地址lsof
,以下解决方案对我有用:
# gdb /usr/src/linux/vmlinux /proc/kcore
(gdb) p ((struct unix_sock*)0xffff8803e256d9c0)->peer
这将打印连接另一端的地址。格雷平lsof -U
对于该编号将提供进程 ID 和文件描述符编号等详细信息。
如果调试信息不可用,则might通过了解对等成员在 unix_sock 结构中的偏移量,可以访问所需的信息。就我而言,在 x86_64 的 Linux 3.5.0 上,可以使用以下代码来计算相同的地址,而无需依赖调试符号:
(gdb) p ((void**)0xffff8803e256d9c0)[0x52]
我不会对该解决方案的可移植性做出任何保证。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)