Cosa sono i processi zombie?
I processi zombie sono quei processi che hanno terminato la loro attività, ma il processo padre (molto probabilmente) è morto o si è bloccato in modo imprevisto. Possono anche essere indicativi di codice difettoso. La maggior parte degli utenti non ha una buona comprensione di cosa siano i processi zombie e di come influiscano su un host Linux. Innanzitutto, un numero basso (diciamo dieci, ad esempio) di processi zombie non contribuisce al carico del sistema. In effetti, migliaia di zombi non contribuirebbero al carico del sistema.
Per definizione, i processi zombie non consumano risorse, per la maggior parte. A ogni processo zombie viene comunque allocato un numero ID processo, o PID. Sui sistemi a 32 bit, il numero massimo di PID disponibili è 32767. Per i sistemi a 64 bit, quel numero aumenta esponenzialmente fino a oltre 4 milioni.
C'è anche una piccola quantità di memoria utilizzata per ogni processo zombie. Tecnicamente, ci vorrebbero decine di migliaia, forse centinaia di migliaia di processi zombie per causare un significativo esaurimento delle risorse di sistema.
Ci sono 2 scenari di cui parlerò qui. Il primo è un processo che genera numerosi PID figlio, quindi il PID padre si arresta in modo anomalo o muore senza raccogliere i PID figlio. Normalmente, questo problema indicherebbe un possibile bug del programma o del codice. Quando ciò accade, il PID 1 (o il processo init) ne assume la proprietà. Ai fini di questa procedura, il percorso più rapido per sbarazzarsi di questi zombi è riavviare. È anche possibile creare un processo fittizio e trasferire la proprietà di quei processi zombie al PID fittizio per ripulirli. Questo è fuori portata qui. Riavvia e basta!
Il secondo scenario è quando un processo viene sospeso al punto che il sistema operativo lo vede in esecuzione, ma il processo in realtà non sta facendo nulla. L'esempio che sto usando per questa discussione è il demone dello strumento di segnalazione bug automatico (abrtd ) fornito con Red Hat Enterprise Linux e alcune altre distribuzioni. Questo è un ottimo strumento e mi piace averlo installato e funzionante su un sistema perché mi dà, come amministratore di sistema, una visione migliore di ciò che sta andando in crash, ma non invocando il kernel di crash.
Nel mio ambiente, questo demone è anche un po' un tallone d'Achille. Per impostazione predefinita, abrtd crea solo informazioni per le applicazioni firmate. Qualsiasi app può essere firmata per generare un bug, ma se un'app non firmata attiva abrtd , il demone esegue i movimenti di creazione di una segnalazione di bug e quindi rimuove tutto ciò che ha creato. Questo comportamento può causare problemi con un'azione sospesa per un'app non firmata.
Diamo un'occhiata a un esempio. Un utente invia un rapporto sull'incidente affermando che il sistema era lento a causa di sei processi zombie. Ci sono alcuni omaggi morti su un sistema che abrtd sta avendo problemi. Quando su - per eseguire il root vedrai quanto segue:
'abrt-cli status' timed out
Se controlliamo su abrtd processo possiamo vedere che è ancora in esecuzione, ma c'è un processo figlio in esecuzione dal 30/5.
[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
Quindi abrtd tecnicamente è ancora in esecuzione, ma il processo di post-creazione ha creato uno stato in cui alcuni nuovi rapporti sugli arresti anomali ABRT hanno tentato di essere eseguiti, ma sono diventati zombie. A questo punto, puoi riavviare abrtd servizio e quell'azione cancellerà tutti i processi zombie.
Ma, se non sapevi che era il caso, ecco come rintracciare quale PID è il genitore degli zombi usando il ps -xal comando. Questo comando restituisce un lotto di informazioni, quindi mostrerò solo le colonne di cui abbiamo bisogno:
[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
La quarta colonna è il PID del genitore, la decima colonna è lo stato del processo figlio (ovviamente cercherai i PID in uno stato Z) e la tredicesima colonna è il processo figlio. Usando il PID padre nella colonna quattro, ora puoi uccidere quel processo padre e anche i suoi figli zombi andranno via. A meno che il PID padre non sia 1, nel qual caso sarà necessario un riavvio.
Essendo in attività, non abbiamo sempre il lusso di riavviare in qualsiasi momento. Personalmente, sento che il riavvio dovrebbe essere l'ultima risorsa. I riavvii nascondono una moltitudine di peccati e lasciano che quei peccati si presentino nel momento più inopportuno, di solito a tarda notte o nei fine settimana delle vacanze!
Oh, e il carico su questo sistema non è diminuito di un po' dopo il riavvio di abrtd e ripulire quei 6 zombi.