it-swarm.it

Quando non dovrei uccidere -9 un processo?

Sono sempre molto restio 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 -9 essere 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?
405
Mikel

Generalmente, dovresti usare kill (abbreviazione di kill -s TERM, O sulla maggior parte dei sistemi kill -15) Prima di kill -9 (kill -s KILL) Per dare il processo target una possibilità di ripulire dopo se stesso. (I processi non possono catturare o ignorare SIGKILL, ma possono e spesso catturano SIGTERM.) Se non dai al processo la possibilità di finire ciò che sta facendo e ripulirlo, potrebbe lasciare in giro file corrotti (o altri stati) che non sarà in grado di capire una volta riavviati.

strace/truss, ltrace e gdb sono generalmente buone idee per capire perché un processo bloccato è bloccato. (truss -u Su Solaris è particolarmente utile; trovo che ltrace troppo spesso presenti argomenti alle chiamate in libreria in un formato inutilizzabile.) Solaris ha anche utili strumenti basati su /proc, Alcuni dei che sono stati portati su Linux. (pstack è spesso utile).

366
geekosaur

Randal Schwartz pubblicava spesso "L'uso inutile di (x)" nelle liste. Uno di questi post riguardava kill -9. Include motivi 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)

230
Shawn J. Goff

Dovrebbe sempre essere OK fare kill -9, proprio come dovrebbe sempre essere OK per lo spegnimento tirando il cavo di alimentazione. Può 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.

77
dbrower

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 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.

Persone dovrebbe 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. C'è niente il mio browser necessita per fare ciò dovrebbe richiedere 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.

39
borud

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

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

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

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

Nota: cosa fa ps -ef .

Modifica e cautela successive: Procedere con cautela quando si uccidono i processi, i loro genitori o i loro figli, perché possono lasciare file aperti o danneggiati, connessioni non finite, possono corrompere database ecc. a meno che tu non sappia cosa fa kill -9 per un processo, usalo solo come ultima risorsa, e se devi eseguire kill usa i segnali sopra specificati prima di usare -9 (KILL)

10

Non fare mai un 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 kill non arresta un processo e rilascia le sue risorse. Tutto ciò che fa è inviare un segnale SIGKILL al processo; potresti finire con un processo sospeso.

6
HandyGandy

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, inviare SIGKILL a un pid non è garanzia di ucciderlo. Se è bloccato in un syscall o è già zombied (Z in ps), potrebbe continuare a essere zombied. Questo è spesso il caso di ^ Z un lungo processo in corso e dimenticare di bg prima di provare a kill -9 esso. Un semplice fg riconnetterà 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 che SIGKILL è stato elaborato dal kernel (non verrà eseguito nessun altro codice userland), di solito c'è un motivo del kernel (simile all'essere "bloccato" in attesa che una syscall finisca) per il processo no terminazione.)

Inoltre, se vuoi terminare un processo e tutti i suoi figli, prendi l'abitudine di chiamare kill con il PID negato, non solo il PID stesso. Non vi è alcuna garanzia di SIGHUP, SIGPIPE o SIGINT o di 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 eseguire operazioni di root a meno che tu non voglia vedere cosa succede in una VM non importante e usa e getta)

5
dhchdhd

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 SIGTERM e SIGKILL, o anche SIGTERM, SIGINT e SIGKILL. Comunque do più opzioni nella risposta completa.

Per favore, sentiti libero di scaricarlo (clonarlo) dal github repository to killgracefully1

3
Dr Beco

Perché non vuoi kill -9 un 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 -9 su un processo

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

  1. Accertarsi che il processo non sia occupato (ovvero fare "lavoro"); invio di un kill -9 al processo 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.
3
user26053