«Too many open files» (EMFILE) y el límite de descriptores de archivo

Qué es

EMFILE es el errno que devuelven llamadas como open(2), socket(2) o accept(2) cuando el proceso que las invoca ya ha alcanzado su propio límite de descriptores de archivo abiertos simultáneamente: RLIMIT_NOFILE, que la página de manual getrlimit(2) documenta como un límite por proceso con un valor flexible (soft) y otro estricto (hard). Las shells y los entornos de ejecución de los lenguajes lo muestran como "Too many open files"; la causa subyacente es siempre la misma: un contador que llega a su tope, ya se trate de archivos, sockets o tuberías (pipes).

Por qué importa

El mismo mensaje cubre dos situaciones muy distintas que requieren soluciones diferentes: un proceso que necesita legítimamente más conexiones o archivos simultáneos de los que permite el límite por defecto, y un proceso con un error que nunca cierra lo que abre, de modo que el recuento sube hasta fallar sin importar lo alto que se fije el límite.

Cómo aplicarlo

• Diagnóstico: ulimit -n, un comando interno (builtin) de bash documentado en bash(1), indica el límite soft de la shell actual; cat /proc/<pid>/limits (proc(5)) muestra los valores soft y hard de "Max open files" de un proceso en ejecución concreto; ls /proc/<pid>/fd | wc -l cuenta los descriptores que ese proceso mantiene realmente abiertos (lsof -p también lista archivos mapeados en memoria y el directorio de trabajo, así que cuenta de más). Observado a lo largo del tiempo, un recuento que sigue creciendo con carga constante apunta a una fuga; un recuento simplemente alto y estable apunta a un límite demasiado bajo para la concurrencia legítima.
• Soluciones, de la menos a la más invasiva:
  1. Si el recuento crece sin límite, corrige la fuga en la aplicación (sockets o manejadores de archivo sin cerrar); subir el límite solo pospone el mismo fallo.
  2. Si la concurrencia es realmente alta, aumenta el límite de la shell actual: ulimit -n 65536 (acotado por el límite hard vigente).
  3. Haz persistente un límite mayor para las sesiones de login mediante /etc/security/limits.conf (leído a través de pam_limits) o, para un servicio gestionado por systemd, define LimitNOFILE= en la sección [Service] de la unidad, que se aplica a ese servicio con independencia de los límites propios de la shell.
  4. En contenedores, el límite normalmente se hereda del daemon de contenedores; configúralo por contenedor (en Docker, docker run --ulimit nofile=65536:65536) en lugar de hacerlo dentro de él, donde subir el límite hard requiere CAP_SYS_RESOURCE, una capacidad que Docker elimina por defecto.
• Inseguro: fijar el límite lo más alto posible en todas partes. RLIMIT_NOFILE no puede ser "ilimitado" (ulimit -n unlimited falla; el techo es fs.nr_open), y los valores enormes ocultan fugas reales y permiten que un único proceso descontrolado agote la tabla de archivos global del sistema, compartida con todos los demás procesos.

Trampas

• Cambiar ulimit -n en una shell interactiva y esperar que afecte a un servicio ya en ejecución gestionado por systemd o por un supervisor, que leen su propio límite al arrancar.
• Confundir el límite por proceso con fs.file-max, el límite global del sistema, que acota la tabla total del kernel y es un cuello de botella distinto y mucho menos frecuente; al alcanzarlo se obtiene ENFILE, "Too many open files in system".