Como matar um processo <defunct> com o pai 1

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)

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.

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.

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

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.

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.

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.