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)