Qué es un file descriptor y por qué todo en Linux es un archivo

Publicado el 2026-09-12 por frfrand

Un número entero que representa cualquier cosa abierta: archivos, sockets, tuberías, el teclado. Por qué esa abstracción hizo tan potente a Unix, y qué significa "too many open files".

"En Unix todo es un archivo" es una frase que se repite mucho y se explica poco. El file descriptor es donde esa idea se vuelve concreta.

Un número, nada más

Cuando un proceso abre algo, el kernel le devuelve un número entero: el descriptor. A partir de ahí, el proceso usa ese número para leer, escribir y cerrar.

Lo interesante es qué puede haber detrás de ese número: un archivo en disco, una conexión de red, una tubería hacia otro proceso, un dispositivo, el teclado, un temporizador.

La interfaz es la misma para todos. Leer de un archivo y leer de un socket usan la misma llamada al sistema.

Los tres primeros están reservados por convención:

0 entrada estándar 1 salida estándar 2 error estándar

Y los que abras después reciben el número libre más bajo: 3, 4, 5.

Por qué esa abstracción es tan potente

Porque permite que los programas se combinen sin saber nada unos de otros.

Cuando escribís algo como esto:

$ cat registro.txt | grep error > salida.txt

lo que ocurre es que el shell manipula descriptores: conecta la salida de uno a la entrada del otro mediante una tubería, y redirige la salida final a un archivo.

Ni cat ni grep saben nada de esto. Cada uno lee de su descriptor 0 y escribe en su descriptor 1, sin enterarse de qué hay del otro lado. Esa es, en esencia, la razón por la que la línea de comandos de Unix es componible.

Y explica algo que confunde a mucha gente: por qué los errores no se van por la tubería. Como van al descriptor 2 y la tubería conecta el 1, los mensajes de error siguen apareciendo en pantalla. Eso es deliberado: permite ver los errores aunque estés redirigiendo la salida.

Too many open files

El error que hace famoso al concepto.

Cada proceso tiene un límite de descriptores abiertos. Por defecto suele ser 1024, que para un servidor con muchas conexiones se queda corto rápido.

Ver el límite actual:

ulimit -n

Ver cuántos tiene abiertos un proceso concreto:

ls /proc/<pid>/fd | wc -l

Y ver qué tiene abierto, que es lo que de verdad ayuda:

ls -l /proc/<pid>/fd

Eso muestra cada descriptor y a qué apunta. Es la forma más rápida de detectar una fuga: si ves cientos de descriptores apuntando al mismo archivo o a sockets cerrados, hay código que abre y no cierra.

Subir el límite, y el detalle que se olvida

Se puede subir en /etc/security/limits.conf, pero hay una trampa muy común: eso no aplica a los servicios de systemd.

Los servicios necesitan su propio ajuste:

[Service] LimitNOFILE=65535

Es la causa número uno de "subí el límite y sigue fallando".

Un detalle que sorprende

Si borrás un archivo que un proceso tiene abierto, el espacio no se libera hasta que ese proceso lo cierre. El nombre desaparece del directorio, pero el contenido sigue vivo porque hay un descriptor apuntándolo.

Es la explicación del misterio clásico: borraste un log gigante, "df" sigue mostrando el disco lleno, y "du" no encuentra nada grande. El archivo existe sin nombre, sostenido por un descriptor.

lsof +L1

lista exactamente esos casos. La solución es reiniciar el proceso que lo tiene abierto, o pedirle que reabra sus logs.