En Linux, en /proc/PID/fd/X , los enlaces para los descriptores de archivos que son conductos o conectores tienen un 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 en la primera línea:6839. ¿Qué representa ese número?
Respuesta aceptada:
Ese es el número de inodo para la tubería o enchufe en cuestión.
Una tubería es un canal unidireccional, con un extremo de escritura y un extremo de lectura. En su ejemplo, parece que FD 5 y FD 6 se comunican entre sí, ya que los números de inodo son los mismos. (Sin embargo, tal vez no. Ver más abajo).
Más común que ver un programa hablándose a sí mismo a través de una tubería es un par de programas separados que se comunican entre sí, generalmente porque configura una tubería entre ellos con un shell:
shell-1$ ls -lR / | less
Luego, en otra ventana 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]
Esto dice que la salida estándar del PID 4242 (FD 1, por convención) está conectada a una tubería con número de inodo 222536390, y que la entrada estándar del PID 4243 (FD 0) está conectada a la misma tubería.
Todo lo cual es una forma larga de decir que ls La salida se envía a less entrada de.
Volviendo a su ejemplo, es casi seguro que FD 1 y FD 2 no hablando uno al otro. Lo más probable es que este sea el resultado de vincular stdout (FD 1) y stderr (FD 2), por lo que ambos van al mismo destino. Puedes hacerlo con un shell de Bourne como este:
$ some-program 2>&1 | some-other-program
Entonces, si hurgaste en /proc/$PID_OF_SOME_OTHER_PROGRAM/fd , encontrará un tercer FD adjunto a una canalización con el mismo número de inodo que está adjunto a los FD 1 y 2 para el some-program instancia. Esto también puede ser lo que está sucediendo con los FD 5 y 6 en su ejemplo, pero no tengo una teoría preparada sobre cómo se unieron estos dos FD. Tendría que saber qué está haciendo el programa internamente para darse cuenta.