linux - mp3tag - musicbrainz picard

Identificar otro extremo de una conexión de socket de dominio Unix

Question

Estoy tratando de averiguar qué proceso tiene el otro extremo de un socket de dominio Unix. En alguna salida de strace , he identificado un descriptor de archivo dado que está involucrado en el problema que actualmente estoy depurando, y me gustaría saber qué proceso se encuentra en el otro extremo de eso. Como hay varias conexiones a ese socket, simplemente el ir por el nombre de la ruta no funcionará.

lsof me proporciona la siguiente información:

dbus-daem  4175  mvg   10u  unix 0xffff8803e256d9c0      0t0  12828 @/tmp/dbus-LyGToFzlcG

Entonces, ¿conozco alguna dirección ("dirección del kernel"?), Conozco un número de socket y conozco la ruta. Puedo encontrar esa misma información en otros lugares:

$ 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]

Sin embargo, nada de esto me dice cuál es el otro extremo de mi conexión de socket. ¿Cómo puedo saber qué proceso está manteniendo el otro extremo?

Answer 1

Actualización: ha sido posible hacer esto usando interfaces reales por un tiempo ahora. A partir de Linux 3.3, la característica UNIX_DIAG proporciona una API basada en netlink para esta información, y lsof 4.89 y posteriores la admiten. Consulte https://unix.stackexchange.com/a/190606/1820 para obtener más información.

Answer 2

Preguntas similares se han hecho en Server Fault y Unix & Linux . La respuesta aceptada es que esta información no está disponible de manera confiable para el espacio del usuario en Linux.

Una sugerencia común es mirar los números de socket adyacentes, pero ls -l /proc/*/fd/* 2>/dev/null | grep 1282[79] ls -l /proc/*/fd/* 2>/dev/null | grep 1282[79] no dio resultados aquí. Quizás se pueden usar líneas adyacentes en la salida de netstat . Parece que hubo un patrón de conexiones con y sin un nombre de socket asociado. Pero me gustaría algún tipo de certeza, no solo conjeturas.

Una respuesta sugiere una herramienta que parece ser capaz de abordar esto al excavar a través de las estructuras del núcleo. El uso de esa opción requiere información de depuración para el kernel, tal como lo genera la opción CONFIG_DEBUG_INFO y se proporciona como un paquete separado por algunas distribuciones. Basado en esa respuesta, usando la dirección proporcionada por lsof , la siguiente solución funcionó para mí:

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

Esto imprimirá la dirección del otro extremo de la conexión. Si pulsa lsof -U para ese número, se proporcionarán detalles como la identificación del proceso y el número del descriptor del archivo.

Si la información de depuración no está disponible, podría ser posible acceder a la información requerida conociendo el desplazamiento del miembro igual en la estructura unix_sock. En mi caso, en Linux 3.5.0 para x86_64, se puede usar el siguiente código para calcular la misma dirección sin depender de los símbolos de depuración:

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

No haré ninguna garantía sobre cuán portátil es esa solución.