Als ich killall -9 name verwendet habe Um ein Programm zu töten, wird der Staat zum Zombie. Einige Minuten später hörte es wirklich auf.
Also, was passiert in diesen Minuten?
Akzeptierte Antwort:
Das Programm erhält eigentlich nie das SIGKILL-Signal, da SIGKILL vollständig vom Betriebssystem/Kernel verwaltet wird.
Wenn SIGKILL für einen bestimmten Prozess gesendet wird, hört der Scheduler des Kernels sofort auf, diesem Prozess mehr CPU-Zeit zum Ausführen von User-Space-Code zu geben. Wenn der Prozess zu dem Zeitpunkt, zu dem der Planer diese Entscheidung trifft, Threads hat, die Userspace-Code auf anderen CPUs/Kernen ausführen, werden diese Threads ebenfalls gestoppt. (In Single-Core-Systemen war dies früher viel einfacher:Wenn der einzige CPU-Kern im System den Scheduler ausführte, führte er per Definition nicht gleichzeitig den Prozess aus!)
Wenn der Prozess/Thread zum Zeitpunkt von SIGKILL Kernel-Code ausführt (z. B. einen Systemaufruf oder eine E/A-Operation, die mit einer speicherabgebildeten Datei verknüpft ist), wird es etwas kniffliger:Nur einige Systemaufrufe sind unterbrechbar, also die Der Kernel markiert den Prozess intern als in einem speziellen „sterbenden“ Zustand, bis die Systemaufrufe oder E/A-Operationen aufgelöst sind. Die CPU-Zeit, um diese zu beheben, wird wie gewohnt geplant. Unterbrechbare Systemaufrufe oder E/A-Operationen prüfen, ob der Prozess, der sie aufgerufen hat, an geeigneten Haltepunkten stirbt, und werden in diesem Fall vorzeitig beendet. Unterbrechungsfreie Operationen werden bis zum Abschluss ausgeführt und auf einen „sterbenden“ Zustand geprüft, kurz bevor sie zum Benutzerbereichscode zurückkehren.
Sobald alle prozessinternen Kernel-Routinen aufgelöst sind, wird der Prozessstatus von „dying“ zu „dead“ geändert und der Kernel beginnt mit der Bereinigung, ähnlich wie beim normalen Beenden eines Programms. Sobald die Bereinigung abgeschlossen ist, wird ein Ergebniscode größer als 128 zugewiesen (um anzuzeigen, dass der Prozess durch ein Signal beendet wurde; siehe diese Antwort für die chaotischen Details), und der Prozess wechselt in den „Zombie“-Zustand . Der Vater des getöteten Prozesses wird mit einem SIGCHLD-Signal benachrichtigt.
Folglich wird der Prozess selbst nie die Chance bekommen, die Information, dass er einen SIGKILL erhalten hat, tatsächlich zu verarbeiten.
Wenn sich ein Prozess in einem „Zombie“-Zustand befindet, bedeutet dies, dass der Prozess bereits tot ist, aber sein übergeordneter Prozess hat dies noch nicht bestätigt, indem er den Exit-Code des toten Prozesses mit wait(2) gelesen hat Systemaufruf. Im Grunde genommen ist die einzige Ressource, die ein Zombie-Prozess noch verbraucht, ein Platz in der Prozesstabelle, der seine PID, den Exit-Code und einige andere „lebenswichtige Statistiken“ des Prozesses zum Zeitpunkt seines Todes enthält.
Wenn der Elternprozess vor seinen Kindern stirbt, werden die verwaisten Kindprozesse automatisch von PID #1 übernommen, die eine besondere Pflicht hat, weiterhin wait(2) aufzurufen damit verwaiste Prozesse nicht als Zombies bestehen bleiben.
Wenn es mehrere Minuten dauert, bis ein Zombie-Prozess gelöscht wird, wird vorgeschlagen, dass der Eltern Prozess des Zombies hat Probleme oder macht seine Arbeit nicht richtig.
Was bei Zombie-Problemen in Unix-ähnlichen Betriebssystemen zu tun ist, wird augenzwinkernd beschrieben:„Für die Zombies selbst kann man nichts tun, da sie bereits tot sind. Töte stattdessen den bösen Zombiemeister! ” (d. h. der übergeordnete Prozess der lästigen Zombies)