18

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]

しかし、これは私のソケット接続のもう一方の端が何であるかを教えてくれません。どのプロセスがもう一方の端を保持しているのかをどのように知ることができますか？

4

2 に答える 2

15

Server FaultおよびUnix & Linuxについても同様の質問が寄せられています。受け入れられた答えは、この情報が Linux のユーザー空間で確実に利用できないというものです。

一般的な提案は、隣接するソケット番号を調べることですが、ls -l /proc/*/fd/* 2>/dev/null | grep 1282[79]ここでは結果が得られませんでした。おそらく、からの出力の隣接する行をnetstat使用できます。関連付けられたソケット名の有無にかかわらず、接続のパターンがあったようです。しかし、当て推量ではなく、ある種の確実性が欲しいのです。

1 つの回答は、カーネル構造を掘り下げることでこれに対処できるように見えるツールを示唆しています。CONFIG_DEBUG_INFOこのオプションを使用するには、オプションによって生成され、一部のディストリビューションによって別のパッケージとして提供される、カーネルのデバッグ情報が必要です。その答えに基づいて、によって提供されたアドレスを使用してlsof、次の解決策がうまくいきました：

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

これにより、接続の反対側のアドレスが出力されます。その番号をgrepするとlsof -U、プロセスIDやファイル記述子番号などの詳細が提供されます。

デバッグ情報が利用できない場合、ピア メンバーの unix_sock 構造へのオフセットを知ることで、必要な情報にアクセスできる可能性があります。私の場合、x86_64 の Linux 3.5.0 では、次のコードを使用して、デバッグ シンボルに依存せずに同じアドレスを計算できます。

(gdb) p ((void**)0xffff8803e256d9c0)[0x52]

そのソリューションの移植性については保証しません。

于 2012-08-10T10:55:50.150 に答える