"kill PID" não está realmente matando o processo, por quê?

Question

Estou tentando melhorar minhas habilidades de linha de comando e encontrei um problema em que não posso matar um processo. Eu digito kill 2200 onde 2200 é meu PID e o processo não é eliminado. Após alguns minutos, espera ainda em top e ps aux . Eu até tentei digitá-lo com o sudo - sem resultados.

Alguma idéia de por que seria assim?

EDITAR

Encontrei uma dependência estranha, em que fg atualiza a lista de processos:

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2200 pts/0    00:00:00 top
 2202 pts/0    00:00:00 top
 2258 pts/0    00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2200 pts/0    00:00:00 top
 2620 pts/0    00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2621 pts/0    00:00:00 ps

    

Answer 1

Os processos podem ignorar alguns sinais. Se você enviar SIGKILL, ele não poderá ignorá-lo (e tampouco pegá-lo para fazer limpezas). Experimente:

kill -9 {PID}

Saiba mais lendo a página de manual:

man kill

    

Answer 2

Se kill for chamado sem nenhum parâmetro, ele envia o número de sinal 15 ( SIGTERM ). Este sinal pode ser ignorado pelo processo. Este sinal notifica o processo para limpar suas coisas e depois terminar corretamente sozinho. Essa é a maneira legal.

Você também pode "enviar" o número de sinal 9 ( SIGKILL ) que não pode ser ignorado pelo processo. O processo não irá reconhecê-lo, porque o kernel encerra o processo, não o processo em si. Essa é a maneira má.

Um diz que kill -9 <pid> sempre funciona. Essa é uma falta de fé . Existem situações em que mesmo kill -9 não mata o processo. Por exemplo, quando um processo tem o estado D (suspensão ininterrupta). Um processo entra nesse estado toda vez que ele espera por E / S (normalmente não muito tempo). Portanto, se um processo aguardar E / S (em um disco rígido defeituoso, por exemplo) e ele não estiver programado corretamente (com um tempo limite), você simplesmente não poderá eliminar o processo . Não importa o que você faça. Você só pode tentar tornar o arquivo acessível que o processo continue.

    

Answer 3

Apesar de o nome kill não matar processos, ele envia sinais para ele. Na página do manual:

kill - send a signal to a process

O sinal padrão enviado por kill [pid] é SIGTERM que geralmente, mas não necessariamente, solicita que o processo termine. É bem possível escrever um programa que tenha uma melodia feliz quando você envia o sinal SIGTERM para ele, mas não é recomendado.

Outro sinal comum é o SIGHUP , que é freqüentemente usado para solicitar que um programa releia seus arquivos de configuração.

Se você realmente quer matar um programa, você precisa usar o sinal SIGKILL fazendo kill -9 [pid] .

    

Answer 4

Parece que você pode estar suspendendo um processo (talvez pressionando Ctrl-Z no terminal). Nesse estado, seu processo não responderá a um SIGTERM quando estiver congelado. Correndo 'fg' descongela o processo, assim ele pode pegar o sinal e auto-terminar. Isso poderia explicar por que 'fg' parece atualizar a lista de processos.

    

Answer 5

De dentro do C ++, executei:

kill(4024, SIGKILL);

E em um terminal linux (Ubuntu),

$ ps -ax | grep my_su

A saída foi:

4024 pts/1    Z+     0:00 [my_subscriber] <defunct>

Aparentemente, (4024) ainda sobrevive. No entanto, assim que terminei o processo pai que chamou a instrução "kill" acima, 4024 não apareceu mais. Agora eu julgo processo "extinto" é nada mais do que uma linha exibida e decidiu ignorá-lo. Espero que minha experiência possa ajudar alguém lá fora. Felicidades!