Quando non dovrei uccidere -9 un processo?

Sono sempre molto riluttante a correre kill -9, ma vedo altri amministratori farlo quasi di routine.

Immagino che ci sia probabilmente una via di mezzo sensibile, quindi:

1. Quando e perché dovrebbe kill -9essere usato? Quando e perché no?
2. Cosa dovrebbe essere provato prima di farlo?
3. Che tipo di debug di un processo "bloccato" potrebbe causare ulteriori problemi?

In genere, è necessario utilizzare kill(abbreviazione di kill -s TERMo sulla maggior parte dei sistemi kill -15) prima di kill -9( kill -s KILL) per dare al processo di destinazione la possibilità di ripulire dopo se stesso. (I processi non possono essere catturati o ignorati SIGKILL, ma possono e spesso catturano SIGTERM.) Se non si dà al processo la possibilità di terminare ciò che sta facendo e ripulire, si possono lasciare file danneggiati (o altri stati) attorno a ciò non sarà in grado di capire una volta riavviato.

strace/ truss, ltracee gdbsono generalmente buone idee per capire perché un processo bloccato è bloccato. ( truss -usu Solaris è particolarmente utile; trovo che ltracetroppo spesso presenti argomenti alle chiamate in libreria in un formato inutilizzabile.) Solaris ha anche utili /procstrumenti basati, alcuni dei quali sono stati portati su Linux. ( pstackè spesso utile).

Randal Schwartz pubblicava spesso "L'uso inutile di (x)" nelle liste. Uno di questi post riguardava kill -9. Include ragioni e una ricetta da seguire. Ecco una versione ricostruita (citato di seguito).

(Preventivo abominio)

No no no Non usare kill -9.

Non dà al processo la possibilità di pulire in modo chiaro:

1) chiudere i collegamenti delle prese

2) ripulire i file temporanei

3) informare i propri figli che sta andando via

4) ripristinare le caratteristiche del terminale

e così via e così via e così via.

In genere, invia 15 e attendi un secondo o due, e se non funziona, invia 2 e, se non funziona, invia 1. In caso contrario, RIMUOVI IL BINARIO perché il programma si comporta male!

Non usare kill -9. Non tirare fuori la mietitrebbia solo per mettere in ordine il vaso di fiori.

Solo un altro uso inutile di Usenet,

(.firma)

Dovrebbe sempre essere OK fare kill -9, proprio come dovrebbe sempre essere OK per spegnere tirando il cavo di alimentazione. Potrebbe essere antisociale e lasciare un po 'di recupero da fare, ma dovrebbe funzionare ed è uno strumento di potere per gli impazienti.

Lo dico come qualcuno che proverà per primo a uccidere semplicemente (15), perché dà al programma la possibilità di fare un po 'di pulizia, forse semplicemente scrivendo su un registro "uscire da sig 15". Ma non accetterò alcuna lamentela riguardo i comportamenti scorretti su un'uccisione -9.

Il motivo: molti clienti lo fanno per le cose che i programmatori preferiscono, quindi non lo fanno. Il test di kill casuale -9 è uno scenario di test corretto ed equo, e se il tuo sistema non lo gestisce, il tuo sistema è rotto.

Uso kill -9 più o meno nello stesso modo in cui butto gli utensili da cucina in lavastoviglie: se un attrezzo da cucina viene rovinato dalla lavastoviglie, non lo voglio.

Lo stesso vale per la maggior parte dei programmi (anche i database): se non riesco a ucciderli senza cose che vanno in tilt, non voglio davvero usarli. (E se ti capita di usare uno di questi non database che ti incoraggia a fingere di avere dati persistenti quando non li hanno: beh, immagino sia giunto il momento di iniziare a pensare a quello che stai facendo).

Perché nel mondo reale le cose possono andare in qualsiasi momento per qualsiasi motivo.

Le persone dovrebbero scrivere software tollerante agli arresti anomali. In particolare sui server. Dovresti imparare come progettare software che presume che le cose si rompano, si arrestino in modo anomalo ecc.

Lo stesso vale per il software desktop. Quando voglio chiudere il mio browser di solito ci vuole AGES per chiudere. Non c'è niente di mio browser ha bisogno di farlo dovrebbe prendere più di al massimo un paio di secondi. Quando chiedo di spegnerlo dovrebbe riuscire a farlo immediatamente. Quando non lo fa, beh, quindi estraiamo kill -9 e lo facciamo.

Non menzionato in tutte le altre risposte è un caso in cui kill -9non funziona affatto, quando un processo è <defunct>e non può essere ucciso:

Come posso uccidere un processo <defunct> il cui genitore è init?

Cosa è defunto per un processo e perché non viene ucciso?

Quindi, prima di provare a eseguire kill -9un <defunct>processo ps -efper vedere qual è il suo genitore e provare -15(TERM) o -2(INT) e, infine, -9(KILL) sul suo genitore.

_{Nota: cosa ps -effa .}

_{Modifica e cautela successive: procedi con cautela durante l'uccisione dei processi, dei loro genitori o dei loro figli, perché possono lasciare file aperti o danneggiati, connessioni non finite, database corrotti ecc. A meno che tu non sappia cosa kill -9fa per un processo, utilizzalo solo come ultima risorsa e se è necessario eseguire kill, utilizzare i segnali sopra specificati prima dell'uso-9 (KILL)}

Non fare mai a kill -9 1. Evita anche di uccidere alcuni processi come mount`. Quando devo uccidere molti processi (ad esempio, una sessione X si blocca e devo uccidere tutti i processi di un determinato utente), invertisco l'ordine dei processi. Per esempio:

ps -ef|remove all processes not matching a certain criteria| awk '{print $2}'|ruby -e '$A=stdin.readlines; A.reverse.each{|a| puts "kill -9 #{a}"}'|bash

Tieni presente che killnon interrompe un processo e rilascia le sue risorse. Tutto ciò che fa è inviare un segnale SIGKILL al processo; potresti finire con un processo sospeso.

Uccidere i processi volenti o nolenti non è una mossa fluida: i dati possono essere persi, le app mal progettate possono rompersi in modi impercettibili che non possono essere riparati senza una reinstallazione .. ma dipende completamente dal sapere cosa è e cosa non è sicuro in un situazione data. e quale sarebbe a rischio. L'utente dovrebbe avere un'idea di cosa sia o dovrebbe essere un processo e quali siano i suoi vincoli (IOPS del disco, rss / swap) ed essere in grado di stimare quanto tempo dovrebbe impiegare un processo di lunga durata (ad esempio una copia del file, ricodifica mp3, migrazione e-mail, backup, [il tuo orario preferito qui].)

Inoltre, l'invio SIGKILLa un pid non è garanzia di uccisione. Se è bloccato in un syscall o è già zombied ( Zin ps), potrebbe continuare a essere zombied. Questo è spesso il caso di ^ Z, un processo che dura a lungo e che si dimentica bgprima di provare kill -9. Un semplice fgriconnetterà stdin / stdout e probabilmente sbloccherà il processo, di solito seguito dal termine del processo. Se è bloccato altrove o in qualche altra forma di deadlock del kernel, solo un riavvio potrebbe essere in grado di rimuovere il processo. (I processi di Zombie sono già morti dopo SIGKILLche il kernel è stato processato (non verrà eseguito nessun altro codice userland), di solito c'è un motivo del kernel (simile all'essere "bloccato" in attesa che un syscall finisca) che il processo non si concluda.)

Inoltre, se vuoi uccidere un processo e tutti i suoi figli, prendi l'abitudine di chiamare killcon il PID negato, non solo il PID stesso . Non vi è alcuna garanzia di SIGHUP, SIGPIPEo SIGINTo altri segnali di ripulitura dopo di esso, e avere un sacco di processi sconosciuti da ripulire (ricordi di Ibrido?) È fastidioso.

Bonus male: kill -9 -1è leggermente più dannoso di kill -9 1(Non fare come root a meno che tu non voglia vedere cosa succede su una macchina virtuale da buttare via non importante)

Perché non vuoi kill -9un processo normalmente

Secondo man 7 signal:

I segnali SIGKILL e SIGSTOP non possono essere catturati, bloccati o ignorati.

Ciò significa che l'applicazione che riceve uno di questi segnali non può "catturarli" per eseguire alcun comportamento di arresto.

Cosa dovresti fare prima di eseguire kill -9un processo

È necessario assicurarsi che prima di inviare il segnale al processo che:

1. Accertarsi che il processo non sia occupato (ovvero fare "lavoro"); l'invio di un kill -9processo comporterà essenzialmente la perdita di questi dati.
2. Se il processo è un database non responsive, assicurarsi di aver prima svuotato la cache. Alcuni database supportano l'invio di altri segnali al processo per forzare lo svuotamento della sua cache.

Ho creato uno script che aiuta ad automatizzare questo problema.

Si basa sulla mia risposta completa 2 in una domanda molto simile a StackOverflow .

Puoi leggere tutte le spiegazioni lì. Per riassumere, consiglierei solo SIGTERMe SIGKILL, o addirittura SIGTERM, SIGINTe SIGKILL. Comunque do più opzioni nella risposta completa.

Sentitevi liberi di scaricarlo (clonarlo) dal repository github su killgracefully 1