kill -9 wirkt nicht? Warum der Prozess nicht stirbt

Wenn kill -9 nicht wirkt, hat SIGKILL nie etwas Lebendiges erreicht: Der Prozess ist bereits ein Zombie, steckt im Kernel im unterbrechbaren Schlaf fest, oder ein Supervisor gibt ihm ständig eine neue PID. ps -eo pid,ppid,stat,comm zeigt, welcher der drei Fälle vorliegt. So liest man das und so behebt man jeden Fall.

1. Erst herausfinden, in welchem Zustand der Prozess ist

$ clai zeig den Zustand eines Prozesses und was er gerade tut→ ps -eo pid,ppid,stat,comm | awk '$3 ~ /^Z/' 339320  339308 Z    sd_espeak-ng-mb1053146  902286 Z    headless_shell1053147  902286 Z    headless_shell

Der erste Buchstabe in STAT entscheidet alles. Z ist Zombie, D ist unterbrechbarer Schlaf, S/R ist ein lebendiger Prozess, der das Signal schlicht ignoriert.

2. Überblick über alle Zustände auf der Maschine

$ clai zähl die Prozesse nach Zustand→ ps -eo stat --no-headers | cut -c1 | sort | uniq -c | sort -rn    588 S    141 I      4 Z      1 R

Ein paar Zombies sind normal — sie belegen nichts außer einem Eintrag in der Prozesstabelle. Tausende bedeuten einen Bug im Elternprozess, der nie wait() aufruft.

3. Einen Zombie kann man nicht töten — er ist schon tot

$ clai finde den Elternprozess des Zombies 339320→ ps -o ppid= -p 339320 339308

Ein Zombie ist der Eintrag eines bereits beendeten Prozesses, den der Elternprozess nie mit wait() abgeholt hat. Signale an ihn zu schicken bringt nichts — man muss sich um den Elternprozess kümmern. Stirbt der Elternprozess, adoptiert init den Zombie und räumt ihn auf.

4. D-State: Der Prozess steckt im Kernel fest

$ clai zeig Prozesse im unterbrechbaren Schlaf und worauf sie warten→ ps -eo pid,stat,wchan:20,comm | awk '$2 ~ /^D/'

D bedeutet, er wartet im Kernel auf I/O — meist ein hängendes Netzwerkdateisystem oder eine defekte Platte. Ein solcher Prozess nimmt nicht einmal SIGKILL an, weil er keinen Nutzercode ausführt. Die Spalte wchan zeigt, in welcher Kernelfunktion er festhängt. Behoben wird das an der Quelle: NFS neu einhängen, Platte ersetzen. Manchmal hilft nur ein Neustart.

5. Der Prozess lebt, aber etwas startet ihn ständig neu

$ clai prüf, ob systemd diesen Dienst nach dem Killen neu startet→ systemctl show -p Restart -p RestartUSec app.service

Kommt der Prozess mit neuer PID zurück, kämpfen Sie nicht gegen ihn, sondern gegen den Supervisor. Stoppen Sie ihn mit systemctl stop, nicht mit kill.

6. Die Reihenfolge, die tatsächlich funktioniert

$ clai stopp Prozess 12345 sanft, und nach 5 Sekunden notfalls erzwingen→ kill 12345; sleep 5; kill -0 12345 2>/dev/null && kill -9 12345

Erst SIGTERM, damit der Prozess Dateien schließen und Puffer leeren kann. kill -0 tötet nichts, es prüft nur, ob der Prozess noch lebt. SIGKILL ist das letzte Mittel — danach ist alles verloren, was noch in den Puffern stand.

Stolperfallen

• kill -9 erreicht den Prozess nie — der Kernel übernimmt das. Genau deshalb ist es gegen D-State machtlos: Da ist niemand, der es behandeln könnte, der Prozess führt keinen eigenen Code aus.
• Ein Zombie belegt weder Speicher noch CPU. Er belegt einen Eintrag in der Prozesstabelle und eine Zeile in ps. Bei drei Zombies muss man nicht in Panik geraten — das ist ein Symptom, kein Problem.
• SIGKILL gibt dem Prozess keine Chance, sauber herunterzufahren. Ungeschriebene Puffer verschwinden, Sperren bleiben bestehen. Für Datenbanken und Dateiserver ist das ein echtes Risiko für Datenkorruption.

Verwandte Fragen

Warum funktioniert kill -9 nicht? Drei Gründe: Der Prozess ist bereits ein Zombie (tot, nichts mehr zu töten), er steckt im D-State (führt keinen Nutzercode aus), oder ein Supervisor startet ihn neu.

Wie tötet man alle Zombies auf einmal? Direkt geht das nicht. Finden Sie die Elternprozesse mit ps -eo ppid,stat | awk '$2 ~ /^Z/' und starten Sie diese neu — oder warten Sie, bis sie selbst wait() aufrufen.

Braucht D-State einen Neustart? Oft nicht. Beheben Sie zuerst die Ursache des Wartens: Netzwerkdateisystem wiederherstellen, dmesg auf Plattenfehler prüfen. Neustart nur, wenn die Quelle nicht erreichbar ist.

Siehe auch

• "Den Prozess auf Port 8080 killen" — und anderes, was Sie ständig googeln
• Den Prozess finden, dessen Speicher ständig wächst
• "Wer frisst gerade meine CPU?"

CliAI repariert keinen feststeckenden Kernel-Thread, erspart Ihnen aber das Raten von ps- und awk-Flags um 2 Uhr nachts. In einer Zeile installieren.