Zombie-Prozess

Als Zombie-Prozess wird bei unixartigen Betriebssystemen der Prozesstabelleneintrag eines beendeten Prozesses bezeichnet. Ein beendeter Prozess wird aus der Prozesstabelle entfernt, sobald sein Elternprozess dessen Exit-Status abfragt. Bis dahin verbleibt er dort als Zombie, der keine weiteren Ressourcen außer dem Tabelleneintrag, der Prozess-ID und Einträgen in Nutzungs-Statistiken mehr belegt.

Aus unten genauer beschriebenen Gründen bei der Prozessverwaltung wird ein beendeter Prozess manchmal nicht aus der Prozesstabelle entfernt (und belegt somit geringfügige Systemressourcen). Ein solcher, langlebiger Zombie richtet selbst keinen Schaden an, kann aber ein Hinweis auf einen Fehler sein.

Entstehung von Zombieprozessen

Wenn ein Prozess einen neuen Prozess startet (mittels Forking), wird der alte Elternprozess und der neue Kindprozess genannt. Wenn der Kindprozess beendet wird, kann der Elternprozess vom Betriebssystem erfragen, auf welche Art der Kindprozess beendet wurde: erfolgreich, mit Fehler, abgestürzt, abgebrochen etc.

Um diese Abfrage zu ermöglichen, bleibt der Eintrag, nachdem der Prozess beendet wurde, in der Prozesstabelle stehen, bis der Elternprozess diese Abfrage durchführt – egal ob diese Information gebraucht wird oder nicht. Bis dahin hat der Kindprozess den Zustand Zombie. In diesem Zustand belegt der Prozess selbst keinen Arbeitsspeicher mehr, bis auf den Eintrag in der Prozesstabelle des Kernels und verbraucht auch keine Rechenzeit, jedoch behält er seine PID, die (noch) nicht für andere Prozesse wiederverwendet werden kann.

Der Kernel sendet an den Elternprozess ein spezielles Signal, nämlich SIGCHLD, sobald eines seiner Kinder beendet wird, um ihm mitzuteilen, dass er eine Statusabfrage durchführen kann, damit es endgültig verschwindet. (Die Statusabfrage darf der Elternprozess auch direkt im Handler für dieses Signal durchführen.) Führt der Elternprozess keine Statusabfrage durch, verbleibt das Kind im Zombie-Zustand in der Prozesstabelle.

Verwaiste Prozesse

Ein weiterer Spezialfall, der an und für sich unabhängig von Zombies ist, jedoch in Kombination damit auftreten kann, ist, wenn der Elternprozess beendet wird. In diesem Fall werden alle seine Kindprozesse „verwaist“ genannt. Die Kindprozesse werden dann per Definition vom Prozess mit der PID 1 „adoptiert“ und bekommen diesen als Elternprozess zugewiesen. (In der klassischen System-V-Bootfolge hat der sogenannte init-Prozess die PID 1. Bei OS X tritt launchd an diese Stelle. Häufig wird bei Linux-Systemen hier systemd verwendet.) Dies passiert für laufende genauso wie für Zombieprozesse, deren Eltern nicht mehr existieren.

Probleme von Zombies

Zombies stellen in der Regel kein Problem für ein Betriebssystem dar, da diese Prozesse bereits beendet wurden und nur sehr wenige Systemressourcen in Anspruch nehmen. Allerdings kann der verursachende Fehler im Elternprozess unter Umständen, wie beispielsweise bei hoher Belastung, weit größere Folgen haben. Eine große Anzahl von Zombies kann auch dazu führen, dass dem Kernel die freien PIDs, die er für neue Prozesse braucht, ausgehen. Die PID-Belegung durch Zombies ist unter Umständen problematischer als deren minimaler Speicherverbrauch. Ist die Anzahl an Prozessen auf einem System limitiert (unter anderem via maxproc in limits.conf, um beispielsweise eine Forkbomb in ihrer Auswirkung zu begrenzen), so führen zu viele Zombies dazu, dass der Kernel keine neuen Prozesse mehr erzeugt.

Behandlung von Zombieprozessen

Obwohl Zombieprozesse in der Regel keine Gefahr für das System darstellen, können sie dennoch manuell gelöscht werden – oder auch automatisiert vom System.

Automatisiertes Löschen

Der init-Prozess hat unter anderem die Aufgabe, den Beendigungszustand aller seiner Kinder abzufragen, sobald diese beendet – also in den Zombie-Zustand überführt – werden. Damit sorgt er dafür, dass keine überflüssigen Zombies im System vorhanden sind. Laufende Prozesse, die vom init-Prozess adoptiert werden, werden dadurch nicht beeinträchtigt. Hier wartet der init-Prozess einfach, bis sie fertig sind, und fragt anschließend deren Status ab.

Alternativ kann man dem Elternprozess des Zombies (laut PPID-Angabe in der Prozesstabelle, zum Beispiel von ps axo stat,pid,comm,ppid | grep '^Z') manuell das Signal SIGCHLD senden, auf der Kommandozeile etwa mittels kill -CHLD <PID des Elternprozesses> . Reagiert der Elternprozess darauf nicht, so kann man den Elternprozess beenden, damit das Zombie-Kind vom init-Prozess adoptiert und sofort danach durch Abfrage seines Zustands endgültig gelöscht wird.

Besonderheit im Linux-Kernel

Der Linux-Kernel bietet für Prozesse, die nicht am Status ihrer Kinder interessiert sind, eine einfache – allerdings nicht standardisierte – Methode, Zombies loszuwerden: Gibt ein Prozess explizit an, dass er SIGCHLD ignorieren will (im Gegensatz zum Ignorieren per Default, wenn kein Handler angegeben ist), so löscht Linux die Zombies automatisch, ohne auf eine Statusabfrage zu warten.

Programmierfehler beseitigen

Wenn ein Prozess seine Kinder oftmals „vergisst“ und zu Zombies werden lässt, besonders wenn er auch auf ein manuelles SIGCHLD nicht reagiert, ist das meistens ein Hinweis auf einen Bug in diesem Programm. Aus oben genannten Gründen sollten diese Fehler im Programm beseitigt werden, um das System durch die entstehenden Zombies nicht zu beeinträchtigen.

Beispiel in C zur Erzeugung von Zombies

Synchrones Warten auf denselben Kindprozess in einer fest definierten Reihenfolge kann Zombieprozesse erzeugen und diese sogar über eine lange Zeit am Leben erhalten. Dies ist nicht notwendigerweise ein Programmierfehler, wie im folgenden Codebeispiel zu sehen ist:

#include <sys/wait.h> #include <stdlib.h> #include <unistd.h> int main(void){  pid_t pids[10]; // Platz für 10 Prozess-IDs (die Kindprozesse)  int i; // Laufvariable  for (i = 0; i < 10; ++i) {  // Der Elternprozess erzeugt nun einen Kindprozess,  // welcher unabhängig vom Elternprozess mit der  // erneuten Ausführung des Programms beginnt.  // Ein Kindprozess erzeugt keinen Fork von sich selbst.  pids[i] = fork();  if (pids[i] == 0) {  // dann befinden wir uns in einem der 10 Kindprozesse  // Der erste Kindprozess wartet 10 Sekunden und jeder  // weitere Kindprozess wartet 1 Sekunde kürzer als der  // vorige.  sleep(10-i);  exit(0); // Kindprozess erfolgreich beenden  }  }  // hier kommt nur der Elternprozess vorbei  for (i = 0; i < 10; ++i){  // Der Elternprozess wartet nun, bis der Reihe nach jeder  // seiner 10 Kindprozesse beendet ist. Leider wird auf das  // Kind mit der längsten Wartezeit zuerst gewartet. Obwohl  // die anderen Kinder längst erfolgreich beendet wurden,  // blockiert das erste Kind eine Bereinigung der Prozesstabelle  waitpid(pids[i], NULL, 0);  }  return 0; // Elternprozess erfolgreich beenden } 

Dennoch ist das Verhalten nicht optimal. Eine bessere Alternative bestünde darin, auf einen beliebigen Prozess zu warten, ihn im Array als erledigt zu markieren und diesen Prozess fortzuführen, bis das Array leer ist.

Literatur

• Michael Kerrisk: The Linux Programming Interface, Chapter 26: Monitoring Child Processes. No Starch Press, San Francisco 2010, ISBN 978-1-59327-220-3. (engl.)

Einzelnachweise

1. The Open Group Base Specifications Issue 7, 2018 edition IEEE Std 1003.1™-2017 (Revision of IEEE Std 1003.1-2008): Consequences of Process Termination

Siehe auch

• Daemon