50 votes

Utilisateur non enregistré avatar

Comment trouver l'autre extrémité d'une connexion unix socket ?

Demandé el 28 de Mars, 2011
Quand la question a-t-elle été
76276 affichage
Nombre de visites la question a
5 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

J'ai un processus (dbus-daemon) qui a plusieurs connexions ouvertes sur des sockets UNIX. L'une de ces connexions est le fd #36 :

=$ ps uw -p 23284
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
depesz   23284  0.0  0.0  24680  1772 ?        Ss   15:25   0:00 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

=$ ls -l /proc/23284/fd/36 
lrwx------ 1 depesz depesz 64 2011-03-28 15:32 /proc/23284/fd/36 -> socket:[1013410]

=$ netstat -nxp | grep 1013410
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
unix  3      [ ]         STREAM     CONNECTED     1013410  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD

=$ netstat -nxp | grep dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1013953  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1013825  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1013726  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1013471  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1013410  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1012325  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1012302  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1012289  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1012151  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011957  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011937  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011900  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011775  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011771  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011769  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011766  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011663  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011635  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011627  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011540  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011480  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011349  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011312  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011284  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011250  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011231  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011155  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011061  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011049  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011035  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1011013  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1010961  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD
unix  3      [ ]         STREAM     CONNECTED     1010945  23284/dbus-daemon   @/tmp/dbus-3XDU4PYEzD

En me basant sur le nombre de connexions, je suppose que dbus-daemon est en fait un serveur. Ce qui est correct. Mais comment puis-je savoir quel processus y est connecté - en utilisant la connexion qui est le 36e gestionnaire de fichier dans dbus-launcher ? J'ai essayé lsof et même greps sur /proc/net/unix mais je n'arrive pas à trouver le processus client.

Demandé el 28 de Mars, 2011 par Utilisateur non enregistré

Réponses

Trop de publicités?

30voto

MvG avatar
MvG Points 1793

Cette réponse ne concerne que Linux.

Mise à jour pour Linux 3.3 : En tant que Zulakis a écrit dans un réponse séparée (+1 that), vous pouvez utiliser ss de iproute2 pour obtenir une paire de numéros d'inode pour chaque connexion de socket identifiant l'extrémité locale et l'homologue. Cela semble être basé sur la même machine que sock_diag(7) avec le UNIX_DIAG_PEER qui identifie le pair. L'attribut répondre par Totor sur Unix & Linux Stack Exchange renvoie aux commits concernés dans Noyau y iproute2 et mentionne également la nécessité de la UNIX_DIAG configuration du noyau.

La réponse originale pour Linux avant la version 3.3 est la suivante.

Sur la base de une réponse de l'Unix & Linux Stack Exchange, j'ai identifié avec succès l'autre extrémité d'un socket de domaine Unix en utilisant des structures de données dans le noyau, auxquelles on accède par l'intermédiaire de gdb y /proc/kcore . Vous devez activer la fonction CONFIG_DEBUG_INFO y CONFIG_PROC_KCORE options du noyau.

Vous pouvez utiliser lsof pour obtenir l'adresse du noyau de la socket, qui prend la forme d'un pointeur, par exemple 0xffff8803e256d9c0 . Ce nombre est en fait l'adresse de la structure ou du type de mémoire du noyau concerné struct unix_sock . Cette structure comporte un champ appelé peer qui pointe vers l'autre extrémité de la prise. Les commandes

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

imprimera l'adresse de l'autre extrémité de la connexion. Vous pouvez extraire la sortie de lsof -U pour ce numéro afin d'identifier le processus et le numéro de descripteur de fichier de l'autre extrémité.

Certaines distributions semblent fournir les symboles de débogage du noyau sous la forme d'un paquet séparé, qui prendrait la place de l'option vmlinux dans la commande ci-dessus.

Répondu el 15 de Août, 2012 par MvG (1793 Points )

28voto

Pixel avatar
Pixel Points 292

J'ai récemment rencontré un problème similaire. J'ai été choqué de découvrir qu'il y a des cas où ce n'est pas possible. J'ai déterré un commentaire du créateur de lsof (Vic Abell) dans lequel il soulignait que cela dépendait fortement de l'implémentation des sockets sous Unix. Parfois, les informations sur le "point final" de la socket sont disponibles, parfois non. Malheureusement, c'est impossible sous Linux, comme il le souligne.

Sous Linux, par exemple, où lsof doit utiliser /proc/net/unix, toutes les sockets de domaine UNIX ont un chemin d'accès lié, mais pas d'informations informations sur le point d'arrivée. Souvent, il n'y a pas de chemin d'accès. Il est donc souvent impossible de déterminer l'autre mais c'est le résultat du système de fichiers /proc de système de fichiers Linux /proc de Linux.

Si vous consultez le site /proc/net/unix, vous constaterez par vous-même qu'il a tout à fait raison (du moins sur mon système). Je suis encore choqué, parce que je trouve cette fonction essentielle lorsque je cherche à résoudre des problèmes de serveur.

Répondu el 3 de Juin, 2011 par Pixel (292 Points )

18voto

Zulakis avatar
Zulakis Points 3947

En fait, ss de iproute2 (qui remplace netstat, ifconfig, etc.) peut fournir ces informations.

Voici un exemple montrant une socket de domaine unix ssh-agent à laquelle est connectée une socket de domaine unix ssh-agent. ssh s'est connecté :

$ 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))
Répondu el 6 de Mars, 2016 par Zulakis (3947 Points )

10voto

Devdas avatar
Devdas Points 737

Sockets Unix généralement Les numéros sont attribués par paires et sont généralement consécutifs. La paire pour vous serait donc 1013410+/-1. Voyez laquelle de ces deux paires existe et devinez le coupable.

Répondu el 26 de Janvier, 2012 par Devdas (737 Points )

10voto

lemonsqueeze avatar
lemonsqueeze Points 221

J'ai écrit un outil qui utilise la fonction méthode gdb pour obtenir de manière fiable des informations sur les pairs de la socket, les symboles de débogage du noyau ne sont pas nécessaires.

Pour obtenir le processus connecté à un socket donné, transmettez-lui le numéro d'inode :

# socket_peer 1013410
3703 thunderbird

Pour obtenir des informations sur tous les processus à la fois, utilisez netstat_unix il ajoute une colonne à la sortie 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       
...

Essayer netstat_unix --dump si vous avez besoin d'un résultat facile à analyser.
Voir https://github.com/lemonsqueeze/unix_sockets_peers pour plus de détails.

Pour plus d'informations, le inode +1/-1 hack n'est pas fiable. Il fonctionne la plupart du temps, mais il peut échouer ou (pire) renvoyer la mauvaise prise si vous n'avez pas de chance.

Répondu el 14 de Novembre, 2014 par lemonsqueeze (221 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X