Come terminare un processo <defunct> con il genitore 1

17

Sto eseguendo Bacula su una scatola RedHat. Di tanto in tanto, il daemon di archiviazione bacula-sd smette di funzionare e diventa <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>

La mia domanda è: come posso uccidere questo processo? Il suo genitore è 1, che è init, per quanto ne so, e non vorrei interrompere il processo di init, vero?

L'uccisione "normale" di questo processo non funziona:

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

L'aiuto è molto apprezzato!

Modifica: in esecuzione

[root@backup ~]# lsof -p 5825

produce il seguente output:

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
fonte

Vedi anche unix.stackexchange.com/questions/5642/… e unix.stackexchange.com/questions/11172/…

— rogerdpack

18

L'unico modo in cui potresti rimuovere il processo zombi / defunto sarebbe uccidere il genitore. Dato che il genitore è init (pid 1), anche questo eliminerebbe il tuo sistema.

Questo ti lascia praticamente con due opzioni.

Modificare manualmente la tabella dei processi, ad es. creare un processo fittizio, collegare il processo defunto come figlio del fittizio, quindi eliminarli. Abbastanza pericoloso e potrebbe essere necessario ripulire manualmente altre risorse di processo come semafori e handle di file.
Riavvia il sistema.

Vorrei andare con il secondo.

— Roy
fonte

2

+1. Tuttavia, non c'è fretta di fare neanche, a condizione che non vengano visualizzati più processi di zombi o che il processo di zombi non abbia bloccato il 4G della RAM. :)

— Kyle Smith,

1

"Dato che il genitore è init (pid 1), questo eliminerebbe anche il tuo sistema" - Non puoi uccidere initperché non ha un gestore di segnale per SIGKILL. Vedere man 2 kill.

— Cawflands,

Come si fa per primo?

— skerit,

@AndrewH Non sono sicuro che SIGKILL dipenda da un gestore di segnali nel processo di destinazione, ma è vero che il kernel tipico ignorerà un SIGKILL per init. Tuttavia, se dovessi esaurire i modi più freddi per scatenare il panico del kernel, penso che scoprirai che sulla maggior parte dei sistemi Linux un SIGSEGV farà abbastanza bene.

— Roy

1

Va notato che uno dei initlavori è quello di raccogliere i processi di zombi, quindi se aspetti abbastanza a lungo initdovresti ripulire i processi di zombi. Sebbene, la maggior parte degli utenti initdovrebbe impostare il gestore di SIGCHLDcome SIG_IGN risolto questo problema.

— cipriota,

3

Potresti provare a riavviare init:

 # telinit u

Altrimenti, non mi preoccuperei troppo. Non è in esecuzione e non richiede risorse ed è solo lì in modo che il kernel possa ricordarlo.

— David Pashley
fonte

1

bene, devo preoccuparmi. è una macchina di produzione che esegue i servizi di backup (bacula) e voip (asterisco). fintanto che c'è il defunto processo bacula-sd, la bacula sembra non riuscire ad accedere all'unità nastro ...

— andreas-h

Non dovrebbe avere alcun file aperto. Esegui lsof -p 5825 e controlla.

— David Pashley,

Bene, sembra che ci siano molte cose aperte ... vedi sopra. Qualche idea su cosa posso fare? Non ho mai usato lsof ...

— andreas-h

1

Sì, il tuo zombi ha / dev / nst0 aperto. Un riavvio del sistema è probabilmente la scommessa migliore a questo punto.

— Kyle Smith,

5

Sì, il riavvio sembra essere la risposta prevalente. Mi sento sempre come se avessi fallito quando devo riavviare un server. :(

— David Pashley,

3

Controlla se c'è stato un panico nel kernel,

# dmesg |tail

Controlla se il processo è in modalità D "Unkillable sleep", dove è in modalità kernel per alcuni syscall che non sono ancora tornati (o kernel oops o qualche altro motivo) http://www.nabble.com/What-causes-an -unkillable-processo - td20645581.html

— In pausa fino a nuovo avviso.
fonte

formattazione fastidiosa

— asdmin

in realtà, non c'è stato alcun panico nel kernel. il processo è nello stato "Z" - uno zombi ...

— andreas-h

3

Se uno zombi ha init come genitore, allora init ha smesso di funzionare correttamente. Uno dei ruoli di init è quello di ripulire gli zombi. Se non lo fa, nessun altro lo farà. Quindi l'unica soluzione è riavviare. Se init viene interrotto, un riavvio potrebbe non riuscire, quindi chiuderei i servizi importanti, sincronizzerei il filesystem e premo invece il pulsante di accensione.

— MarkR
fonte

Sono d'accordo sul fatto che init non funzioni correttamente. Vedi anche: upstarte systemd.

— Mikko Rantalainen,

2

Riduciamo il panico, vero? Un processo "defunto" o "zombi" non è un processo . È semplicemente una voce nella tabella dei processi, con un codice di uscita salvato. Pertanto, uno zombi non detiene risorse, non esegue cicli di CPU e non utilizza memoria, poiché non è un processo . Non diventare strano e prurito nel tentativo di "uccidere" i processi di zombi. Proprio come i loro omonimi, non possono essere uccisi, poiché sono già morti. Ma a differenza del tipo che mangia il cervello, non danneggiano assolutamente nessuno e non mordono altri processi.

Non lasciare che i processi di zombi ti mangino il cervello. Ignorali e basta.

— Teddy
fonte

11

Sì, questa è la teoria. Purtroppo non è sempre vero. Un processo defunto a volte si aggrappa alle risorse di sistema, come andreash ha chiaramente documentato.

— Roy,

5

Nel suo caso, secondo l'output di lsof, il processo degli zombi sta divorando il cervello di / dev / nst0. Ha bisogno di quei cervelli per continuare le operazioni di backup.

— Kyle Smith,

2

Un amministratore di sistema che trascorre la sua carriera ignorando i processi di zombi alla fine si sveglierà nel mezzo della notte con la loro vita risucchiata da loro. Nella mia esperienza, uno zombi è indicativo di qualcosa di sbagliato. Le scrivo anche quando un bambino zombi ha una strana interazione con il suo genitore, e il genitore gira la mia CPU. Non so di chi sia la colpa, ma il punto è che gli zombi sono brutti e un giorno ignorarli arriverà a perseguitarti. ... Un giorno ... quando dormi pacificamente ... nel cuore della notte ... dopo una fredda giornata d'autunno ...

— Mike S,

@MikeS Ho avuto una bella risata dal tuo commento!

— Paul Calabro,

@MikeS ha ragione. Ho ssh-agent defunto e ssh né git non possono funzionare correttamente. solo il riavvio può aiutare. (stessa correzione di Windows ha ... haha)

— John Tribe,

0

Sembra che tu abbia un processo orfano. Per quanto ne so, l'unico modo per ucciderli sarebbe riavviare la scatola. Ho avuto questo accadere sui miei server ESX (che sono Linux sotto il cofano) di volta in volta e un riavvio dell'host è la soluzione (dal supporto VMware).

Sono un ragazzo di Windows, quindi prendilo per quello che vale.

— mrdenny
fonte

sfortunatamente, il riavvio non è una vera opzione. è una macchina di produzione che esegue anche servizi VoIP, quindi non posso riavviarlo durante le ore d'ufficio ...

— andreas-h

1

quindi, potresti riavviarlo dopo l'orario di ufficio, giusto?

— Warren,