Maneira alternativa de matar um processo de zumbi


19

Acabei de notar alguns processos zumbis no CentOS 6.8 (Final), tentei matá-los, mas eles ainda estão lá:

[root@host user]# ps -ef | grep git
tomcat     746     1  0 Jul18 ?        00:00:00 git clone https://github.com/angular/bower-angular.git -b v1.3.20 --progress . --depth 1
tomcat     747   746  0 Jul18 ?        00:00:00 [git-remote-http] <defunct>
root     20776 20669  0 09:03 pts/3    00:00:00 grep git
tomcat   29970     1  0 Jul18 ?        00:00:00 git clone https://github.com/components/jqueryui.git -b 1.12.0 --progress . --depth 1
tomcat   29971 29970  0 Jul18 ?        00:00:00 [git-remote-http] <defunct>

[root@host user]# kill 746 747 29970 29971

[root@host user]# ps -ef | grep git
tomcat     746     1  0 Jul18 ?        00:00:00 git clone https://github.com/angular/bower-angular.git -b v1.3.20 --progress . --depth 1
tomcat     747   746  0 Jul18 ?        00:00:00 [git-remote-http] <defunct>
root     21525 20669  0 09:26 pts/3    00:00:00 grep git
tomcat   29970     1  0 Jul18 ?        00:00:00 git clone https://github.com/components/jqueryui.git -b 1.12.0 --progress . --depth 1
tomcat   29971 29970  0 Jul18 ?        00:00:00 [git-remote-http] <defunct>

Como você pode ver, eles estão funcionando por dois meses, e também, se não forem prejudiciais, eu me livraria deles, alguma maneira alternativa de matar um zumbi?


11
você já tentou kill -9?
Ipor Sircer 19/09/16

7
Somente 747e 29971são processos zumbis. Os outros podem estar trancados, mas ainda não estão mortos.
roaima 19/09/16

Parece que você tem um bug em algum código em execução no tomcat ...
Boris a aranha

Respostas:


8

Como mencionado por Heemayl, você não pode realmente matar um zumbi. Já está [des] morto ...

No entanto, o problema que você está enfrentando parece um problema com o git clonecomando. Fica preso de alguma forma. Provavelmente atinge o tempo limite ou falha de alguma outra maneira? Geralmente, devido a algumas E / S, um processo fica preso ao ponto em que a SIGTERMe SIGINTnão funciona.

Para matá-lo, nesse caso, você deseja usar a -9opção de linha de comando. Isso significa enviar o SIGKILLsinal. Você pode realmente usar -KILLtambém.

[root@host user]# kill -KILL 746 29970

Para obter uma lista dos sinais disponíveis, use a opção de linha de comando list.

[root@host user]# kill -l

Isso mostra os números e nomes (e você verá que o nº 9 diz SIGKILL.)


11
Na verdade, kill -KILLfoi o único comando capaz de fechar esses processos, por esse motivo, vou aceitar a resposta do @Alexis Wilke. Mas certamente gostaria de expressar minha gratidão à resposta rápida, sábia e muito informativa @heemayl +1. Obrigado a todos
lese

39

Você não pode matar um zumbi (processo), ele já está morto. Ele está apenas aguardando o processo pai executar wait(2)e coletar seu status de saída. Não será necessário nenhum recurso no sistema além de uma entrada da tabela de processos.

Você pode enviar SIGCHLDao pai ou mãe para que ele saiba que um de seus filhos terminou (ou seja, solicite que ele colete o status de saída do filho). Este sinal pode ser ignorado (que é o padrão):

kill -CHLD <PPID>

(Substitua <PPID>pelo PID real do pai.)

Ou você pode matar o processo pai para que init(PID 1) herde o processo zumbi e o colha corretamente (é uma das initprincipais tarefas de herdar qualquer órfão e fazê-lo wait(2)regularmente). Mas matar os pais não é recomendado. Geralmente, a criação de processos zumbis indica problemas de programação, e você deve tentar consertar ou reportar isso.


8
Você pode enviar o SIGCHLD para seu pai para que ele saiba que, se um filho tiver terminado (ou seja, solicitar que ele colete o status de saída do filho), esse sinal pode ser ignorado (padrão) O problema é que, se um processo ignorar SIGCHLD, nenhum zumbi seria criado. Portanto, se não está ignorando SIGCHLDe os zumbis não estão sendo colhidos, o processo é de buggy ou não se importa com crianças zumbis. Dado que o processo em questão é git clone ..., aposto que ele simplesmente não se importa com crianças zumbis, já que é um processo de vida curta (espero) que faz seu trabalho e depois sai.
Andrew Henle

11
@AndrewHenle: Embora isso seja verdade, a ação padrão ( SIG_DFL) SIGCHILDtambém é ignorá-la, mas nesse caso os zumbis certamente não são colhidos automaticamente.
R ..

@R Embora isso seja verdade, a ação padrão ( SIG_DFL) para SIGCHILDtambém é ignorá-la, mas neste caso os zumbis certamente não são colhidos automaticamente. Não sei ao que você está se referindo. Você está se referindo aos processos que não estão sendo colhidos na pergunta? Não estou vendo como o envio SIGCHLDpara um processo cujo SIGCHLDmanipulador está definido como SIG_IGN(explicitamente ou por padrão) fará com que esse processo colha zumbis.
Andrew Henle

11
@AndrewHenle, enviar um SIGCHLDpode funcionar desta vez . A última vez que ele perdeu o sinal ou duas crianças morreram ao mesmo tempo e o código não é inteligente o suficiente para lidar com as duas mortes simultaneamente.
Alexis Wilke

Não pode doer, mas eu não apostaria nisso.
Barmar 22/09/16

2

procurar processos zumbis:

ps aux | grep -w Z | grep -v grep

ps -eo stat,ppid | grep -w Z

para matar o processo zumbi, os IDs pai precisam ser mortos, ou seja, PPID:

kill PPID1 PPID2

kill $(ps -eo stat,ppid|grep -w Z|awk '{print $2}'|tr "\n" " ")

0

Quando um processo pai morre, todo o processo zumbi é limpo. Não mate o processo pai apenas para limpar o processo zumbi. Ele voltará quando você executar novamente o seu programa. Corrija seu programa chamando corretamente a chamada de sistema "wait ()" ou "waitpid ()".

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.