Quando ho usato killall -9 name per uccidere un programma, lo stato diventa zombie. Alcuni minuti dopo, si è fermato davvero.
Allora, cosa sta succedendo in quei minuti?
Risposta accettata:
Il programma in realtà non riceve mai il segnale SIGKILL, poiché SIGKILL è completamente gestito dal sistema operativo/kernel.
Quando viene inviato SIGKILL per un processo specifico, lo scheduler del kernel smette immediatamente di concedere a quel processo più tempo di CPU per l'esecuzione del codice dello spazio utente. Se il processo ha dei thread che eseguono codice user-space su altre CPU/core nel momento in cui lo scheduler prende questa decisione, anche quei thread verranno interrotti. (Nei sistemi single-core questo era molto più semplice:se l'unico core della CPU nel sistema stava eseguendo lo scheduler, per definizione non stava eseguendo il processo allo stesso tempo!)
Se il processo/thread sta eseguendo codice del kernel (ad esempio una chiamata di sistema o un'operazione di I/O associata a un file mappato in memoria) al momento di SIGKILL, diventa un po' più complicato:solo alcune chiamate di sistema sono interrompibili, quindi il kernel internamente contrassegna il processo come in uno stato speciale di "estinzione" fino a quando le chiamate di sistema o le operazioni di I/O non vengono risolte. Il tempo della CPU per risolverli sarà programmato come al solito. Le chiamate di sistema interrompibili o le operazioni di I/O verificheranno se il processo che le ha chiamate sta morendo in qualsiasi punto di arresto appropriato e in tal caso uscirà presto. Le operazioni ininterrotte verranno completate e verificheranno lo stato di "estinzione" appena prima di tornare al codice dello spazio utente.
Una volta che tutte le routine del kernel in-process sono state risolte, lo stato del processo viene modificato da "morire" a "morto" e il kernel inizia a ripulirlo, in modo simile a quando un programma esce normalmente. Una volta completata la pulizia, verrà assegnato un codice risultato maggiore di 128 (per indicare che il processo è stato interrotto da un segnale; vedere questa risposta per i dettagli disordinati) e il processo passerà allo stato "zombie" . Il genitore del processo terminato verrà avvisato con un segnale SIGCHLD.
Di conseguenza, il processo stesso non avrà mai la possibilità di elaborare effettivamente le informazioni che ha ricevuto un SIGKILL.
Quando un processo è in uno stato "zombie" significa che il processo è già morto, ma il suo processo padre non lo ha ancora riconosciuto leggendo il codice di uscita del processo morto usando wait(2) chiamata di sistema. Fondamentalmente l'unica risorsa che un processo zombi sta consumando ancora è uno slot nella tabella dei processi che contiene il suo PID, il codice di uscita e alcune altre "statistiche vitali" del processo al momento della sua morte.
Se il processo padre muore prima dei suoi figli, i processi figlio orfani vengono automaticamente adottati dal PID #1, che ha il dovere speciale di continuare a chiamare wait(2) in modo che eventuali processi orfani non rimangano come zombi.
Se ci vogliono diversi minuti per cancellare un processo zombie, suggerisce che il genitore processo dello zombi sta lottando o non sta svolgendo correttamente il suo lavoro.
C'è una descrizione ironica su cosa fare in caso di problemi con gli zombi nei sistemi operativi simili a Unix:"Non puoi fare nulla per gli zombi stessi, poiché sono già morti. Invece, uccidi il malvagio maestro zombi! ” (cioè il processo genitore dei fastidiosi zombi)