So beenden Sie einen <defunct> -Prozess mit übergeordnetem Element 1

17

Ich lasse Bacula auf einer RedHat-Box laufen. Von Zeit zu Zeit funktioniert der Speicher-Daemon bacula-sd nicht mehr und wird <defunct>.

[root@backup ~]# ps -ef | grep defunct | more
root      4801 29261  0 09:25 pts/5    00:00:00 grep defunct
root      5825     1  0 Oct18 ?        00:00:00 [bacula-sd] <defunct>

Meine Frage ist, wie kann ich diesen Prozess beenden? Sein Elternteil ist 1, was meines Wissens nach init ist, und ich würde den init-Prozess nicht abbrechen wollen, oder?

"Normalerweise" funktioniert das Beenden dieses Prozesses nicht:

[root@backup ~]# kill -0 5825
[root@backup ~]# kill -9 5825

Hilfe wird sehr geschätzt!

Bearbeiten: Laufen

[root@backup ~]# lsof -p 5825

erzeugt die folgende Ausgabe:

COMMAND    PID USER   FD   TYPE  DEVICE     SIZE    NODE NAME
bacula-sd 5825 root  cwd    DIR   253,0     4096 3801089 /root
bacula-sd 5825 root  rtd    DIR   253,0     4096       2 /
bacula-sd 5825 root  txt    REG   253,0  2110599  368004 /usr/local/sbin/bacula-sd
bacula-sd 5825 root  mem    REG   253,0    75284  389867 /usr/lib/libz.so.1.2.3
bacula-sd 5825 root  mem    REG   253,0    46680 3604521 /lib/libnss_files-2.5.so
bacula-sd 5825 root  mem    REG   253,0   936908  369115 /usr/lib/libstdc++.so.6.0.8
bacula-sd 5825 root  mem    REG   253,0   125736 3606807 /lib/ld-2.5.so
bacula-sd 5825 root  mem    REG   253,0  1602128 3606885 /lib/libc-2.5.so
bacula-sd 5825 root  mem    REG   253,0   208352 3606892 /lib/libm-2.5.so
bacula-sd 5825 root  mem    REG   253,0   125744 3606887 /lib/libpthread-2.5.so
bacula-sd 5825 root  mem    REG   253,0    25940 3604573 /lib/libacl.so.1.1.0
bacula-sd 5825 root  mem    REG   253,0    15972 3604535 /lib/libattr.so.1.1.0
bacula-sd 5825 root  mem    REG   253,0    46548 3606908 /lib/libgcc_s-4.1.2-20080102.so.1
bacula-sd 5825 root  mem    REG   253,0 56422480  366368 /usr/lib/locale/locale-archive
bacula-sd 5825 root    0r   CHR     1,3             1545 /dev/null
bacula-sd 5825 root    1r   CHR     1,3             1545 /dev/null
bacula-sd 5825 root    2r   CHR     1,3             1545 /dev/null
bacula-sd 5825 root    3u   CHR   9,128             6469 /dev/nst0
bacula-sd 5825 root    4u  IPv4 1023380              TCP backup:bacula-sd (LISTEN)
bacula-sd 5825 root    5u  IPv4 2693268              TCP backup:bacula-sd->backup:53957 (CLOSE_WAIT)
bacula-sd 5825 root    7u  IPv4 3248683              TCP backup:bacula-sd->backup:57629 (CLOSE_WAIT)
bacula-sd 5825 root    8u  IPv4 3250966              TCP backup:bacula-sd->backup:37650 (CLOSE_WAIT)
bacula-sd 5825 root    9u  IPv4 3253908              TCP backup:bacula-sd->backup:37671 (CLOSE_WAIT)

— andreas-h
quelle

Siehe auch unix.stackexchange.com/questions/5642/… und unix.stackexchange.com/questions/11172/…

— Rogerdpack

18

Die einzige Möglichkeit, den Zombie- / Abbruchprozess zu entfernen, besteht darin, die Eltern zu töten. Da das übergeordnete Element init (pid 1) ist, würde dies auch Ihr System herunterfahren.

Damit haben Sie zwei Möglichkeiten.

Ändern Sie die Prozesstabelle manuell, z. Erstellen Sie einen Dummy-Prozess, verknüpfen Sie den nicht mehr vorhandenen Prozess als untergeordnetes Element des Dummys und beenden Sie sie anschließend. Sehr gefährlich, und Sie müssen möglicherweise andere Prozessressourcen wie Semaphoren und Dateihandles manuell bereinigen.
Starten Sie das System neu.

Ich würde mit dem zweiten gehen.

— Roy
quelle

2

+1. Es gibt jedoch auch keine Eile, solange keine weiteren Zombie-Prozesse angezeigt werden oder Ihr Zombie-Prozess 4 GB RAM nicht blockiert hat. :)

— Kyle Smith

1

"Da das übergeordnete Element init (pid 1) ist, würde dies auch Ihr System herunterfahren." - Sie können nicht töten, initda es keinen Signalhandler für SIGKILL gibt. Sehen man 2 kill.

— Cawflands

Wie machst du das erste?

— Skerit

@AndrewH Ich bin nicht sicher, ob SIGKILL von einem Signal-Handler im Zielprozess abhängt, aber es ist wahr, dass der typische Kernel ein zu initialisierendes SIGKILL ignoriert. Sollte es Ihnen jedoch nicht mehr möglich sein, eine Kernel-Panik auszulösen, werden Sie wahrscheinlich feststellen, dass ein SIGSEGV auf den meisten Linux-Systemen recht gut funktioniert.

— Roy

1

Es sollte beachtet werden, dass eine der initAufgaben darin besteht, Zombieprozesse zu ernten. Wenn Sie also lange genug warten, initsollten Sie die Zombieprozesse bereinigen. Die meisten inits sollten jedoch den Handler SIGCHLDauf be setzen, SIG_IGN der dies behebt.

— Cyphar

3

Sie könnten versuchen, init neu zu starten:

 # telinit u

Sonst würde ich mir keine Sorgen machen. Es läuft nicht und nimmt keine Ressourcen in Anspruch und ist nur da, damit sich der Kernel daran erinnern kann.

— David Pashley
quelle

1

Nun, ich muss mir irgendwie Sorgen machen. Es ist eine Produktionsmaschine, auf der Backup- (Bacula) und VoIP- (Asterisk) Dienste ausgeführt werden. solange der defekte bacula-sd-prozess vorhanden ist, kann bacula anscheinend nicht auf das bandlaufwerk zugreifen ...

— andreas-h

Es sollten keine Dateien geöffnet sein. Führen Sie lsof -p 5825 aus und überprüfen Sie es.

— David Pashley

Nun, da scheint vieles offen zu sein ... siehe oben. Irgendwelche Ideen, was ich tun kann? Lsof habe ich noch nie benutzt ...

— andreas-h

1

Ja, dein Zombie hat / dev / nst0 geöffnet. Ein Systemneustart ist an dieser Stelle wahrscheinlich die beste Wahl.

— Kyle Smith

5

Ja, Neustart scheint die vorherrschende Antwort zu sein. Ich habe immer das Gefühl, dass ich gescheitert bin, wenn ich einen Server neu starten muss. :(

— David Pashley

3

Überprüfen Sie, ob es eine Kernel-Panik gab,

# dmesg |tail

Überprüfen Sie, ob sich der Prozess im "D" -Unkillable-Sleep-Modus befindet, in dem er sich für einen noch nicht zurückgegebenen Systemaufruf im Kernel-Modus befindet (entweder Kernel-Ups oder aus einem anderen Grund). Http://www.nabble.com/What-causes-an -unkillable-process - td20645581.html

— Bis auf weiteres angehalten.
quelle

ärgerliche Formatierung

— asdmin

Eigentlich gab es keine Kernel-Panik. Prozess ist in 'Z' Zustand - ein Zombie ...

— andreas-h

3

Wenn ein Zombie init als übergeordnetes Element hat, funktioniert init nicht mehr ordnungsgemäß. Eine der Aufgaben von init ist es, Zombies zu bereinigen. Wenn es das nicht tut, wird es niemand anderes tun. Die einzige Lösung ist also ein Neustart. Wenn init kaputt ist, schlägt ein Neustart möglicherweise fehl. Daher habe ich wichtige Dienste heruntergefahren, das Dateisystem synchronisiert und stattdessen den Ein- / Ausschalter gedrückt.

— MarkR
quelle

Ich bin damit einverstanden, dass init nicht richtig funktioniert. Siehe auch: upstartund systemd.

— Mikko Rantalainen

2

Lassen Sie uns die Panik lindern, sollen wir? Ein "nicht mehr existierender" oder "Zombie" -Prozess ist kein Prozess . Es handelt sich lediglich um einen Eintrag in der Prozesstabelle mit einem gespeicherten Beendigungscode. Daher hält ein Zombie keine Ressourcen, benötigt keine CPU-Zyklen und verwendet keinen Speicher, da es sich nicht um einen Prozess handelt . Versuche nicht, alle Zombie-Prozesse zu "töten". Genau wie ihre Namensvetter können sie nicht getötet werden, da sie bereits tot sind. Aber im Gegensatz zu den gehirnfressenden schädigen sie absolut niemanden und beißen andere Prozesse nicht.

Lass nicht zu, dass Zombieprozesse dein Gehirn fressen. Ignorier Sie einfach.

— Teddy
quelle

11

Ja, das ist die Theorie. Leider stimmt das nicht immer. Ein nicht mehr funktionierender Prozess hängt manchmal von den Systemressourcen ab, wie dies andreash eindeutig dokumentiert hat.

— Roy

5

In seinem Fall frisst der Zombie-Prozess gemäß der lsof-Ausgabe die Gehirne von / dev / nst0. Er braucht diese Köpfe, um die Sicherungsoperationen fortzusetzen.

— Kyle Smith

2

Ein Systemadministrator, der seine Karriere damit verbringt, Zombie-Prozesse zu ignorieren, wacht schließlich mitten in der Nacht auf, und sein Leben wird ihnen entzogen. Ein Zombie weist meiner Erfahrung nach auf einen Fehler hin. Ich schreibe diese, selbst wenn ein Zombiekind eine seltsame Interaktion mit seinem Elternteil hat und der Elternteil meine CPU dreht. Ich weiß nicht, wessen Schuld es ist, aber der Punkt ist, dass Zombies hässlich sind und eines Tages kommen werden, um dich zu verfolgen, wenn man sie ignoriert. ... Eines Tages ... wenn Sie friedlich schlafen ... mitten in der Nacht ... nach einem kalten Herbsttag ...

— Mike S

@ MikeS Ich habe ein gutes Lachen aus Ihrem Kommentar!

— Paul Calabro

@MikeS hat recht. Ich habe ssh-agent nicht mehr und ssh oder git können nicht richtig ausgeführt werden. Nur ein Neustart kann helfen. (das gleiche Update wie Windows hat ... haha)

— John Tribe

0

Scheint, als hättest du einen verwaisten Prozess. Soweit ich weiß, wäre die einzige Möglichkeit, diese zu töten, ein Neustart der Box. Ich habe dies von Zeit zu Zeit auf meinen ESX-Servern (die Linux unter der Haube sind) erlebt und ein Neustart des Hosts ist das Update (vom VMware-Support).

Ich bin ein Windows-Typ, also nimm das für das, was es wert ist.

— mrdenny
quelle

Ein Neustart ist leider keine echte Option. es ist eine produktionsmaschine, auf der auch voip-dienste ausgeführt werden, daher kann ich sie während der bürozeiten nicht neu starten ...

— andreas-h

1

Sie könnten es also nach den Bürozeiten neu starten, oder?

— Warren