Was sind Zombie-Prozesse?
Zombie-Prozesse sind solche Prozesse, die ihre Aufgabe beendet haben, aber der übergeordnete Prozess ist (höchstwahrscheinlich) gestorben oder unerwartet abgestürzt. Sie können auch auf fehlerhaften Code hinweisen. Die meisten Benutzer haben kein gutes Verständnis dafür, was Zombie-Prozesse sind und wie sie sich auf einen Linux-Host auswirken. Zuallererst trägt eine geringe Anzahl (z. B. zehn) von Zombie-Prozessen nicht zur Systemlast bei. Tatsächlich würden Tausende von Zombies nicht zur Systemlast beitragen.
Definitionsgemäß verbrauchen Zombie-Prozesse größtenteils keine Ressourcen. Jedem Zombie-Prozess wird immer noch eine Prozess-ID-Nummer oder PID zugewiesen. Auf 32-Bit-Systemen ist die maximale Anzahl an verfügbaren PIDs 32767. Bei 64-Bit-Systemen steigt diese Zahl exponentiell auf über 4 Millionen.
Außerdem wird für jeden Zombie-Prozess eine kleine Menge an Speicher verwendet. Technisch gesehen wären Zehntausende, vielleicht Hunderttausende von Zombie-Prozessen erforderlich, um eine erhebliche Erschöpfung der Systemressourcen zu verursachen.
Es gibt 2 Szenarien, die ich hier diskutieren werde. Der erste ist ein Prozess, der zahlreiche untergeordnete PIDs erzeugt, und dann stürzt die übergeordnete PID ab oder stirbt, ohne die untergeordneten PIDs zu ernten. Normalerweise weist dieses Problem auf einen möglichen Fehler im Programm oder Code hin. Wenn dies geschieht, übernimmt PID 1 (oder der Init-Prozess) die Eigentümerschaft. Für die Zwecke dieser Anleitung ist der schnellste Weg, diese Zombies loszuwerden, ein Neustart. Es ist auch möglich, einen Dummy-Prozess zu erstellen und den Besitz dieser Zombie-Prozesse zurück an die Dummy-PID zu übergeben, um sie zu bereinigen. Das ist hier außerhalb des Rahmens. Neustart und fertig!
Das zweite Szenario ist, wenn ein Prozess bis zu einem Punkt hängen bleibt, an dem das Betriebssystem ihn als ausgeführt sieht, aber der Prozess tatsächlich nichts tut. Das Beispiel, das ich für diese Diskussion verwende, ist der Daemon des automatischen Fehlerberichtstools (abrtd ), das mit Red Hat Enterprise Linux und einigen anderen Distributionen geliefert wird. Dies ist ein großartiges Tool, und ich mag es, es auf einem System zum Laufen zu bringen, weil es mir als Systemadministrator einen besseren Überblick darüber gibt, was oops ist – oder abstürzt –, aber nicht den Crash-Kernel aufruft.
In meiner Umgebung ist dieser Daemon auch eine Art Achillesferse. Standardmäßig abrtd erstellt nur Informationen für signierte Anwendungen. Jede App kann signiert werden, um einen Fehler zu generieren, aber wenn eine nicht signierte App abrtd auslöst , erstellt der Daemon einen Fehlerbericht und entfernt dann alles, was er erstellt hat. Dieses Verhalten kann Probleme verursachen, wenn eine Aktion für eine nicht signierte App hängen bleibt.
Schauen wir uns ein Beispiel an. Ein Benutzer reicht einen Vorfallbericht ein, der besagt, dass das System aufgrund von sechs Zombie-Prozessen langsam war. Es gibt einige tote Werbegeschenke auf einem System, das abrtd hat Probleme. Wenn Sie su - zum Rooten sehen Sie Folgendes:
'abrt-cli status' timed out
Wenn wir den abrtd prüfen Prozess können wir sehen, dass er noch läuft, aber es gibt einen untergeordneten Prozess, der seit dem 30.5. läuft.
[root@$HOSTNAME ~]# systemctl status abrtd
● abrtd.service - ABRT Automated Bug Reporting Tool
Loaded: loaded (/usr/lib/systemd/system/abrtd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2019-04-27 08:36:47 EDT; 2 months 13 days ago
Main PID: 1161 (abrtd)
Tasks: 12
Memory: 34.0M
CGroup: /system.slice/abrtd.service
├─ 1161 /usr/sbin/abrtd -d -s
├─60777 abrt-server -s
├─60867 /usr/libexec/abrt-handle-event -i -e post-create -- /var/spool/abrt/unsigned-app-2019-05-30-01:48:24-57451
├─64714 abrt-server -s
├─68157 abrt-server -s
├─70725 abrt-server -s
├─74101 abrt-server -s
├─77136 abrt-server -s
├─81417 abrt-server -s
├─84637 abrt-server -s
├─88183 abrt-server -s
└─90022 abrt-server -s
Also abrtd läuft technisch immer noch, aber dieser Post-Create-Prozess hat einen Zustand geschaffen, in dem einige neue ABRT-Absturzberichte versucht haben, ausgeführt zu werden, aber zu Zombies wurden. An dieser Stelle können Sie den abrtd neu starten Dienst, und diese Aktion löscht alle Zombie-Prozesse.
Aber wenn Sie nicht wussten, dass dies der Fall ist, finden Sie hier heraus, welche PID der Elternteil der Zombies ist, indem Sie den ps -xal verwenden Befehl. Dieser Befehl gibt eine Vielzahl aus von Informationen, also zeige ich nur die Spalten, die wir brauchen:
[root@$HOSTNAME ~]# ps -xal | awk '{ print $4 " " $10 " " $13 }' | sort -n
1739 Ssl+ java
1903 S bin/rscd
1903 S bin/rscd
2391 Ssl+ node
2816 Ssl+ java
2889 Ssl+ java
3785 Ss appcollect
3785 Ss appconfigcollect
3926 Ssl+ java
4696 Ss /bin/sh
4731 S bin/bash
4827 Sl /myappbinaries/jre/bin/java
7074 Ss+ httpd
7095 S+ httpd
Die vierte Spalte ist die PID des übergeordneten Prozesses, die zehnte Spalte ist der Status des untergeordneten Prozesses (offensichtlich würden Sie nach PIDs in einem Z-Zustand suchen) und die dreizehnte Spalte ist der untergeordnete Prozess. Mit der übergeordneten PID in Spalte vier können Sie diesen übergeordneten Prozess jetzt beenden, und seine Zombie-Kinder werden ebenfalls verschwinden. Es sei denn, diese übergeordnete PID ist 1, in diesem Fall ist ein Neustart erforderlich.
Da wir im Betrieb sind, haben wir nicht immer den Luxus, jederzeit neu zu starten. Persönlich denke ich, dass ein Neustart der letzte Ausweg sein sollte. Neustarts verbergen eine Vielzahl von Sünden und lassen diese Sünden zum ungünstigsten Zeitpunkt erscheinen, normalerweise spät in der Nacht oder an Feiertagswochenenden!
Oh, und die Last auf diesem System ist nach dem Neustart von abrtd kein bisschen gesunken und diese 6 Zombies beseitigen.