/ proc / PID / fd / número do link X

No Linux, in /proc/PID/fd/X, os links para descritores de arquivo que são pipes ou soquetes têm um número, como:

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]

Como na primeira linha: 6839. O que esse número representa?

Esse é o número do inode para o tubo ou soquete em questão.

Um canal é um canal unidirecional, com um final de gravação e um final de leitura. No seu exemplo, parece que o FD 5 e o FD 6 estão conversando entre si, pois os números dos inodes são os mesmos. (Talvez não, no entanto. Veja abaixo.)

Mais comum do que ver um programa conversando consigo mesmo através de um canal é um par de programas separados conversando entre si, normalmente porque você configura um canal entre eles com um shell:

shell-1$ ls -lR / | less

Em outra janela do 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]

Isso indica que a saída padrão do PID 4242 (FD 1, por convenção) está conectada a um tubo com número de inodo 222536390, e que a entrada padrão do PID 4243 (FD 0) está conectada ao mesmo tubo.

Tudo isso é um longo caminho para dizer que lsa saída está sendo enviada para lessa entrada da.

Voltando ao seu exemplo, o FD 1 e o FD 2 quase certamente não estão se falando. Provavelmente, este é o resultado de vincular stdout (FD 1) e stderr (FD 2) juntos, para que ambos vão para o mesmo destino. Você pode fazer isso com um shell Bourne como este:

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

Portanto, se você bisbilhotasse /proc/$PID_OF_SOME_OTHER_PROGRAM/fd, encontraria um terceiro FD anexado a um tubo com o mesmo número de inode que é anexado aos FDs 1 e 2 da some-programinstância. Também pode ser o que está acontecendo com os FDs 5 e 6 no seu exemplo, mas não tenho uma teoria pronta sobre como esses dois FDs se uniram. Você precisaria saber o que o programa está fazendo internamente para descobrir isso.

Para soquetes, você pode encontrar mais informações sobre o inode in /proc/net/tcp, /proc/net/udpou /proc/net/unix. Por exemplo:

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

Vemos inode é 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

Nesse caso, este é um soquete de escuta (sem endereço remoto), escutando na porta local 27 (0x1B). Os endereços IP são 4 bytes em hexadecimal em "notação de rede"; você pode usar a inet_ntoafunção para convertê-lo em notação abcd padrão (127.0.0.1 neste caso).

Observe que esses arquivos parecem ter 0 bytes, mas têm conteúdo se você os ler. Observe também que isso -aé necessário com o grep, pois eles podem (por exemplo, com unix) parecer binários.