'[java] defunct' com filhos defuntos - Qualquer maneira de coletá-los?

Question

Relacionado à pergunta: E se 'kill -9' não funcionar?

Eu tenho a seguinte situação: processo zumbi com threads, não coletado pelo init :

[root@Arch64]# ps auxH | grep java
gwpl       569  0.0  0.0      0     0 ?        Zl   04:23   0:00 [java] <defunct>
gwpl       569  5.5 49.0 1466648 375572 ?      Rl   07:25  23:55 [java] <defunct>
gwpl       569 16.0 49.0 1466648 375572 ?      Rl   12:27  20:54 [java] <defunct>
gwpl       569 17.9 49.0 1466648 375572 ?      Rl   12:47  19:48 [java] <defunct>
root     10466  0.0  0.0   6740   628 pts/0    S+   14:38   0:00 grep java
[root@Arch64]# pstree -s 569
init---java---3*[{java}]

Posso fazer algo sobre isso?

Ou é um bug init como sugerido no comentário ao link ?

Se for um bug, o que devo fazer para ajudar a corrigi-lo?

A listagem acima usa os seguintes códigos de status: Zl , Rl , S+ . Aqui está uma planilha de cheats de man ps para decodificá-los:

PROCESS STATE CODES
       (...)
       R    Running or runnable (on run queue)
       S    Interruptible sleep (waiting for an event to complete)
       (...)
       Z    Defunct ("zombie") process, terminated but not reaped by its parent.

       For BSD formats and when the stat keyword is used, additional characters may be displayed:
       (...)
       L    has pages locked into memory (for real-time and custom IO)
       (...)
       +    is in the foreground process group

    

Answer 1

Isso provavelmente é tarde demais para fazer alguma coisa boa, mas eu tenho que me perguntar se talvez o processo 569 não seja inteiramente um zumbi. Talvez isso seja o que você obtém nesse sistema operacional (qual SO é esse?) Quando o encadeamento inicial foi finalizado, mas outros encadeamentos ainda estão em execução. Se for esse o caso, kill(1) ainda deve ser eficaz. Se não for, a próxima coisa que eu tentaria é usar tgkill(2) , ou o equivalente do seu sistema operacional, em os encadeamentos listados no estado-R (isso exigirá que você escreva algum C, pois provavelmente não existem utilitários de shell enlatados para invocar essas chamadas de sistema).

Além disso, tentar anexar strace ou gdb ao processo pode revelar algo útil para o diagnóstico.

Um erro na coleta de zumbis de init é extraordinariamente improvável; se isso é um bug, eu diria que é mais provável que seja um bug kernel no qual processos multithread são (sob algumas condições) não descartados apropriadamente.

    

Answer 2

O Init sempre aguarda, vai o velho ditado. Então, um bug no kernel é bastante improvável. Qual é o ppid do processo 569? ps -alef lhe daria isso, ou, se você for da persuasão do BSD, ps axo stat,pid.ppid,comm . Se o pai não é init, 569 é provavelmente um Zumbi comum. E como os zumbis são perigosos quando há muitos deles , você pode deixar este ficar parado no canto e ter a próxima reinicialização descartada.