Solución 1:
Esta respuesta es solo para Linux.
Actualización para Linux 3.3: Como escribió Zulakis en una respuesta separada (+1 eso), puede usar ss de iproute2 para obtener un par de números de inodo para cada conexión de socket que identifique el extremo local y el par. Esto parece estar basado en la misma maquinaria que sock_diag(7) con el UNIX_DIAG_PEER atributo que identifica al par. Una respuesta de Totor en Unix &Linux Stack Exchange vincula a las confirmaciones relevantes en kernel e iproute2 y también menciona la necesidad de UNIX_DIAG ajuste de configuración del kernel.
Sigue la respuesta original para Linux anterior a 3.3.
Basado en una respuesta de Unix &Linux Stack Exchange, identifiqué con éxito el otro extremo de un socket de dominio de Unix usando estructuras de datos en el kernel, accediendo usando gdb y /proc/kcore . Debe habilitar el CONFIG_DEBUG_INFO y CONFIG_PROC_KCORE opciones del kernel.
Puedes usar lsof para obtener la dirección del kernel del socket, que toma la forma de un puntero, p. 0xffff8803e256d9c0 . Ese número es en realidad la dirección de la estructura de memoria interna relevante o escriba struct unix_sock . Esa estructura tiene un campo llamado peer que apunta al otro extremo del zócalo. Entonces los comandos
# gdb /usr/src/linux/vmlinux /proc/kcore
(gdb) p ((struct unix_sock*)0xffff8803e256d9c0)->peer
imprimirá la dirección del otro extremo de la conexión. Puede grep la salida de lsof -U para que ese número identifique el proceso y el número de descriptor de archivo de ese otro extremo.
Algunas distribuciones parecen proporcionar símbolos de depuración del kernel como un paquete separado, que ocuparía el lugar del vmlinux archivo en el comando anterior.
Solución 2:
Hace poco me encontré con un problema similar. Me sorprendió descubrir que hay casos en los que esto podría no ser posible. Desenterré un comentario del creador de lsof (Vic Abell) donde señaló que esto depende en gran medida de la implementación del socket de Unix. A veces, la llamada información de "punto final" para el socket está disponible y, a veces, no. Desafortunadamente es imposible en Linux como él señala.
En Linux, por ejemplo, donde lsof debe usar /proc/net/unix, todos los sockets de dominio de UNIX tienen una ruta enlazada, pero no información de punto final. A menudo no hay un camino enlazado. Eso a menudo hace que sea imposible determinar el otro extremo, pero es el resultado de la implementación del sistema de archivos Linux /proc.
Si observa /proc/net/unix, puede ver por sí mismo que (al menos en mi sistema) tiene toda la razón. Todavía estoy sorprendido, porque considero que esta característica es esencial al rastrear los problemas del servidor.
Solución 3:
En realidad, ss de iproute2 (reemplazo de netstat, ifconfig, etc.) puede mostrar esta información.
Aquí hay un ejemplo que muestra un socket de dominio ssh-agent unix al que un ssh el proceso se ha conectado:
$ 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))
Solución 4:
Zócalos Unix generalmente se asignan números en pares, y por lo general son consecutivos. Entonces, el par para usted probablemente sea 1013410+/-1. Vea cuál de esos dos existe y adivine al culpable.
Solución 5:
Escribí una herramienta que usa el método gdb de MvG para obtener de manera confiable información de pares de socket, no se necesitan símbolos de depuración del kernel.
Para conectar el proceso a un socket determinado, pásele el número de inodo:
# socket_peer 1013410
3703 thunderbird
Para averiguar todos los procesos a la vez, use netstat_unix , agrega una columna a la salida de 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
...
Prueba netstat_unix --dump si necesita una salida que sea fácil de analizar.
Consulte https://github.com/lemonsqueeze/unix_sockets_peers para obtener más detalles.
Para información, el inode +1/-1 hack no es confiable. Funciona la mayor parte del tiempo, pero fallará o (peor) devolverá el zócalo incorrecto si no tiene suerte.