/ proc / PID / fd / X numéro du lien

Sous Linux, in /proc/PID/fd/X, les liens des descripteurs de fichiers qui sont des pipes ou des sockets ont un numéro, comme:

l-wx------ 1 user user 64 Mar 24 00:05 1 -> pipe:[6839]
l-wx------ 1 user user 64 Mar 24 00:05 2 -> pipe:[6839]
lrwx------ 1 user user 64 Mar 24 00:05 3 -> socket:[3142925]
lrwx------ 1 user user 64 Mar 24 00:05 4 -> socket:[3142926]
lr-x------ 1 user user 64 Mar 24 00:05 5 -> pipe:[3142927]
l-wx------ 1 user user 64 Mar 24 00:05 6 -> pipe:[3142927]
lrwx------ 1 user user 64 Mar 24 00:05 7 -> socket:[3142930]
lrwx------ 1 user user 64 Mar 24 00:05 8 -> socket:[3142932]
lr-x------ 1 user user 64 Mar 24 00:05 9 -> pipe:[9837788]

Comme sur la première ligne: 6839. Que représente ce nombre?

C'est le numéro d' inode du tuyau ou de la prise en question.

Un tuyau est un canal unidirectionnel, avec une extrémité écriture et une extrémité lecture. Dans votre exemple, il semble que les FD 5 et FD 6 se parlent, car les numéros d'inode sont les mêmes. (Peut-être pas, cependant. Voir ci-dessous.)

Plus commun que de voir un programme se parler à lui-même par-dessus un tuyau est une paire de programmes séparés qui se parlent, généralement parce que vous configurez un tuyau entre eux avec un shell:

shell-1$ ls -lR / | less

Puis dans une autre fenêtre de terminal:

shell-2$ ...find the ls and less PIDs with ps; say 4242 and 4243 for this example...
shell-2$ ls -l /proc/4242/fd | grep pipe
l-wx------ 1 user user 64 Mar 24 12:18 1 -> pipe:[222536390]
shell-2$ ls -l /proc/4243/fd | grep pipe
l-wx------ 1 user user 64 Mar 24 12:18 0 -> pipe:[222536390]

Cela signifie que la sortie standard du PID 4242 (FD 1, par convention) est connectée à un tuyau portant le numéro d'inode 222536390 et que l'entrée standard du PID 4243 (FD 0) est connectée au même tuyau.

Ce qui est un long chemin à dire que lsla sortie est envoyée à lessl'entrée de.

Pour revenir à votre exemple, les FD 1 et FD 2 ne se parlent presque certainement pas . Il est fort probable que cela résulte du lien qui unit stdout (FD 1) et stderr (FD 2), de sorte qu'ils se rendent tous les deux à la même destination. Vous pouvez le faire avec un shell Bourne comme ceci:

$ some-program 2>&1 | some-other-program

Ainsi, si vous /proc/$PID_OF_SOME_OTHER_PROGRAM/fdfouillez dedans, vous trouverez un troisième FD attaché à un tuyau avec le même numéro d'inode que celui attaché aux FD 1 et 2 pour l' some-programinstance. C'est peut-être aussi ce qui se passe avec les FD 5 et 6 dans votre exemple, mais je n'ai pas de théorie toute prête quant à la manière dont ces deux FD ont été liées. Vous devez savoir ce que le programme fait en interne pour comprendre cela.

Pour les sockets, vous pouvez trouver plus d'informations sur l'inode dans /proc/net/tcp, /proc/net/udpou /proc/net/unix. Par exemple:

ls -l /proc/<pid>/fd
lrwx------ 1 root root 64 May 26 22:03 3 -> socket:[53710569]

Nous voyons l'inode est 53710569.

head -n1 < tcp ; grep -a 53710569 tcp
sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                   
155: 0100007F:001B 00000000:0000 0A 00000000:00000000 00:00000000 00000000  0        0 53710569 1 ffff88011f52c200 300 0 0 2 -1

Dans ce cas, il s’agit d’un socket d’écoute (pas d’adresse distante) qui écoute sur le port local 27 (0x1B). Les adresses IP ont une taille hexadécimale hexadécimale dans la "notation réseau". Vous pouvez utiliser la inet_ntoafonction pour la convertir en notation standard abcd (127.0.0.1 dans ce cas).

Notez que ces fichiers semblent être 0 octets mais ont un contenu si vous les lisez. Notez également que cela -aest nécessaire avec grep car ils peuvent (par exemple avec unix) sembler être binaires.