E se 'kill -9' não funcionar?

Question

Eu tenho um processo que não posso matar com kill -9 <pid> . Qual é o problema em tal caso, especialmente desde que eu sou o dono desse processo. Eu pensei que nada poderia escapar dessa opção kill .

    

Answer 1

kill -9 ( SIGKILL ) sempre funciona, desde que você tenha permissão para matar o processo. Basicamente, o processo deve ser iniciado por você e não ser setuid ou setgid, ou você deve ser root. Há uma exceção: mesmo o root não pode enviar um sinal fatal para o PID 1 (o processo init ).

No entanto, kill -9 não tem garantia de funcionar imediatamente . Todos os sinais, incluindo o SIGKILL, são entregues de forma assíncrona: o kernel pode demorar para entregá-los. Normalmente, a entrega de um sinal leva no máximo alguns microssegundos, apenas o tempo que leva para o alvo obter um intervalo de tempo. No entanto, se o alvo tiver bloqueado o sinal , o sinal será enfileirado até target desbloqueia.

Normalmente, os processos não podem bloquear o SIGKILL. Mas o código do kernel pode, e os processos executam o código do kernel quando eles chamam chamadas do sistema . O código do kernel bloqueia todos os sinais ao interromper a chamada do sistema resultaria em uma estrutura de dados mal formada em algum lugar no kernel, ou mais geralmente em alguma invariante do kernel sendo violada. Portanto, se (devido a um bug ou má design) uma chamada do sistema for bloqueada indefinidamente, pode não haver maneira de eliminar o processo. (Mas o processo será eliminado se completar a chamada do sistema.)

Um processo bloqueado em uma chamada de sistema está em suspensão ininterrupta . O comando ps ou top irá (na maioria dos unices) mostrá-lo no estado D (originalmente para “ d isk”, eu acho).

Um caso clássico de sono longo e ininterrupto é o processo de acessar arquivos pelo NFS quando o servidor não está respondendo ; implementações modernas tendem a não impor suspensão ininterrupta (por exemplo, no Linux, a opção intr mount permite que um sinal interrompa os acessos a arquivos NFS).

Às vezes, você pode ver as entradas marcadas com Z (ou H no Linux, não sei qual é a diferença) na ps ou top output. Tecnicamente, estes não são processos, eles são processos zumbis, que nada mais são do que uma entrada na tabela de processos, mantida de forma que o processo pai possa ser notificado da morte de seu filho. Eles vão embora quando o processo pai presta atenção (ou morre).

    

Answer 2

Algum processo existe e não pode ser eliminado devido a:

• sendo zumbi. Ou seja processo qual pai não leu o status de saída. Esse processo não consome recursos, exceto a entrada PID. Em top é sinalizado Z
• sono ininterrupto errôneo. Isso não deve acontecer, mas com uma combinação de código buggy do kernel e / ou hardware com bugs que ele faz. O único método é reiniciar ou esperar. Em top é sinalizado por D.

Answer 3

Parece que você pode ter um processo zumbi . Isso é inofensivo: o único recurso que um processo de zumbi consome é uma entrada na tabela de processos. Ele desaparece quando o processo pai morre ou reage à morte de seu filho.

Você pode ver se o processo é um zumbi usando top ou o seguinte comando:

ps aux | awk '$8=="Z" {print $2}'

    

Answer 4

Verifique seus /var/log/kern.log e /var/log/dmesg (ou equivalentes) para quaisquer pistas. Na minha experiência, isso aconteceu comigo somente quando a conexão de rede de uma montagem NFS caiu repentinamente ou um driver de dispositivo falhou. Pode acontecer se um disco rígido travar também, eu acredito.

Você pode usar lsof para ver quais arquivos de dispositivos o processo abriu.

    

Answer 5

Se @ Maciej e @ A resposta de Gilles não resolve o seu problema , e você não reconhece o processo (e perguntando o que é com sua distro não aparece respostas). Verifique o Rootkit e quaisquer outros sinais que você tenha propriedade . Um rootkit é mais do que capaz de impedir que você mate o processo. Na verdade, muitos são capazes de impedir que você os veja. Mas se eles se esquecerem de modificar um programa pequeno, eles poderão ser localizados (por exemplo, eles modificaram top , mas não htop ). Muito provavelmente este não é o caso, mas é melhor prevenir do que remediar.

    

Answer 6

Matar significa enviar um sinal. Existem vários sinais que você pode enviar. kill -9 é um sinal especial.

Ao enviar um sinal, o aplicativo lida com ele. se não o kernel lida com isso. então você pode capturar um sinal em seu aplicativo.

Mas eu disse que kill -9 era especial. É especial que o aplicativo não consiga. ele vai direto para o kernel, que realmente mata a aplicação na primeira oportunidade possível. em outras palavras, mata-o morto

kill -15 envia o sinal SIGTERM que significa SIGNAL TERMINATE em outras palavras, diz ao aplicativo para sair. Esta é a maneira amigável de dizer a um aplicativo que é hora de desligar. mas se o aplicativo não estiver respondendo, kill -9 irá eliminá-lo.

se kill -9 não funcionar, provavelmente significa que seu kernel está fora de sintonia. uma reinicialização está em ordem. Não me lembro de que isso tenha acontecido.

    

Answer 7

Primeiro, verifique se é um processo zumbi (o que é muito possível):

ps -Al

Você verá algo como:

0 Z  1000 24589     1  0  80   0 -     0 exit   ?        00:00:00 soffice.bin <defunct>

(observe o "Z" à esquerda)

Se a quinta coluna não for 1, significa que ela tem um processo pai. Tente matar o ID do processo pai .

Se o seu PPID = 1, NÃO MATE-O !! , pense em quais outros dispositivos ou processos podem estar relacionados a ele.

Por exemplo, se você estava usando um dispositivo montado ou um samba, tente desmontá-lo. Isso pode liberar o processo de zumbis.

OBSERVAÇÃO : Se ps -Al (ou top ) mostrar um "D" em vez de "Z", isso pode estar relacionado à montagem remota (como NFS). Na minha experiência, a reinicialização é a única maneira de ir até lá, mas você pode verificar as outras respostas que abordam esse caso com mais detalhes.

    

Answer 8

Como outros já mencionaram, um processo no sono ininterrupto não pode ser morto imediatamente (ou, em alguns casos, em todos). Vale a pena notar que outro estado do processo, TASK_KILLABLE, foi adicionado para resolver esse problema em determinados cenários, particularmente no caso comum em que o processo está aguardando no NFS. Veja link

Infelizmente eu não acredito que isso seja usado em qualquer lugar no kernel, mas no NFS.

    

Answer 9

O processo de iniciação é imune a SIGKILL.

Isso também é verdade também para encadeamentos do kernel, ou seja, "processos" com um PPID igual a 0.

    

Answer 10

Fiz um pequeno roteiro que me ajudou muito a dar uma olhada!

Você pode usá-lo para matar qualquer processo com um determinado nome em seu caminho (preste atenção nisso !!) Ou você pode matar qualquer processo de um determinado usuário usando o parâmetro "-u username".

#!/bin/bash

if [ "$1" == "-u" ] ; then\n
        PID='grep "$2" /etc/passwd | cut -d ":" -f3'
        processes='ps aux | grep "$PID" | egrep -v "PID|ps \-au|killbyname|grep" | awk '{ print $2}''
        echo "############# Killing all processes of user: $2 ############################"
else
        echo "############# Killing processes by name: $1 ############################"
        processes='ps aux | grep "$1" | egrep -v "killbyname|grep" | awk '{ print $2}' '
fi


for process in $processes ; do
        # "command" stores the entire commandline of the process that will be killed
        #it may be useful to show it but in some cases it is counter-productive
        #command='ps aux | grep $process | egrep -v "grep" | awk '{ print $2 }''
        echo "Killing process: $process"
        echo ""
        kill -9 $process
done

    

Answer 11

Existem casos em que mesmo se você enviar um kill -9 para um processo, o pid parará, mas o processo será reiniciado automaticamente (por exemplo, se você tentar com gnome-panel , ele será reiniciado): o caso aqui?

    

Answer 12

de aqui originalmente :

verifique se o strace mostra alguma coisa

strace -p <PID>

tente anexar ao processo com o gdb

gdb <path to binary> <PID>

se o processo estiver interagindo com um dispositivo que você possa desmontar, remova o módulo do kernel ou desconecte / desconecte fisicamente ... tente isso.

    

Answer 13

Eu tive esse tipo de problema. Este foi um programa que eu tinha lançado com strace e interrompido com Ctrl + C . Ele acabou em um estado T (rastreado ou parado). Eu não sei como isso aconteceu exatamente, mas não foi eliminável com SIGKILL .

Resumindo, consegui matá-lo com gdb :

gdb -p <PID>
> kill
Kill the program being debugged? (y or n) y
> quit