Soluzione 1:
Questa risposta è solo per Linux.
Aggiornamento per Linux 3.3: Come ha scritto Zulakis in una risposta separata (+1 quello), puoi usare ss da iproute2 per ottenere una coppia di numeri di inode per ogni connessione socket che identifica l'estremità locale e il peer. Questo sembra essere basato sullo stesso meccanismo di sock_diag(7) con UNIX_DIAG_PEER attributo che identifica il peer. Una risposta di Totor su Unix &Linux Stack Exchange si collega ai relativi commit in kernel e iproute2 e menziona anche la necessità del UNIX_DIAG impostazione di configurazione del kernel.
Segue la risposta originale per Linux precedente alla 3.3.
Sulla base di una risposta da Unix &Linux Stack Exchange, ho identificato con successo l'altra estremità di un socket di dominio unix utilizzando strutture di dati interne al kernel, a cui si accede utilizzando gdb e /proc/kcore . Devi abilitare il CONFIG_DEBUG_INFO e CONFIG_PROC_KCORE opzioni del kernel.
Puoi usare lsof per ottenere l'indirizzo del kernel del socket, che assume la forma di un puntatore, ad es. 0xffff8803e256d9c0 . Quel numero è in realtà l'indirizzo della relativa struttura di memoria nel kernel o digitare struct unix_sock . Quella struttura ha un campo chiamato peer che punta all'altra estremità della presa. Quindi i comandi
# gdb /usr/src/linux/vmlinux /proc/kcore
(gdb) p ((struct unix_sock*)0xffff8803e256d9c0)->peer
stamperà l'indirizzo dell'altra estremità della connessione. Puoi grep l'output di lsof -U per quel numero per identificare il processo e il numero del descrittore di file di quell'altra estremità.
Alcune distribuzioni sembrano fornire i simboli di debug del kernel come un pacchetto separato, che prenderebbe il posto del vmlinux file nel comando precedente.
Soluzione 2:
Di recente mi sono imbattuto in un problema simile. Sono rimasto scioccato nello scoprire che ci sono casi in cui questo potrebbe non essere possibile. Ho recuperato un commento dal creatore di lsof (Vic Abell) in cui ha sottolineato che questo dipende fortemente dall'implementazione del socket unix. A volte sono disponibili le cosiddette informazioni "endpoint" per il socket e talvolta no. Purtroppo è impossibile in Linux, come sottolinea.
Su Linux, ad esempio, dove lsof mustuse /proc/net/unix, tutti i socket di dominio UNIX hanno un percorso associato, ma nessuna informazione sull'endpoint. Spesso non esiste un percorso vincolato. Ciò spesso rende impossibile determinare l'altro endpoint, ma è il risultato dell'implementazione del file system Linux /proc.
Se guardi /proc/net/unix puoi vedere di persona che (almeno sul mio sistema) ha assolutamente ragione. Sono ancora scioccato, perché trovo questa funzionalità essenziale durante il monitoraggio dei problemi del server.
Soluzione 3:
In realtà, ss da iproute2 (in sostituzione di netstat, ifconfig, ecc.) può mostrare queste informazioni.
Ecco un esempio che mostra un socket di dominio unix ssh-agent a cui un ssh il processo si è connesso:
$ 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))
Soluzione 4:
Socket Unix solitamente vengono assegnati numeri in coppia e di solito sono consecutivi. Quindi la coppia per te sarebbe probabilmente 1013410+/-1. Guarda quale di questi due esiste e indovina il colpevole.
Soluzione 5:
Ho scritto uno strumento che utilizza il metodo gdb di MvG per ottenere in modo affidabile informazioni sui socket peer, i simboli di debug del kernel non sono necessari.
Per connettere il processo a un dato socket, passagli il numero di inode:
# socket_peer 1013410
3703 thunderbird
Per scoprire tutti i processi contemporaneamente usa netstat_unix , aggiunge una colonna all'output di 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
...
Prova netstat_unix --dump se hai bisogno di un output facile da analizzare.
Vedi https://github.com/lemonsqueeze/unix_sockets_peers per i dettagli.
Per informazioni, l'hack inode +1/-1 non è affidabile. Funziona la maggior parte delle volte ma fallirà o (peggio) restituirà il socket sbagliato se sei sfortunato.