"Too many open files" (EMFILE) e o limite de descritores de arquivo

O que é

EMFILE é o errno retornado por chamadas como open(2), socket(2) ou accept(2) quando o processo chamador já atingiu o próprio limite de descritores de arquivo abertos simultaneamente — RLIMIT_NOFILE, descrito na página de manual getrlimit(2) como um limite por processo, com valor soft e valor hard. Shells e runtimes de linguagens o exibem como "Too many open files"; a causa subjacente é sempre a mesma: o mesmo contador chegou ao teto, quer os descritores sejam arquivos, sockets ou pipes.

Por que importa

A mesma mensagem cobre duas situações muito diferentes, que exigem correções diferentes: um processo que precisa legitimamente de mais conexões ou arquivos simultâneos do que o limite padrão permite, e um processo com um bug que nunca fecha o que abre, de modo que a contagem sobe até falhar, não importa quão alto seja o limite.

Como aplicar

• Diagnóstico: ulimit -n, um builtin do bash documentado em bash(1), mostra o limite soft do shell atual; cat /proc/<pid>/limits (proc(5)) mostra os limites soft e hard de "Max open files" de um processo em execução; ls /proc/<pid>/fd | wc -l conta os descritores realmente mantidos por esse processo (lsof -p também lista arquivos mapeados em memória e o diretório de trabalho, portanto conta a mais). Observada ao longo do tempo, uma contagem que continua subindo sob carga constante aponta para um vazamento; uma contagem simplesmente alta e estável aponta para um limite baixo demais para a concorrência legítima.
• Correções, da menos para a mais invasiva:
  1. Se a contagem cresce sem parar, corrija o vazamento na aplicação (sockets ou handles de arquivo não fechados); aumentar o limite apenas adia a mesma falha.
  2. Se a concorrência é realmente alta, aumente o limite do shell atual: ulimit -n 65536 (restrito ao limite hard já em vigor).
  3. Torne persistente um limite maior para sessões de login via /etc/security/limits.conf (lido por meio do pam_limits) ou, para um serviço gerenciado pelo systemd, defina LimitNOFILE= na seção [Service] da unit, o que vale para esse serviço independentemente dos limites do próprio shell.
  4. Em contêineres, o limite costuma ser herdado do daemon de contêineres; defina-o por contêiner (no Docker, docker run --ulimit nofile=65536:65536) e não dentro dele, onde aumentar o limite hard exige CAP_SYS_RESOURCE, que o Docker remove por padrão.
• Inseguro: definir o limite o mais alto possível em todo lugar. RLIMIT_NOFILE não pode ser "ilimitado" (ulimit -n unlimited falha; o teto é fs.nr_open), e valores enormes escondem vazamentos reais e permitem que um único processo descontrolado esgote a tabela de arquivos do sistema, compartilhada com todos os outros processos.

Armadilhas

• Alterar ulimit -n em um shell interativo e esperar que isso afete um serviço já em execução gerenciado pelo systemd ou por um supervisor, que leem o próprio limite no momento da inicialização.
• Confundir o limite por processo com o fs.file-max, válido para todo o sistema, que limita a tabela total do kernel e é um gargalo diferente e muito mais raro; atingi-lo gera ENFILE, "Too many open files in system".