Linux: too many open files (EMFILE, errore 24)

Come appare il messaggio

accept4() failed (24: Too many open files)

Cause frequenti

• Limite per processo troppo basso, spesso 1024 di default.
• Limite alzato in /etc/security/limits.conf, che però non vale per i servizi systemd.
• Leak di file descriptor: l'applicazione non chiude file o connessioni.
• Molte connessioni contemporanee, ad es. WebSocket o upstream lenti.
• In nginx: worker_connections più alto del limite dei worker.

Verifica

1. Mostra il limite reale del processo in esecuzione
   cat /proc/$(pgrep -o nginx)/limits | grep 'open files'Copia
2. Conta i descriptor aperti in questo momento
   ls /proc/$(pgrep -o nginx)/fd | wc -lCopia
3. Mostra il limite dalla unit systemd
   systemctl show nginx.service -p LimitNOFILECopia
4. Trova i processi con più file aperti
   lsof -n 2>/dev/null | awk '{print $1}' | sort | uniq -c | sort -rn | headCopia

Soluzione

• Imposta il limite per il servizio: systemctl edit nginx con [Service] LimitNOFILE=65535, poi riavvia.
• In nginx imposta anche worker_rlimit_nofile 65535;.
• Se i descriptor aperti crescono di continuo, cerca un leak invece di alzare solo il limite.
• limits.conf per le shell di login, sempre systemd per i servizi.
• Controlla il limite di sistema: cat /proc/sys/fs/file-nr.

Domande frequenti

Perché ulimit -n mostra un valore alto ma il servizio fallisce?

ulimit mostra il limite della tua shell. I servizi ereditano i limiti da systemd. Conta /proc/PID/limits del processo in esecuzione.

Quanto alto può essere il limite?

65535 è abbondante per la maggior parte dei servizi. Si può salire, ma si nascondono i leak. Osserva nel tempo il numero di descriptor aperti.