Linux: Too many open files (EMFILE, Fehler 24)

So sieht die Meldung aus

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

Häufige Ursachen

• Limit pro Prozess zu niedrig, oft 1024 als Standard.
• Limit in /etc/security/limits.conf erhöht – das gilt aber nicht für systemd-Dienste.
• Dateideskriptor-Leck: Die Anwendung schließt Dateien oder Verbindungen nicht.
• Viele gleichzeitige Verbindungen, z. B. WebSockets oder langsame Upstreams.
• Bei nginx: worker_connections höher als das Limit der Worker.

Prüfen

1. Tatsächliches Limit des laufenden Prozesses anzeigen
   cat /proc/$(pgrep -o nginx)/limits | grep 'open files'Kopieren
2. Aktuell offene Deskriptoren zählen
   ls /proc/$(pgrep -o nginx)/fd | wc -lKopieren
3. Limit aus der systemd-Unit anzeigen
   systemctl show nginx.service -p LimitNOFILEKopieren
4. Prozesse mit den meisten offenen Dateien finden
   lsof -n 2>/dev/null | awk '{print $1}' | sort | uniq -c | sort -rn | headKopieren

Lösung

• Limit für den Dienst setzen: systemctl edit nginx und [Service] LimitNOFILE=65535, danach Neustart.
• Bei nginx zusätzlich worker_rlimit_nofile 65535; setzen.
• Steigt die Zahl offener Deskriptoren stetig, ein Leck suchen statt nur das Limit zu erhöhen.
• Für Login-Shells limits.conf anpassen, für Dienste immer systemd.
• Systemweite Grenze prüfen: cat /proc/sys/fs/file-nr.

Häufige Fragen

Warum zeigt ulimit -n einen hohen Wert, der Dienst scheitert trotzdem?

ulimit zeigt das Limit Ihrer Shell. Dienste erben ihre Limits von systemd. Maßgeblich ist /proc/PID/limits des laufenden Prozesses.

Wie hoch darf das Limit sein?

65535 ist für die meisten Dienste großzügig. Höhere Werte sind möglich, verdecken aber Lecks. Beobachten Sie die Zahl offener Deskriptoren über die Zeit.