Zu viele offene Dateien unter Linux: ENFILE und EMFILE trennen

Die genaue Meldung entscheidet über die Ebene

Wenn ein Linux Dienst keine Datei mehr öffnen kann, liegt die naheliegende Vermutung oft bei einer einzelnen Anwendung. Doch die Meldung kann einen Prozess oder das gesamte System betreffen. Die Linux Beschreibung von open unterscheidet EMFILE für die prozessbezogene Grenze und ENFILE für die systemweite Grenze offener Dateien. Halten Sie daher den vollständigen Fehlertext und gegebenenfalls die Fehlernummer fest. Der zusätzliche Hinweis in system ist wichtig. Ein pauschales Erhöhen von ulimit im eigenen Terminal behandelt nicht automatisch einen systemweiten Engpass und verändert auch nicht rückwirkend die Grenzen bereits laufender Dienste.

Dateideskriptoren werden nicht nur für normale Dateien gebraucht. Netzwerkverbindungen und Pipes gehören ebenfalls zum Bild. Deshalb können bei einem Engpass sehr verschiedene Funktionen gleichzeitig scheitern: Ein Webserver nimmt keine neue Verbindung an, ein Hilfsprogramm startet nicht sauber oder ein Export kann eine Ausgabe nicht öffnen. Solche Folgefehler wirken mitunter wie mehrere unabhängige Defekte. Prüfen Sie den gemeinsamen Zeitpunkt, bevor Sie Bibliotheken ersetzen oder Anwendungen neu installieren. Wenn verschiedene Dienste dieselbe Ressourcenklasse nicht mehr erhalten, ist die gemeinsame Ebene ein sinnvoller Ansatz. Diese Beobachtung allein nennt jedoch noch nicht den Verursacher; dafür brauchen Sie den Verlauf der Belegung und passende Prozessdaten.

Systemweite Belegung zuerst aufnehmen

Die Kernel Dokumentation zu proc und Dateisystemgrenzen beschreibt file nr und file max. Unter Linux liefert die Datei unter proc einen Blick auf die systemweiten File Handles. Lesen Sie die Werte zusammen mit dem aktuell geltenden Grenzwert und dem Zeitpunkt. Eine Momentaufnahme nach der Störung kann bereits niedrig sein. Daraus folgt nicht, dass während des Fehlers kein Engpass bestand. Kurze Spitzen sind gerade bei vielen gleichzeitigen Verbindungen möglich. Beginnen Sie deshalb mit einer zeitlich passenden Messung und halten Sie auch fest, ob davor ein Dienst neu gestartet oder ein großer Job beendet wurde.

cat /proc/sys/fs/file-nr
sysctl fs.file-max
cat /proc/1234/limits

Die Prozessnummer 1234 ist im Beispiel ein Platzhalter. Diese Abfragen sind Bestandsprüfungen und ändern keine Werte. Für eine echte Diagnose brauchen Sie den betroffenen Host und passende Rechte. Bewahren Sie die Ergebnisse mit Zeitstempel auf und vergleichen Sie sie mit der Fehlermeldung. Rechnen Sie nicht aus einer beliebigen ruhigen Momentaufnahme eine allgemeine Entwarnung. Wenn der Wert gerade weit von der Grenze entfernt ist, ist das nur der beobachtete Zustand zu diesem Zeitpunkt. Die nächste Aufgabe kann darin bestehen, die kurze Spitze beim erneuten Auftreten zu erfassen. Ein sauber begrenzter Befund ist hilfreicher als eine Aussage, die mehr Zeitraum umfasst, als tatsächlich gemessen wurde.

Prozesslimits am echten Dienst lesen

Die Linux Dokumentation zu Ressourcenlimits erklärt die prozessbezogene Grenze für offene Deskriptoren. Für den Betrieb zählt der Wert des tatsächlich laufenden Prozesses. Ein ulimit Aufruf in Ihrer Shell beschreibt zunächst diese Shell und ihre später gestarteten Kinder. Ein bereits laufender Dienst kann mit anderen Grenzen gestartet worden sein. Lesen Sie daher die Limits des passenden Prozesses und prüfen Sie dessen Startweg. Dienste können ihre Grenzen durch den Dienstmanager oder eigene Konfiguration erhalten. Ohne diese Zuordnung ist eine Änderung am falschen Ort leicht möglich und wirkt beim nächsten Neustart anders als erwartet.

Bei einem Webstack können mehrere Prozesse und Dienste beteiligt sein. Ein FPM Pool besitzt andere Grenzen und andere Verbraucher als der äußere Webserver. Prüfen Sie die Ebene, zu der der Fehler gehört. Wenn nur ein Prozess an seine Grenze kommt, untersuchen Sie seine offenen Deskriptoren und die Arbeit, die er gerade ausführt. Wenn viele Dienste gleichzeitig scheitern, bleibt die systemweite Belegung besonders wichtig. Der FPM Diagnoseablauf hilft, diese Daten mit der betroffenen Anfrage zu verbinden. Beide Prüfungen können nötig sein, aber sie beantworten unterschiedliche Fragen und sollten im Protokoll nicht als derselbe Wert bezeichnet werden.

Verbraucher finden ohne sofort ein Leck zu behaupten

Für eine erste Sicht auf einen auffälligen Prozess kann das Verzeichnis seiner offenen Deskriptoren unter proc hilfreich sein. Eine gezielte lsof Abfrage liefert weitere Details, sofern das Werkzeug und die nötigen Rechte vorhanden sind. Beginnen Sie bei den größten oder zeitlich passenden Verbrauchern und betrachten Sie die Art ihrer Einträge. Viele Sockets können zu hoher normaler Last gehören; viele offene Datenbankdateien können zum vorgesehenen Betrieb passen. Eine hohe Zahl allein beweist kein Leck. Entscheidend ist, ob die Zahl mit dem Arbeitsumfang steigt und danach wieder sinkt oder ob sie über vergleichbare Lastphasen hinweg dauerhaft weiter anwächst.

Halten Sie zusätzlich Prozessstart, Rolle und typische Arbeit fest. Eine Prozessnummer kann nach einem Neustart neu vergeben werden; sie ist daher ohne Zeit und Identität kein dauerhafter Beleg. Bei einer Datenbank interessieren beispielsweise Verbindungen und Dateinutzung, bei einem Webserver die aktiven Anfragen und bei einem Import die gerade bearbeiteten Dateien. Vergleichen Sie ähnliche Zeiträume statt einen ruhigen Prozess mit einem gerade stark beschäftigten Prozess. Diese Sorgfalt verhindert, dass der größte Verbraucher automatisch als Schuldiger behandelt wird. Er kann lediglich der erste Dienst sein, dessen Fehler sichtbar wird, während eine andere Anwendung den gemeinsamen Engpass ausgelöst hat.

Kurze Spitzen vor dem nächsten Vorfall messen

Wenn die Belegung nach dem Vorfall wieder niedrig ist, brauchen Sie eine kleine fortlaufende Messung. Erfassen Sie den systemweiten Wert mit Zeitstempel in einem angemessenen Intervall. Bei einer hohen Belegung können gezielte zusätzliche Prozessdaten gesammelt werden. Der Logger muss selbst sparsam sein und darf nicht bei jedem Durchlauf große vollständige Listen erzeugen. Begrenzen Sie Dauer, Dateigröße und Speicherort. Ausführliche Ausgaben können interne Wege und Verbindungsdaten enthalten, deshalb bleiben sie geschützt. Testen Sie den Messablauf im ruhigen Zustand. Wenn er erst während des Engpasses gestartet wird, können gerade die dafür benötigten Hilfsprogramme bereits nicht mehr zuverlässig funktionieren.

Wählen Sie einen Zeitraum, der den vermuteten Auslöser umfasst. Eine nächtliche Sicherung, eine Crawlerwelle oder ein regelmäßig laufender Export kann kurzzeitig viel Arbeit erzeugen. Notieren Sie die Starts solcher Aufgaben und vergleichen Sie sie mit dem Verlauf. Ein zeitlicher Zusammenhang ist ein Hinweis, aber noch kein endgültiger Ursachenbeleg. Prüfen Sie ihn mit einem kontrollierten Ablauf oder einer begrenzten Änderung, wenn die Umgebung das erlaubt. Unser Ratgeber zur Kapazität beschreibt, wie Last und Ressourcen als Verlauf behandelt werden. Damit wird die Diagnose von einer zufälligen Momentaufnahme zu einer nachvollziehbaren Untersuchung.

Entlastung und dauerhafte Korrektur trennen

In einer akuten Störung kann eine kurzfristige Entlastung nötig sein. Dazu kann gehören, einen bekannten schweren Job zu stoppen oder einen betroffenen Dienst begrenzt neu zu starten. Der Umfang muss zur eigenen Zuständigkeit passen und andere Websites berücksichtigen. Sichern Sie vorher die wichtigsten Belege, soweit möglich. Nach der Maßnahme prüfen Sie die betroffene Funktion und den neuen Ressourcenstand. Schreiben Sie das Ergebnis als Entlastung auf. Wenn die Ursache noch offen ist, bleibt diese Grenze im Bericht bestehen. Ein ruhiger Zustand nach dem Eingriff darf nicht die frühere Fehlermeldung aus der Historie verdrängen oder als Nachweis für ein behobenes Leck gelten.

Ein höherer systemweiter Grenzwert kann in einer passend dimensionierten Umgebung zeitweise Reserve schaffen. Er erklärt aber nicht, warum die Belegung unerwartet gestiegen ist. Prüfen Sie daher vor einer Änderung den vorhandenen Wert, den Ressourcenrahmen und den Grund der bisherigen Einstellung. Verändern Sie keine globale Grenze für eine einzelne Kundendomain ohne Zuständigkeit für den Host. Nach einer autorisierten Änderung werden alter Wert, neuer Wert, Zeitpunkt und Postcheck festgehalten. Der weitere Verlauf bleibt zu beobachten. Wenn ein Prozess Deskriptoren nicht freigibt, verschiebt eine größere Grenze den nächsten Fehler nur nach hinten und kann die Auswirkungen auf andere Dienste vergrößern.

Persistente Werte bewusst verwalten

Eine temporäre Änderung und eine dauerhaft gespeicherte Einstellung sind verschiedene Schritte. Prüfen Sie, welche Konfigurationsdatei den Wert setzt und ob andere Dateien denselben Schlüssel enthalten. Eine neue Datei mit einem höheren Wert ist kein sauberer Abschluss, wenn die Reihenfolge später unklar bleibt. Ebenso hebt ein systemweiter Wert nicht automatisch die Grenzen laufender Prozesse an. Diese Ebenen müssen getrennt betrachtet werden. Für eine dauerhafte Anpassung gehört der Startweg der Dienste zur Abnahme. Dokumentieren Sie, ob ein Neustart erforderlich war und welcher Wert danach tatsächlich am laufenden Prozess galt. Nur die Konfigurationsdatei zu lesen genügt für diese Aussage nicht.

Behalten Sie außerdem einen Rückweg. Wenn eine neue Grenze unerwartete Last oder Nebenwirkungen erlaubt, muss der vorherige Stand bekannt sein. Ein Rücksetzen während laufender Arbeit kann jedoch andere Folgen haben als die ursprüngliche Änderung; beurteilen Sie den Zeitpunkt und die aktuellen Verbraucher. Globale Grenzen gehören in ein Wartungskonzept des Hostbetriebs, nicht in eine beiläufige Websiteanleitung. Der Plesk Betriebsratgeber erklärt die praktische Grenze zwischen Domain, Abo und Server. Diese Grenze schützt Nachbarprojekte und sorgt dafür, dass eine lokale Anforderung nicht unbemerkt zu einem allgemeinen Umbau wird.

Andere Fehlertexte nicht zum Beweis umdeuten

Ein FastCGI Timeout oder ein unbekannter Skriptpfad kann unabhängig von einem Open Files Engpass auftreten. Ordnen Sie solche Einträge nach ihrem eigenen Inhalt und prüfen Sie den Zeitbezug. Wenn der gesamte Host gerade keine Ressourcen mehr zuweisen konnte, sind Folgefehler plausibel. Wenn die Meldung nur in einer Domain und regelmäßig bei derselben URL erscheint, kann dagegen deren Konfiguration oder Anwendung betroffen sein. Die Analyse von HTTP Fehlern hilft, äußeren Status und innere Ursache zu trennen. Verwenden Sie keine einzelne ähnlich klingende Zeile als pauschalen Nachweis dafür, dass alle Fehler aus demselben Engpass stammen.

Auch Meldungen über fehlende Bibliotheken verdienen diese Sorgfalt. Ein Programm kann beim Öffnen einer vorhandenen Datei scheitern, wenn gerade die Ressource fehlt. Bevor Dateien ersetzt werden, prüfen Sie deren tatsächlichen Bestand und den zugrunde liegenden Fehler. Ein vorschneller Austausch kann die Umgebung zusätzlich verändern und die ursprüngliche Ursache verdecken. Halten Sie die Beobachtung eng: Datei vorhanden, Zugriff im Vorfall gescheitert, später wieder möglich. Daraus entsteht eine konkrete nächste Prüfung statt eine erfundene Beschädigung. Diese Arbeitsweise ist besonders unter Zeitdruck hilfreich, weil sie verhindert, dass viele scheinbare Folgeprobleme einzeln mit riskanten Änderungen behandelt werden.

Der Abschluss braucht einen vergleichbaren Verlauf

Nach einer dauerhaften Korrektur beobachten Sie den nächsten ähnlichen Lastzeitraum. Prüfen Sie Belegung, Fehler und die betroffene Funktion. Wenn ein Job geändert wurde, vergleichen Sie dessen Ergebnis und Dauer, ohne aus einzelnen Zahlen eine allgemeine Leistungszusage zu machen. Vermerken Sie, ob die gleiche Last wirklich wieder auftrat. Bleibt sie aus, ist der Fehler aktuell nicht beobachtet, aber die frühere Spitze noch nicht unter gleichen Bedingungen geprüft. Der Bericht kann diese Grenze ausdrücklich nennen. Ein ehrlicher Status hilft dem Team, die Beobachtung fortzusetzen und bei einer Wiederkehr genau an den noch offenen Teil der Untersuchung anzuknüpfen.

Die richtige Open Files Diagnose beginnt mit ENFILE oder EMFILE und endet mit einem belegten Verlauf. Prozesszahl, aktuelle Handlebelegung und Limits werden dabei auf ihrer jeweiligen Ebene gelesen. Eine höhere Grenze kann eine bewusst dokumentierte Maßnahme sein, ersetzt jedoch keine Ursachenprüfung. Mit Zeitstempeln, gezielten Verbraucherdaten und einer begrenzten Entlastung bleibt der Vorfall nachvollziehbar. Das schützt vor der falschen Diagnose eines Lecks und vor globalen Änderungen auf Verdacht. Für den Betrieb zählt am Ende, dass der konkrete Dienst unter der vorgesehenen Nutzung wieder zuverlässig arbeitet und dass der Weg zu dieser Aussage mit den passenden Belegen wiederholt werden kann.