Řešení 1:
Tato odpověď je pouze pro Linux.
Aktualizace pro Linux 3.3: Jak napsal Zulakis v samostatné odpovědi (+1 to), můžete použít ss z iproute2 k získání dvojice čísel inodů pro každé připojení soketu identifikující místní konec a peer. Zdá se, že je založeno na stejném stroji jako sock_diag(7) s UNIX_DIAG_PEER atribut identifikující peer. Odpověď od Totora na Unix &Linux Stack Exchange odkazuje na příslušné commity v jádře a iproute2 a také zmiňuje potřebu UNIX_DIAG nastavení konfigurace jádra.
Následuje původní odpověď pro Linux starší než 3.3.
Na základě odpovědi z Unix &Linux Stack Exchange jsem úspěšně identifikoval druhý konec soketu unixové domény pomocí datových struktur v jádře, ke kterému se přistupuje pomocí gdb a /proc/kcore . Musíte povolit CONFIG_DEBUG_INFO a CONFIG_PROC_KCORE možnosti jádra.
Můžete použít lsof získat adresu jádra soketu, která má podobu ukazatele, např. 0xffff8803e256d9c0 . Toto číslo je ve skutečnosti adresa příslušné struktury paměti v jádře nebo typu struct unix_sock . Tato struktura má pole nazvané peer který ukazuje na druhý konec zásuvky. Takže příkazy
# gdb /usr/src/linux/vmlinux /proc/kcore
(gdb) p ((struct unix_sock*)0xffff8803e256d9c0)->peer
vytiskne adresu druhého konce připojení. Můžete grep výstup lsof -U pro toto číslo k identifikaci procesu a čísla deskriptoru souboru tohoto druhého konce.
Zdá se, že některé distribuce poskytují symboly ladění jádra jako samostatný balíček, který by nahradil vmlinux soubor ve výše uvedeném příkazu.
Řešení 2:
Nedávno jsem narazil na podobný problém. Byl jsem šokován, když jsem zjistil, že existují případy, kdy to možná není možné. Vyhrabal jsem komentář od tvůrce lsof (Vic Abell), kde poukázal na to, že to silně závisí na implementaci unixového socketu. Někdy jsou k dispozici informace o takzvaném "koncovém bodu" pro socket a někdy ne. V Linuxu je to bohužel nemožné, jak zdůrazňuje.
Například v Linuxu, kde lsof musí používat /proc/net/unix, mají všechny doménové sokety systému UNIX vázanou cestu, ale žádné informace o koncovém bodě. Často neexistuje žádná svázaná cesta. To často znemožňuje určit jiný koncový bod, ale je to výsledek implementace souborového systému Linux /proc.
Když se podíváte na /proc/net/unix, můžete sami vidět, že (alespoň na mém systému) má naprostou pravdu. Stále jsem šokován, protože takovou funkci považuji za zásadní při sledování problémů se serverem.
Řešení 3:
Ve skutečnosti ss od iproute2 (náhrada za netstat, ifconfig atd.) může zobrazit tyto informace.
Zde je příklad ukazující unix doménový soket ssh-agent, ke kterému je přiřazen ssh proces se připojil:
$ 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))
Řešení 4:
Unixové sokety obvykle jsou přiřazena čísla ve dvojicích a jsou obvykle po sobě jdoucí. Takže pár pro vás bude pravděpodobně 1013410+/-1. Podívejte se, který z těchto dvou existuje, a hádejte viníka.
Řešení 5:
Napsal jsem nástroj, který používá metodu gdb od MvG ke spolehlivému získávání informací o rovnocenných soketech, symboly ladění jádra nejsou potřeba.
Chcete-li proces připojit k danému soketu, předejte mu číslo inodu:
# socket_peer 1013410
3703 thunderbird
Chcete-li to zjistit pro všechny procesy najednou, použijte netstat_unix , přidá do výstupu netstatu sloupec:
# 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
...
Zkuste netstat_unix --dump pokud potřebujete výstup, který lze snadno analyzovat.
Podrobnosti najdete na https://github.com/lemonsqueeze/unix_sockets_peers.
Pro informaci, hack +1/-1 inodu není spolehlivý. Většinu času funguje, ale pokud nemáte štěstí, selže nebo (co je horší) vrátí špatnou zásuvku.