linux - tag - musicbrainz picard debian

¿Cómo puedo saber qué programa está en el otro extremo de un socket local?

Question

Strace me dice que un proceso en mi sistema Linux está hablando en un socket que tiene un descriptor de archivo 10. lsof me dice que este es un socket Unix con inode 11085, y netstat me dice que el Inode 11085 es un socket de corriente y que es conectado.

Dado que este proceso no tiene otros hilos, por lo tanto, debe haber otro proceso en el sistema que esté conectado al otro extremo de este socket. ¿Cómo puedo saber qué es?

Actualizar:

Hay algo de iluminación por parte del autor lsof here . Esencialmente, parece que Linux simplemente no proporciona esta información.

Answer 1

¿ netstat -p ayuda?

De Manpage:

 -p,
--program Show the PID and name of the program to which each socket belongs.

Answer 2

Escribí una tool que utiliza el método gdb 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 dado, pásale el número de inodo:

# socket_peer 11085
3703 thunderbird

Para descubrir 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
...

Pruebe netstat_unix --dump si necesita una salida que sea fácil de analizar.
Consulte tool para obtener más información.

Para información, el inodo + 1 / -1 hack no es confiable. Funciona la mayor parte del tiempo, pero fallará o (peor) devolverá el conector incorrecto si no tiene suerte.

Answer 3

He observado que:

El inodo del fd que llamó a connect() en el lado del cliente, siempre es exactamente uno mayor que el que recibió de la llamada accept() en el lado del servidor.

Ejemplo de salida de mi programa:

client_fd=4
/proc/4436/fd/4
inode=3072
is socket
node: 3072 socket: /tmp/unix.socket
f0be8960: 00000003 00000000 00000000 0001 03 3072 /tmp/unix.socket
/proc/9293/fd/43
fd:43
inode=3073
is socket
node: 3073 socket:
f0be81e0: 00000003 00000000 00000000 0001 03 3073

La ruta enlazada no se muestra en /proc/net/unix sin embargo.

YMMV y yo no hemos investigado la mecánica subyacente.

Answer 4

Parece que si estás realmente desesperado, puedes obtener esa información directamente de la memoria del kernel de Linux usando un depurador del kernel. Con la herramienta "crash" de RHEL5:

• obtenga una imagen vmlinux sin comprimir (por ejemplo, instale kernel-debuginfo rpm o extraiga el archivo vmlinux de esa rpm)
• ejecutar crash /path/to/vmlinux
• net -s 12345 enumera todos los sockets para PID 12345
• encuentre el socket interesante (tiene que ser de la familia / tipo UNIX:STREAM ), y anote su valor de SOCK :
  • PID: 12345 TASK: e903d000 CPU: 0 COMMAND: "someapp"
  • FD SOCKET SOCK FAMILY:TYPE SOURCE-PORT DESTINATION-PORT
  • 36 cadd0240 c8a64040 UNIX:STREAM
• ahora tiene la dirección de la unix_sock struct para este socket
  • básicamente, unix_sock.peer.name es la estructura de nombre del otro extremo del socket
  • p *(*(*((struct unix_sock*)( (struct unix_sock*)0xc8a64040)->peer)).addr).name con: p *(*(*((struct unix_sock*)( (struct unix_sock*)0xc8a64040)->peer)).addr).name

Realmente triste que esta información no se exporta directamente al espacio de usuario.

Answer 5

Qué tal esto: grep 11085 /proc/net/unix . Suponiendo que haya una ruta no vacía presente en la línea con el inodo que le interesa, grep para esa ruta en /proc/net/unix para encontrar el inodo para el otro extremo de la conexión, luego use el método @ efficientjelly''s para asignar el otro inodo a un pid .

Un punto clave aquí es el hecho de que los dos zócalos conectados tendrán cada uno un número de inodo diferente.

Answer 6

Si por alguna razón no tiene suerte con las opciones adecuadas de lsof y netstat, también puede hacer lo siguiente:

find /proc -lname ''*11085*'' 2> /dev/null

Answer 7

lsof | grep 11085

lsof debe ejecutarse como root.

He estado experimentando con lsof en mi sistema Linux y lsof -U muestra que todos los números en la columna NODE son únicos.

Answer 8

ss -p

le dirá (Siempre que el zócalo no sea propiedad del propio núcleo).