Ein Dienst verschwindet ohne Absturzmeldung? Bei Speichermangel beendet der Kernel selbst Prozesse. Das Protokoll verrät, wen es traf und warum.
Aufwand:
ca. 30 Min.
Voraussetzung:
sudo-Rechte, Terminal
Gilt für:
Linux (Kernel 2.6.36 und neuer)
Das Symptom
Der Dienst lief wochenlang, und irgendwann war er weg. Kein Absturzbericht, keine
Fehlermeldung im eigenen Protokoll, kein Hinweis auf ein Signal. Der letzte
Logeintrag sieht völlig normal aus, mitten im Satz endet die Datei. Ein Neustart
des Dienstes bringt ihn zurück, und ein paar Tage später ist er wieder
verschwunden.
Die „Layer 8“-Wahrheit
Der Dienst ist nicht abgestürzt. Er wurde hingerichtet.
Linux verspricht Programmen mehr Speicher, als es besitzt, weil kaum ein Programm
alles nutzt, was es anfordert. Diese Wette geht meistens auf. Geht sie nicht auf
und der Arbeitsspeicher ist tatsächlich erschöpft, bleibt dem Kernel keine
elegante Wahl mehr. Er wählt ein Opfer und beendet es sofort, ohne Aufräumen,
ohne Vorwarnung. Deshalb fehlt im Protokoll des Dienstes jede Spur: Er hatte
keine Gelegenheit, etwas zu schreiben.
Der Beweis steht anderswo, nämlich im Kernelprotokoll. Und dort steht meist auch
die zweite Überraschung: Erwischt wurde nicht der Verursacher, sondern der größte
Verbraucher. Der Kernel bewertet nach Speicherbedarf, nicht nach Schuld. Ein
kleines Skript mit einem Speicherleck kann die Lage herbeiführen, während die
Datenbank stirbt, weil sie eben am meisten Speicher hält.
Wer nun Swap anlegt, hat nicht das Problem gelöst, sondern eine Pufferzone
eingezogen: Das System wird zäh, bevor es tötet, und Trägheit ist ein Symptom,
das man rechtzeitig bemerkt. Die eigentliche Frage bleibt, warum ein Prozess
unbegrenzt wächst. Diese Antwort gibt kein Kernelparameter, sondern nur ein Blick
in die Anwendung.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Den Verdacht im Kernelprotokoll bestätigen
Das Kernelprotokoll enthält bei jedem solchen Eingriff eine ausdrückliche Zeile. Sie nennt den beendeten Prozess samt Prozessnummer und ist der einzige belastbare Beweis:
sudo dmesg -T | grep -i "killed process"
2.
Auch das Journal durchsuchen
Auf Systemen mit systemd steht dieselbe Meldung im Journal und überlebt dort den Neustart. So lässt sich rekonstruieren, was in der Nacht geschah:
Nun prüfen, wie viel Speicher wirklich verfügbar ist. Entscheidend ist die Spalte für den verfügbaren Speicher, nicht der freie – zwischengespeicherte Daten zählen nicht als Mangel:
free -h
4.
Den größten Verbraucher ermitteln
Anschließend die Prozesse nach Speicherverbrauch sortieren. Wächst ein Prozess über Stunden stetig an, liegt ein Speicherleck vor und keine Unterdimensionierung:
ps -eo pid,comm,rss --sort=-rss | head -n 10
5.
Auslagerungsspeicher bereitstellen
Ein System ganz ohne Auslagerungsspeicher trifft der Eingriff schlagartig und ohne Vorwarnung. Etwas Swap verschafft dem Kernel Luft, Seiten auszulagern, bevor er zu töten beginnt. Er ersetzt keinen fehlenden Arbeitsspeicher, aber er verwandelt einen abrupten Tod in spürbare Trägheit.
6.
Den wichtigen Dienst schützen
Über die Prozessbewertung lässt sich ein Dienst gezielt bevorzugen oder opfern. Bei systemd-Diensten regelt das eine Einstellung in der Unit-Datei, mit der sich zusätzlich eine harte Speichergrenze setzen lässt. Ein Dienst, der seine Grenze überschreitet, reißt dann nicht mehr das System mit.
7.
Die Ursache beheben, nicht die Meldung
Swap und Speichergrenzen kaufen Zeit. Wächst ein Prozess unbegrenzt, ist die Ursache ein Fehler in der Anwendung oder eine zu große Datenmenge. Beides löst kein Kernelparameter.
Häufige Fragen (FAQ)
?Warum beendet der Kernel einfach meinen Prozess?
Weil die Alternative schlimmer wäre. Linux vergibt Speicher großzügiger, als tatsächlich vorhanden ist, in der Annahme, dass Programme selten alles nutzen, was sie anfordern. Wird die Annahme widerlegt und der Speicher geht wirklich aus, gibt es keinen Weg zurück. Der Kernel wählt dann einen Prozess aus und beendet ihn, damit das System als Ganzes weiterläuft, statt vollständig stehenzubleiben.
?Warum trifft es oft nicht den schuldigen Prozess?
Der Kernel bewertet Prozesse nach einer Punktzahl, die im Wesentlichen dem Speicherverbrauch folgt. Getroffen wird der größte Verbraucher, nicht der Verursacher. Ein kleines Skript kann durch ein Speicherleck die Lage herbeiführen, während die Datenbank stirbt, weil sie am meisten Speicher hält. Genau deshalb lohnt der Blick ins Protokoll statt der Verdacht gegen den zuletzt gestarteten Dienst.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.