如何findunix套接字连接的另一端？

最近我偶然发现了一个类似的问题。 我很震惊地发现，有些情况下这是不可能的。 我从lsof（Vic Abell）的创build者那里得到了一个评论，他指出这很大程度上取决于unix套接字的实现。 有时，所谓的“端点”信息是可用的，有时候不是。 不幸的是，在Linux中是不可能的，正如他指出的那样。

在Linux上，例如，lsof必须使用/ proc / net / unix，所有UNIX域套接字都有一个绑定path，但没有端点信息。 通常没有约束的path。 这经常使得不可能确定另一个端点，但这是Linux / proc文件系统实现的结果。

如果你看看/ proc / net / unix，你可以亲眼看到，至less在我的系统上，他绝对是对​​的。 我仍然感到震惊，因为在追踪服务器问题时，我发现这样的function至关重要。

这个答案只适用于Linux。 根据Unix＆Linux Stack Exchange 的回答 ，我使用gdb和/proc/kcore访问，使用内核数据结构成功地确定了unix域套接字的另一端。 您需要启用CONFIG_DEBUG_INFO和CONFIG_PROC_KCORE内核选项。

您可以使用lsof来获取套接字的内核地址，该地址采用指针的forms，例如0xffff8803e256d9c0 。 这个数字实际上是相关的内核内存结构或typesstruct unix_sock 。 该结构有一个叫做peer的字段，指向socket的另一端。 所以命令

 # gdb /usr/src/linux/vmlinux /proc/kcore (gdb) p ((struct unix_sock*)0xffff8803e256d9c0)->peer 

将打印连接另一端的地址。 你可以grep输出lsof -U这个数字来标识另一端的进程和文件描述符号。

一些发行版似乎提供了内核debugging符号作为一个单独的包，这将取代上述命令中的vmlinux文件。

Unix套接字通常是成对分配的，通​​常是连续的。 所以这对你可能会是1013410 +/- 1。 看看其中哪一个存在，并猜测罪魁祸首。

其实，从iproute2 （更换netstat，ifconfig等） ss可以显示此信息。

以下是一个显示ssh进程连接的ssh-agent unix域套接字的例子：

 $ sudo ss -a --unix -p Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port u_str ESTAB 0 0 /tmp/ssh-XxnMh2MdLBxo/agent.27402 651026 * 651642 users:(("ssh-agent",pid=27403,fd=4) u_str ESTAB 0 0 * 651642 * 651026 users:(("ssh",pid=2019,fd=4)) 

我写了一个工具 ，使用MvG的gdb方法来可靠地获取套接字对等信息，不需要内核debugging符号。

要使进程连接到给定的套接字，请将inode号传递给它：

 # socket_peer 1013410 3703 thunderbird 

要一次性查找所有进程，请使用netstat_unix ，它将一列添加到netstat的输出中：

 # netstat_unix Proto RefCnt Flags Type State I-Node PID/Program name Peer PID/Program name Path unix 3 [ ] STREAM CONNECTED 6825 982/Xorg 1497/compiz /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 6824 1497/compiz 982/Xorg unix 3 [ ] SEQPACKET CONNECTED 207142 3770/chromium-brows 17783/UMA-Session-R unix 3 [ ] STREAM CONNECTED 204903 1523/pulseaudio 3703/thunderbird unix 3 [ ] STREAM CONNECTED 204902 3703/thunderbird 1523/pulseaudio unix 3 [ ] STREAM CONNECTED 204666 1523/pulseaudio 3703/thunderbird ... 

尝试netstat_unix --dump如果你需要输出，很容易parsing。
有关详细信息，请参阅https://github.com/lemonsqueeze/unix_sockets_peers 。

有关信息， inode + 1 / -1 hack是不可靠的。 它大部分时间都有效，但如果运气不好，会失败或（更糟糕）返回错误的套接字。

编辑你的system.conf

在这个文件中，你可以添加更多的东西进行debugging。

文件位置： /etc/dbus-1/system.conf

出于debugging的目的，你可以编辑你的system.conf来允许窃听：

1. 用以下方式replace政策部分：

   <policy context="default">

   <!-- Allow everything to be sent -->

   <allow send_destination="*" eavesdrop="true"/>

   <!-- Allow everything to be received -->

   <allow eavesdrop="true"/>

   <!-- Allow anyone to own anything -->

   <allow own="*"/>

   <!-- XXX: Allow all users to connect -->

   <allow user="*"/> </policy>

2. 删除includedir行：system.d

   <includedir>system.d</includedir>

资料来源： http ： //old.nabble.com/dbus-send-error-td29893862.html

一些其他有用的东西关于unix套接字

找出总线上发生的事情的最简单的方法是运行dbus-monitor总线程序包附带的dbus-monitor程序

您也可以尝试使用dbus-cleanup-sockets来清理剩余的插槽。

以下命令将根据netstat输出显示连接了多less次到dbus套接字的进程：

 sudo netstat -nap | grep dbus | grep CONNECTED | awk '{print $8}' | sort | uniq -c 

（在Ubuntu上testing）

硬核方式：这个命令将手动find/ proc和show中使用最多连接（所有types的套接字）的进程：

 ls -lR */fd/* | grep socket | sed -r "s@([0-9{1}]+)/fd/@_\1_@g" | awk -F_ '{print $2}' | uniq -c | sort -n | awk '{print $1" "$2; print system("ps "$2"|tail -n1")}' 

示例输出：

（计数，PID和下一行包含有关进程的详细信息）

 25 3732 3732 ? Ss 0:38 /usr/bin/wineserver 89 1970 1970 ? Ss 0:02 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session 

（在Ubuntu上testing）

玩的开心。

参见相关文章以供参考：

• Linux API来确定进程拥有的套接字
• / proc / PID / fd / X链接号码