« Too many open files » (EMFILE) et la limite de descripteurs de fichiers

Ce que c'est

EMFILE est l'errno renvoyé par des appels tels que open(2), socket(2) ou accept(2) lorsque le processus appelant a déjà atteint sa propre limite de descripteurs de fichiers ouverts simultanément, soit RLIMIT_NOFILE, que la page de manuel getrlimit(2) décrit comme une limite par processus, avec une valeur souple (soft) et une valeur stricte (hard). Les shells et les environnements d'exécution des langages la présentent sous la forme « Too many open files » ; la cause sous-jacente est toujours la même : un compteur qui atteint son plafond, que les descripteurs correspondent à des fichiers, des sockets ou des tubes (pipes).

Pourquoi c'est important

Le même message recouvre deux situations très différentes, qui appellent des corrections différentes : soit un processus a légitimement besoin de plus de connexions ou de fichiers simultanés que ne le permet la limite par défaut, soit un processus comporte un bogue et ne ferme jamais ce qu'il ouvre, de sorte que le compteur augmente jusqu'à l'échec, quelle que soit la valeur de la limite.

Comment l'appliquer

• Diagnostiquer : ulimit -n, commande interne de bash documentée dans bash(1), indique la limite souple du shell courant ; cat /proc/<pid>/limits (proc(5)) affiche les limites souple et stricte « Max open files » d'un processus en cours d'exécution donné ; ls /proc/<pid>/fd | wc -l compte les descripteurs réellement détenus par ce processus (lsof -p liste aussi les fichiers projetés en mémoire et le répertoire de travail, et surévalue donc le nombre). Observé dans le temps, un compteur qui ne cesse de croître sous charge constante indique une fuite ; un compteur simplement élevé et stable indique une limite trop basse pour la concurrence légitime.
• Corrections, de la moins à la plus intrusive :
  1. Si le compteur croît sans borne, corriger la fuite dans l'application (sockets ou descripteurs de fichiers non fermés) ; relever la limite ne fait que repousser le même plantage.
  2. Si la concurrence est réellement élevée, relever la limite du shell courant : ulimit -n 65536 (dans la limite de la valeur stricte déjà en vigueur).
  3. Rendre persistante une limite plus haute pour les sessions de connexion via /etc/security/limits.conf (lu par pam_limits) ou, pour un service géré par systemd, définir LimitNOFILE= dans la section [Service] de l'unité, ce qui s'applique à ce service indépendamment des limites du shell.
  4. Dans les conteneurs, la limite est généralement héritée du démon de conteneurs ; la définir pour chaque conteneur (avec Docker, docker run --ulimit nofile=65536:65536) plutôt qu'à l'intérieur de celui-ci, où relever la limite stricte exige CAP_SYS_RESOURCE, capacité que Docker retire par défaut.
• À éviter : fixer partout la limite la plus haute possible. RLIMIT_NOFILE ne peut pas être « illimitée » (ulimit -n unlimited échoue ; le plafond est fs.nr_open), et des valeurs énormes masquent les vraies fuites et permettent à un seul processus incontrôlé d'épuiser la table de fichiers globale, partagée avec tous les autres processus.

Pièges

• Modifier ulimit -n dans un shell interactif en s'attendant à ce que cela affecte un service déjà lancé et géré par systemd ou par un superviseur, qui lisent leur propre limite au démarrage.
• Confondre la limite par processus avec fs.file-max, limite globale du système qui plafonne la table totale du noyau ; c'est un goulot d'étranglement différent et bien plus rare, dont l'atteinte produit ENFILE, « Too many open files in system ».