Quando não devo matar -9 um processo?

384

Estou sempre muito hesitante em executar kill -9 , mas vejo outros administradores fazendo isso quase rotineiramente.

Eu acho que provavelmente existe um meio-termo sensato, então:

  1. Quando e por que kill -9 deve ser usado? Quando e porque não?
  2. O que deve ser tentado antes de fazer isso?
  3. Que tipo de depuração de um processo "suspenso" poderia causar mais problemas?
por Mikel 09.03.2011 / 11:13

9 respostas

346

Geralmente, você deve usar kill (abreviação de kill -s TERM ou na maioria dos sistemas kill -15 ) antes de kill -9 ( kill -s KILL ) para dar ao processo de destino uma chance de limpeza após ele mesmo. (Processos não podem pegar ou ignorar SIGKILL , mas eles podem e geralmente captam SIGTERM .) Se você não der ao processo uma chance de terminar o que está fazendo e limpar, ele pode deixar arquivos corrompidos (ou outro estado) que não será capaz de entender uma vez reiniciado.

strace / truss , ltrace e gdb são geralmente boas ideias para analisar por que um processo travado está preso. ( truss -u no Solaris é particularmente útil; acho que ltrace apresenta argumentos para chamadas de biblioteca em um formato inutilizável.) O Solaris também possui ferramentas úteis baseadas em /proc , algumas das quais foram portadas para o Linux. ( pstack costuma ser útil).

    
por 09.03.2011 / 11:26
220

Randal Schwartz costumava postar "Useless use of (x)" nas listas. Um desses posts foi sobre kill -9 . Inclui razões e uma receita a seguir. Aqui está uma versão reconstruída (citada abaixo ).

(Quote abomination)

No no no. Don't use kill -9.

It doesn't give the process a chance to cleanly:

1) shut down socket connections

2) clean up temp files

3) inform its children that it is going away

4) reset its terminal characteristics

and so on and so on and so on.

Generally, send 15, and wait a second or two, and if that doesn't work, send 2, and if that doesn't work, send 1. If that doesn't, REMOVE THE BINARY because the program is badly behaved!

Don't use kill -9. Don't bring out the combine harvester just to tidy up the flower pot.

Just another Useless Use of Usenet,

(.signature)

    
por 09.03.2011 / 13:29
73

Deve estar sempre OK fazer kill -9 , assim como deve estar sempre OK desligar desligando o cabo de alimentação. Pode ser anti-social, e deixar alguma recuperação para fazer, mas deve funcionar, e é uma ferramenta poderosa para o impaciente.

Eu digo isso como alguém que tentará o plain kill (15) primeiro, porque ele dá ao programa uma chance de fazer alguma limpeza - talvez apenas escrevendo para um log "saindo em sig 15". Mas eu não vou aceitar nenhuma queixa sobre mau comportamento em um kill -9.

O motivo: muitos clientes fazem isso para coisas que os programadores prefeririam, então não. O teste random-kill kill -9 é um bom e justo cenário de teste, e se o seu sistema não lidar com isso, seu sistema está quebrado.

    
por 28.01.2014 / 07:11
37

Eu uso kill -9 da mesma maneira que eu jogo utensílios de cozinha na lava-louças: se um utensílio de cozinha for arruinado pela máquina de lavar louças, então eu não o quero.

O mesmo vale para os programas mais (bancos de dados pares): se eu não puder matá-los sem que as coisas fiquem descontroladas, eu realmente não quero usá-los. (E se acontecer de você usar um desses não-bancos de dados que encoraja você a fingir que eles persistiram dados quando eles não têm: bem, eu acho que é hora de você começar a pensar sobre o que você está fazendo).

Porque no mundo real as coisas podem cair a qualquer momento por qualquer motivo.

Pessoas devem escrever softwares tolerantes a falhas. Em particular nos servidores. Você deve aprender a projetar software que pressupõe que as coisas vão quebrar, bater, etc.

O mesmo vale para software de desktop. Quando eu quero desligar meu navegador, normalmente ele leva o AGES para desligar. Não há nada meu navegador precisa para fazer isso deve demorar mais do que alguns segundos. Quando eu pedir para desligar, deve conseguir fazer isso imediatamente. Quando isso não acontece, bem, então nós tiramos o kill -9 e o fazemos.

    
por 28.01.2014 / 16:46
9

Não mencionado em todas as outras respostas é um caso em que kill -9 não funciona, quando um processo é <defunct> e não pode ser eliminado:

Como posso matar uma tag < defunct > processo cujo pai é init?

O que é extinto por um processo e por que não é morto?

Portanto, antes de tentar kill -9 a <defunct> processar, execute ps -ef para ver o que é seu pai e tente -15 (TERM) ou -2 (INT) e, por último, -9 (KILL) em seu pai.

Nota: que ps -ef faz .

Edição posterior e cautela: Prossiga com cuidado ao matar processos, seus pais ou seus filhos, porque eles podem deixar arquivos abertos ou corrompidos, conexões inacabadas, podem corromper bancos de dados, etc, a menos que você saiba o que kill -9 faz para um processo, use-o apenas como último recurso, e se você precisar executar kill use os sinais especificados acima antes de usar -9 (KILL)

    
por 28.01.2014 / 16:17
6

Nunca faça um kill -9 1 . Também evite matar alguns processos como o mount '. Quando eu tenho que matar muitos processos (digamos, por exemplo, uma sessão X fica suspensa e eu tenho que matar todos os processos de um determinado usuário), eu inverto a ordem dos processos. Por exemplo:

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

Lembre-se de que kill não interrompe um processo e libera seus recursos. Tudo o que faz é enviar um sinal SIGKILL para o processo; você pode acabar com um processo pendente.

    
por 09.03.2011 / 11:29
5

Matar processos a qualquer momento não é uma tarefa fácil: os dados podem ser perdidos, aplicativos mal projetados podem se quebrar de maneiras sutis que não podem ser corrigidas sem uma reinstalação ... mas depende completamente de saber o que é e o que não é seguro em uma determinada situação.  e o que estaria em risco. O usuário deve ter alguma idéia do que um processo é, ou deveria ser, fazer e quais são as restrições (IOPS de disco, rss / swap) e ser capaz de estimar quanto tempo um processo demorado deve demorar (digamos, uma cópia de arquivo, reencoding mp3, migração de e-mail, backup, [seu tempo favorito aqui].

Além disso, enviar SIGKILL para um pid não é garantia de eliminá-lo. Se ele estiver preso em um syscall ou já estiver zumbido ( Z in ps ), ele pode continuar sendo zumbido. Este é frequentemente o caso de ^ Z um longo processo em execução e esquecendo-se de bg antes de tentar kill -9 it. Um simples fg irá reconectar stdin / stdout e provavelmente desbloqueará o processo, geralmente seguido pelo processo que termina. Se estiver preso em outro lugar ou em alguma outra forma de deadlock do kernel, apenas uma reinicialização poderá remover o processo. (Processos zumbis já estão mortos após SIGKILL ser processado pelo kernel (nenhum código userland será executado), geralmente há uma razão de kernel (semelhante a ser "bloqueado" aguardando o syscall terminar) para o processo não terminar.)

Além disso, se você quiser matar um processo e todos os seus filhos, crie o hábito de chamar kill com o PID negado, não apenas com o próprio PID . Não há garantia de SIGHUP , SIGPIPE ou SIGINT ou outros sinais sendo limpos depois disso, e ter um monte de processos rejeitados para limpeza (lembre-se de vira-lata?) É irritante.

Bônus maligno: kill -9 -1 é um pouco mais prejudicial do que kill -9 1 (Não faça como root, a menos que você queira ver o que acontece em uma VM não importante descartável)

    
por 25.05.2014 / 03:33
3

Por que você não quer kill -9 de um processo normalmente

De acordo com man 7 signal :

The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.

Isso significa que o aplicativo que recebe um desses sinais não pode "capturá-los" para fazer qualquer comportamento de desligamento.

O que você deve fazer antes de executar kill -9 em um processo

Você deve se certificar de que antes de enviar o sinal para o processo que você:

  1. Assegure-se de que o processo não esteja ocupado (isto é, "trabalhe"); enviar um kill -9 para o processo essencialmente resultará na perda desses dados.
  2. Se o processo for um banco de dados não responsivo, certifique-se de que ele tenha liberado seus caches primeiro. Alguns bancos de dados suportam o envio de outros sinais ao processo para forçar o fluxo de seu cache.
por 24.05.2014 / 18:07
3

Eu criei um script que ajuda a automatizar esse problema.

É baseado na minha resposta completa 2 em uma pergunta muito semelhante em stackoverflow .

Você pode ler todas as explicações lá. Para resumir, eu recomendaria apenas SIGTERM e SIGKILL ou mesmo SIGTERM , SIGINT e SIGKILL . No entanto, dou mais opções na resposta completa.

Por favor, sinta-se à vontade para fazer o download (clone) do repositório do github repositório para killgracefully 1

    
por 08.06.2016 / 06:54