kill -9 não funciona? Por que o processo não morre

2026-05-27

Se kill -9 não funciona, é porque o SIGKILL nunca chegou a nada vivo: o processo já é um zumbi, está preso no kernel em sono ininterrupto, ou um supervisor fica dando a ele um PID novo. ps -eo pid,ppid,stat,comm mostra qual dos três casos é o seu. Veja como ler isso e o que fazer em cada um.

1. Primeiro, descubra em que estado o processo está

clai

$ clai mostre o estado de um processo e o que ele está fazendo→ ps -eo pid,ppid,stat,comm | awk '$3 ~ /^Z/' 339320  339308 Z    sd_espeak-ng-mb1053146  902286 Z    headless_shell1053147  902286 Z    headless_shell

A primeira letra em STAT decide tudo. Z é zumbi, D é sono ininterrupto, S/R é um processo vivo que simplesmente está ignorando o sinal.

2. Veja o panorama de estados na máquina

clai

$ clai conte os processos por estado→ ps -eo stat --no-headers | cut -c1 | sort | uniq -c | sort -rn    588 S    141 I      4 Z      1 R

Alguns zumbis são normais — não ocupam nada além de uma entrada na tabela de processos. Milhares é bug num processo pai que nunca chama wait().

3. Não dá para matar um zumbi — ele já está morto

clai

$ clai encontre o pai do processo zumbi 339320→ ps -o ppid= -p 339320 339308

Um zumbi é o registro de um processo que já terminou e cujo pai nunca coletou com wait(). Mandar sinais para ele não faz nada — o problema é o pai. Quando o pai morre, o init adota o zumbi e limpa tudo.

4. D-state: o processo está preso dentro do kernel

clai

$ clai mostre os processos em sono ininterrupto e o que eles estão esperando→ ps -eo pid,stat,wchan:20,comm | awk '$2 ~ /^D/'

D significa que ele está esperando I/O dentro do kernel — geralmente um sistema de arquivos de rede travado ou um disco falhando. Um processo assim nem aceita SIGKILL, porque não está executando código de usuário. A coluna wchan mostra em que função do kernel ele está parado. Resolve-se na origem: remontar o NFS, trocar o disco. Às vezes só um reboot resolve.

5. O processo está vivo, mas algo continua reiniciando ele

clai

$ clai verifique se o systemd reinicia esse serviço depois que você mata ele→ systemctl show -p Restart -p RestartUSec app.service

Se o processo volta com um PID novo, você não está brigando com ele, e sim com o supervisor. Pare com systemctl stop, não com kill.

6. A sequência que realmente funciona

clai

$ clai pare o processo 12345 com cuidado, e force depois de 5 segundos se não sair→ kill 12345; sleep 5; kill -0 12345 2>/dev/null && kill -9 12345

Primeiro SIGTERM, para o processo fechar arquivos e esvaziar buffers. kill -0 não mata nada, só verifica se o processo ainda está vivo. SIGKILL é o último recurso — depois dele, o que estava nos buffers se perde.

Pegadinhas

kill -9 nunca chega ao processo — quem trata é o kernel. É exatamente por isso que ele é inútil contra o D-state: não tem quem trate o sinal, o processo não está executando código próprio.
Um zumbi não ocupa memória nem CPU. Ocupa uma entrada na tabela de processos e uma linha no ps. Não precisa entrar em pânico com três zumbis — é sintoma, não problema.
SIGKILL não dá ao processo nenhuma chance de encerrar direito. Buffers não gravados somem, travas continuam seguradas. Para bancos de dados e servidores de arquivos, isso é um risco real de corrupção de dados.

Perguntas relacionadas

Por que o kill -9 não funciona? Três motivos: o processo já é um zumbi (morto, não há nada para matar), está em D-state (não executa código de usuário), ou um supervisor está reiniciando ele.

Como matar todos os zumbis de uma vez? Direto não dá. Ache os pais deles com ps -eo ppid,stat | awk '$2 ~ /^Z/' e reinicie esses — ou espere eles mesmos chamarem wait().

Precisa reiniciar a máquina no D-state? Muitas vezes não. Primeiro resolva a causa da espera: restaure o sistema de arquivos de rede, cheque o dmesg por erros de disco. Reinicie só se a origem estiver inacessível.

Veja também

CliAI não conserta uma thread travada no kernel, mas evita que você fique adivinhando flags de ps e awk às 2 da manhã. Instale em uma linha.