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

Eu tenho um processo com o qual não posso matar kill -9 <pid>. Qual é o problema nesse caso, principalmente porque sou o proprietário desse processo. Eu pensei que nada poderia escapar dessa killopção.

kill -9( SIGKILL ) sempre funciona, desde que você tenha permissão para interromper 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 initprocesso).

No entanto, kill -9não é garantido que funcione imediatamente . Todos os sinais, incluindo o SIGKILL, são entregues de forma assíncrona: o kernel pode demorar para entregá-los. Geralmente, a entrega de um sinal leva no máximo alguns microssegundos, apenas o tempo necessário para o alvo obter uma fatia de tempo. No entanto, se o alvo tiver bloqueado o sinal , o sinal ficará na fila de espera até que o alvo o desbloqueie.

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 chamam chamadas do sistema . O código do kernel bloqueia todos os sinais ao interromper a chamada do sistema, resultando em uma estrutura de dados mal formada em algum lugar do kernel ou, mais geralmente, em alguma invariância do kernel sendo violada. Portanto, se (devido a um erro ou erro de design) uma chamada do sistema é bloqueada indefinidamente, pode não haver maneira de eliminar o processo. (Mas o processo será interrompido se alguma vez concluir a chamada do sistema.)

Um processo bloqueado em uma chamada do sistema está em suspensão ininterrupta . O comando psou top(na maioria das unidades) o mostrará em estado D(originalmente para " d isk", eu acho).

Um caso clássico de suspensão ininterrupta longa é o processo de acesso a 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 intropção mount permite que um sinal interrompa o acesso a arquivos NFS).

Às vezes, você pode ver entradas marcadas Z(ou Hno Linux, não sei qual é a distinção) na saída psou top. Tecnicamente, esses não são processos, são processos zumbis, que nada mais são do que uma entrada na tabela de processos, mantidos em torno para que o processo pai possa ser notificado da morte de seu filho. Eles desaparecem quando o processo pai presta atenção (ou morre).

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

• sendo zumbi. Ou seja, processo que o pai não leu o status de saída. Esse processo não consome nenhum recurso, exceto a entrada do PID. Em topque Z é sinalizado
• sono ininterrupto e errôneo. Isso não deveria acontecer, mas com uma combinação de código do kernel com bugs e / ou hardware com bugs, ocorre algum dia. O único método é reiniciar ou aguardar. Em topque é sinalizado por D.

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

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

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

Verifique seu /var/log/kern.loge /var/log/dmesg(ou equivalentes) em busca de pistas. Na minha experiência, isso aconteceu comigo apenas quando a conexão de rede de uma montagem NFS caiu de repente ou um driver de dispositivo travou. Poderia acontecer se um disco rígido travar também, acredito.

Você pode usar lsofpara ver quais arquivos de dispositivo o processo abriu.

Se as respostas de @ Maciej e @ Gilles não resolverem o seu problema e você não reconhecer o processo (e perguntar o que há na sua distribuição não gera respostas). Verifique o Rootkit e quaisquer outros sinais de que você pertence . Um rootkit é mais do que capaz de impedir que você interrompa o processo. De fato, muitos são capazes de impedir que você os veja. Mas se eles esquecerem de modificar 1 programa pequeno, poderão ser detectados (por exemplo, eles modificaram top, mas não htop). Provavelmente não é esse o caso, mas é melhor prevenir do que remediar.

Matar, na verdade, 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. caso contrário, o kernel lida com isso. para que você possa capturar um sinal em seu aplicativo.

Mas eu disse que matar -9 era especial. É especial porque o aplicativo não o entende. vai direto para o kernel, que realmente mata o aplicativo 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. Essa é a maneira mais fácil de dizer a um aplicativo que é hora de desligar. mas se o aplicativo não estiver respondendo, kill -9 o matará.

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 isso ter acontecido.

Primeiro, verifique se é um processo Zombie (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 ele possui um processo pai. Tente matar o ID do processo pai .

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

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

NOTA : Se ps -Al(ou top) mostrar um "D" em vez de "Z", isso poderá estar relacionado à montagem remota (como o NFS). Na minha experiência, a reinicialização é o único caminho a percorrer, mas você pode verificar as outras respostas que abordam esse caso em mais detalhes.

O processo init é imune ao SIGKILL.

Isso também é válido para os threads do kernel, ou seja, "processos" com um PPID igual a 0.

Como outros já mencionaram, um processo em sono ininterrupto não pode ser morto imediatamente (ou, em alguns casos, de maneira alguma). Vale ressaltar 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 http://lwn.net/Articles/288056/

Infelizmente, não acredito que isso seja usado em nenhum lugar do kernel, exceto no NFS.

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

Você pode usá-lo para eliminar qualquer processo com um determinado nome em seu caminho (preste atenção a isso !!) ou pode eliminar qualquer processo de um determinado usuário usando o parâmetro "-u nome de usuário".

#!/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

Há casos em que, mesmo que você envie um kill -9 para um processo, esse pid será interrompido, mas o processo será reiniciado automaticamente (por exemplo, se você tentar com gnome-panelele, será reiniciado): poderia ser esse o caso aqui?

a partir daqui originalmente :

verifique se strace mostra alguma coisa

strace -p <PID>

tente anexar ao processo com gdb

gdb <path to binary> <PID>

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

Eu tive esse problema. Este foi um programa que eu havia iniciado stracee interrompido com o Ctrl+ C. Acabou em um estado T(rastreado ou parado). Não sei exatamente como aconteceu, mas não foi matável SIGKILL.

Para encurtar a história, consegui matá-lo com gdb:

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

Com base em uma pista da resposta de gilles, eu tinha um processo marcado como "Z" no topo ( <defunct>em ps) que estava usando recursos do sistema, ele até tinha uma porta aberta que estava LISTEN'ing e você podia conectar-se a essa porta. Isso foi depois de executar um kill -9. Seu pai era "1" (ou seja init), então, teoricamente, deveria ser repetido e desaparecer. Mas não era, estava por aí, embora não estivesse correndo e "não morrendo"

Então, no meu caso, era zumbi, mas ainda consumia recursos ... FWIW.

E não era killable por qualquer número de kill -9's

E seu pai era, initmas não estava sendo colhido (limpo). Ou seja, initteve um filho zumbi.

E a reinicialização não era necessária para corrigir o problema. Embora uma reinicialização "tivesse funcionado" em torno do problema / o tornasse mais rápido. Apenas não gracioso, o que ainda era possível.

E era uma porta LISTEN de propriedade de um processo zumbi (e algumas outras portas também, como o status CLOSE_WAIT, conectavam host local a host local). E ainda aceitava conexões. Mesmo como um zumbi. Eu acho que ainda não havia conseguido limpar as portas, portanto as conexões recebidas ainda foram adicionadas ao backlog da porta de escuta do tcp, embora elas não tivessem chance de serem aceitas.

Muitos dos itens acima são declarados como "impossíveis" em vários lugares nas interwebs.

Acontece que eu tinha um encadeamento interno que estava executando uma "chamada de sistema" (ioctl nesta instância) que estava demorando algumas horas para retornar (esse era o comportamento esperado). Aparentemente, o sistema não pode matar o processo "até o fim" até retornar da ioctlchamada, suponha que entre no território do kernel. Depois de algumas horas, as coisas foram esclarecidas e as tomadas foram fechadas automaticamente, etc., conforme o esperado. Isso é algum tempo definhando no corredor da morte! O núcleo estava esperando pacientemente para matá-lo.

Então, para responder ao OP, às vezes você precisa esperar. Muito tempo. Então a matança finalmente levará.

Verifique também o dmesg para ver se houve um pânico no kernel (ou seja, bug do kernel).