Como matar um processo <defunct> com o pai 1

17

Estou executando o Bacula em uma caixa RedHat. De tempos em tempos, o daemon de armazenamento bacula-sd para de funcionar e se torna <defunct>.

[root@backup ~]# ps -ef | grep defunct | more
root      4801 29261  0 09:25 pts/5    00:00:00 grep defunct
root      5825     1  0 Oct18 ?        00:00:00 [bacula-sd] <defunct>

Minha pergunta é: como posso matar esse processo? Seu pai é 1, que é init, tanto quanto eu sei, e eu não gostaria de matar o processo de init, gostaria?

"Normalmente" matar esse processo não funciona:

[root@backup ~]# kill -0 5825
[root@backup ~]# kill -9 5825

A ajuda é muito apreciada!

Editar: em execução

[root@backup ~]# lsof -p 5825

produz a seguinte saída:

COMMAND    PID USER   FD   TYPE  DEVICE     SIZE    NODE NAME
bacula-sd 5825 root  cwd    DIR   253,0     4096 3801089 /root
bacula-sd 5825 root  rtd    DIR   253,0     4096       2 /
bacula-sd 5825 root  txt    REG   253,0  2110599  368004 /usr/local/sbin/bacula-sd
bacula-sd 5825 root  mem    REG   253,0    75284  389867 /usr/lib/libz.so.1.2.3
bacula-sd 5825 root  mem    REG   253,0    46680 3604521 /lib/libnss_files-2.5.so
bacula-sd 5825 root  mem    REG   253,0   936908  369115 /usr/lib/libstdc++.so.6.0.8
bacula-sd 5825 root  mem    REG   253,0   125736 3606807 /lib/ld-2.5.so
bacula-sd 5825 root  mem    REG   253,0  1602128 3606885 /lib/libc-2.5.so
bacula-sd 5825 root  mem    REG   253,0   208352 3606892 /lib/libm-2.5.so
bacula-sd 5825 root  mem    REG   253,0   125744 3606887 /lib/libpthread-2.5.so
bacula-sd 5825 root  mem    REG   253,0    25940 3604573 /lib/libacl.so.1.1.0
bacula-sd 5825 root  mem    REG   253,0    15972 3604535 /lib/libattr.so.1.1.0
bacula-sd 5825 root  mem    REG   253,0    46548 3606908 /lib/libgcc_s-4.1.2-20080102.so.1
bacula-sd 5825 root  mem    REG   253,0 56422480  366368 /usr/lib/locale/locale-archive
bacula-sd 5825 root    0r   CHR     1,3             1545 /dev/null
bacula-sd 5825 root    1r   CHR     1,3             1545 /dev/null
bacula-sd 5825 root    2r   CHR     1,3             1545 /dev/null
bacula-sd 5825 root    3u   CHR   9,128             6469 /dev/nst0
bacula-sd 5825 root    4u  IPv4 1023380              TCP backup:bacula-sd (LISTEN)
bacula-sd 5825 root    5u  IPv4 2693268              TCP backup:bacula-sd->backup:53957 (CLOSE_WAIT)
bacula-sd 5825 root    7u  IPv4 3248683              TCP backup:bacula-sd->backup:57629 (CLOSE_WAIT)
bacula-sd 5825 root    8u  IPv4 3250966              TCP backup:bacula-sd->backup:37650 (CLOSE_WAIT)
bacula-sd 5825 root    9u  IPv4 3253908              TCP backup:bacula-sd->backup:37671 (CLOSE_WAIT)
linux process kill bacula andreas-h
fonte
Veja também unix.stackexchange.com/questions/5642/… e unix.stackexchange.com/questions/11172/…
rogerdpack

Respostas:

18

A única maneira de remover o processo zumbi / extinto seria matar o pai. Como o pai é init (pid 1), isso também derrubaria seu sistema.

Isso praticamente deixa você com duas opções.

  • Modifique manualmente a tabela de processos, por exemplo. crie um processo fictício, vincule o processo extinto como filho do fictício e mate-o. Muito perigoso, e talvez você precise limpar manualmente outros recursos do processo, como semáforos e identificadores de arquivo.
  • Reinicie o sistema.

Eu iria com o segundo.

Roy
fonte
2
+1. No entanto, não há pressa para fazê-lo, desde que mais processos de zumbis não apareçam ou seu processo de zumbis não tenha bloqueado 4G da sua RAM. :)
Kyle Smith
1
"Como o pai é init (pid 1), isso também derrubaria seu sistema" - Você não pode matar, initpois ele não possui um manipulador de sinal para o SIGKILL. Veja man 2 kill.
Cawflands
Como você faz o primeiro?
Skerit
@AndrewH Não tenho certeza se o SIGKILL depende de um manipulador de sinal no processo de destino, mas é verdade que o kernel típico ignora um SIGKILL para iniciar. No entanto, se você ficar sem maneiras mais legais de provocar um pânico no kernel, acho que descobrirá que na maioria dos sistemas Linux um SIGSEGV funcionará bem.
Roy
1
Deve-se notar que um dos inittrabalhos de é colher processos zumbis; portanto, se você esperar o suficiente, initdeverá limpar os processos zumbis. Embora, a maioria dos inits deve definir o manipulador de SIGCHLDcomo o SIG_IGN que corrige isso.
Cyphar # 12/15
3

Você pode tentar reiniciar o init:

 # telinit u

Caso contrário, eu não me preocuparia muito. Ele não está sendo executado e não está recebendo nenhum recurso, e está lá apenas para que o kernel possa se lembrar dele.

David Pashley
fonte
1
bem, eu meio que preciso me preocupar. é uma máquina de produção executando serviços de backup (bacula) e voip (asterisco). enquanto o processo bacula-sd extinta está lá, bacula não consigo acessar a unidade de fita ...
andreas-h
Não deve haver nenhum arquivo aberto. Execute lsof -p 5825 e verifique.
David Pashley
Bem, parece haver muitas coisas em aberto ... veja acima. Alguma idéia do que eu posso fazer? Eu nunca usei lsof ...
andreas-h
1
Sim, seu zumbi tem / dev / nst0 aberto. Uma reinicialização do sistema é provavelmente a melhor aposta neste momento.
22610 Kyle Smith
5
Sim, a reinicialização parece ser a resposta predominante. Eu sempre sinto que falhei quando tenho que reiniciar um servidor. :(
David Pashley
3

Verifique se houve um pânico no kernel, 

# dmesg |tail

Verifique se o processo está no modo "D" Suspensão inábil, onde está no modo kernel para algum syscall que ainda não retornou (seja o kernel oops ou outro motivo) http://www.nabble.com/What-causes-an -unificável-processo - td20645581.html

Pausado até novo aviso.
fonte
formatação irritante
asdmin 20/10/2009
na verdade, não houve pânico no kernel. processo está no estado 'Z' - um zumbi ...
andreas-h
3

Se um zumbi tem init como pai, então o init parou de funcionar corretamente. Um dos papéis do init é limpar zumbis. Se isso não acontecer, ninguém o fará. Portanto, a única solução é reiniciar. Se o init estiver quebrado, uma reinicialização poderá falhar, então eu desligaria serviços importantes, sincronizaria o sistema de arquivos e apertaria o botão liga / desliga.

MarkR
fonte
Concordo que o init não funcione corretamente. Veja também: upstarte systemd.
Mikko Rantalainen
2

Vamos manter o pânico baixo, não é? Um processo "extinto" ou "zumbi" não é um processo . É simplesmente uma entrada na tabela de processos, com um código de saída salvo. Assim, um zumbi não possui recursos, não realiza ciclos de CPU e não usa memória, pois não é um processo . Não fique esquisito e coceira ao tentar "matar" processos zumbis. Assim como seus nomes, eles não podem ser mortos, pois já estão mortos. Mas, diferentemente do tipo que come cérebro, eles não prejudicam absolutamente ninguém e não mordem outros processos.

Não deixe que processos zumbis comam seu cérebro. Apenas ignore-os.

Urso de pelúcia
fonte
11
Sim, essa é a teoria. Infelizmente, nem sempre é verdade. Às vezes, um processo extinto se apega aos recursos do sistema, como andreash documentou claramente.
Roy
5
No caso dele, de acordo com a saída lsof, o processo zumbi está comendo o cérebro de / dev / nst0. Ele precisa desses cérebros para continuar as operações de backup.
Kyle Smith
2
Um administrador de sistema que passa sua carreira ignorando os processos Zombie acabará acordando no meio da noite com sua vida sendo sugada para fora deles. Um zumbi é, na minha experiência, indicativo de algo errado. Eu os escrevo mesmo quando uma criança zumbi tem alguma interação estranha com seu pai, e o pai está girando minha CPU. Não sei de quem é a culpa, mas o ponto é que os zumbis são feios e ignorá-los um dia virá para assombrá-lo. ... Um dia ... quando você está dormindo pacificamente ... no meio da noite ... depois de um dia frio de outono ...
Mike S
@ MikeS Eu ri muito do seu comentário!
Paul Calabro
@MikeS tem razão. Eu tenho o ssh-agent desativado e o ssh nem o git não podem funcionar corretamente. somente reiniciar pode ajudar. (mesma correção como janelas tem ... haha)
John Tribe
0

Parece que você tem um processo órfão. Tanto quanto eu sei, a única maneira de matar estes seria reiniciar a caixa. Isso aconteceu nos meus servidores ESX (que são linux oculto) de tempos em tempos e uma reinicialização do host é a correção (do suporte da VMware).

Eu sou um cara do Windows, então leve isso para o que vale a pena.

Mrdenny
fonte
infelizmente, a reinicialização não é uma opção real. é uma máquina de produção também está executando serviços de VoIP, por isso não posso reiniciá-lo durante o horário de expediente ...
andreas-h
1
então, você pode reiniciá-lo após o horário comercial, certo?
Warren