É um sinal de processo zumbi persistente de um bug?

Question

(SO: variante do Debian)

Ter um processo com status de zumbi. O PPid pertencia a um processo gvim . O conteúdo de /proc/[pid]/wchan é do_exit , /comm é sh e /cmdline está vazio, /status é mostrado abaixo.

Isso pode ser um bug em gvim ? A partir da entrada da Wikipedia em Processo Zombie eu li que um programa pode voluntariamente rejeitar para chamar wait mas isso foi por um gvim session que ficou inativa por algum tempo. Eu fechei o processo gvim - mas o zumbi ainda espreita por aí. Isso pode indicar um bug do sistema operacional?

Novamente na Wikipedia:

If the parent program is no longer running, zombie processes typically indicate a bug in the operating system.

E com que frequência init colhe processos abandonados? Tem sido pelo menos 60 minutos desde o desaparecimento de gvim , mas ainda está lá.

Por outro lado, poderia ser sh e não gvim ?

O arquivo /status indica SigQ de zero.

$ less /proc/30339/status
Name     : sh
State    : Z (zombie)
Tgid     : 30339
Pid      : 30339
PPid     : 29673
TracerPid:     0
Uid      :  1000    1000    1000    1000
Gid      :  1000    1000    1000    1000
FDSize   :     0
Groups   :     4 7 20 24 27 29 30 46 107 124 127 1000 
Threads  :     1
SigQ     : 0/30658
SigPnd   : 0000000000000000
ShdPnd   : 0000000000000000
SigBlk   : 0000000000000000
SigIgn   : 0000000000003001
SigCgt   : 0000000000010002
CapInh   : 0000000000000000
CapPrm   : 0000000000000000
CapEff   : 0000000000000000
CapBnd   : ffffffffffffffff
Cpus_allowed     :   3
Cpus_allowed_list:   0-1
Mems_allowed     :   1
Mems_allowed_list:   0
voluntary_ctxt_switches   :   2
nonvoluntary_ctxt_switches:   3

Não que destrua meu sono de beleza, mas me pergunto ...

    

Answer 1

Ver zumbis tende a indicar um bug no processo que os gerou: esse processo deve colher os zumbis (chamando wait ) ou ignorar explicitamente SIGCLD (ou definir o SA_NOCLDWAIT flag).

No entanto, este é um pequeno bug. Os processos zumbis consomem apenas uma entrada na tabela de processos, que é uma quantidade insignificante de recursos. O problema só se torna significativo se um processo deixar milhares de zumbis para trás.

Você não matou o processo pai do zumbi: caso contrário, o zumbi teria ido embora. O processo 29673 (pai do zumbi) ainda está vivo e chutando (mas não wait ing). Ou isso não é o Gvim, mas algum subprocesso dele, ou você fechou uma janela do Gvim, mas o programa ainda está em execução. Execute ps l 29673 para ver o que é esse processo.

    

Answer 2

Se você está continuamente encontrando um processo zumbi, eu ficaria inclinado a pensar que definitivamente há algo errado. O processo de zumbis ocorre. Eu geralmente vejo alguns meses nos vários sistemas que mantenho tanto no trabalho como em casa.

Geralmente, eles podem ser contabilizados devido a erros do operador ou a um problema com um determinado software. As reinicializações geralmente as resolvem e normalmente não ocorrem novamente por algum tempo.

Se eles estiverem incomodando você, você pode tentar anexar ao ID do processo pai (PPID) usando gdb para ver o que está acontecendo ou até mesmo tentar matá-los:

$ gdb -p 100
(gdb) call waitpid(200, 0, 0)
(gdb) quit

Se você quiser, eu li esses recursos adicionais abaixo para outras técnicas sobre como tentar lidar com eles.

Referências

• O que é um processo zumbi e como eu mato?
• O gdb pode anexar um processo zumbi ()?
• O caminho certo para lidar com processos congelados no Unix

Answer 3

Isso acontece toda vez que você usa o gvim? O gvim trabalha além de deixar um zumbi depois que ele sai? A menos que cause problemas reais, eu simplesmente o ignoraria - os zumbis não taxam os recursos do sistema. Eu não ficaria surpreso se fosse um bug no gvim - ou talvez no gtk, mas a menos que o programa não funcione, eu o ignoraria.

Um processo zumbi / defunto normalmente ocorre quando um processo-filho sai antes que o pai comece a ouvi-lo. A criança "fica por perto" porque não havia nenhum programa por perto para receber seu status de saída, embora tenha terminado satisfatoriamente - por isso se torna um zumbi. Outra razão pela qual você obtém zumbis, pode ser quando uma grande árvore de processo desmorona - talvez porque alguém tenha tentado matar um ou mais processos na árvore.

Um zumbi é realmente uma maneira de o sistema operacional manter o status de saída e outras informações sobre um processo que não foi finalizado corretamente, no caso de alguém estar interessado. Além de uma entrada na tabela de processos, um zumbi não usa recursos (ou seja, sem memória ou cpu).

IMHO WikiPedia está errado - ou pelo menos é fácil interpretar mal - quando afirma que zumbis não colhidos significam um erro no sistema operacional se eles permanecerem após o processo principal que foi gerado pelas saídas. Não é incomum que um zumbi sobreviva aos pais, caso em que é adotado por init (PID 1). O init pode eventualmente colher, mas alguns zumbis - mesmo aqueles adotados pelo init - podem muito bem permanecer até a reinicialização. Contanto que você não tenha tantos zumbis que eles preencham a tabela de processos, eles dificilmente serão um problema.

É claro que zumbis costumam significar que algo está errado - que um programa gera uma criança que morre antes que o pai espere - mas não precisa ser o sistema operacional que é o problema. Certamente pode ser componentes do sistema operacional que causam isso - por exemplo. um servidor de som ausente ou mal configurado, faz com que um processo filho processe o som para que um programa saia imediatamente, permanecendo como zumbis.

    

Answer 4

Como sempre - isso depende. A maioria das ferramentas de monitoramento ficará amarela ou vermelha, pois encontrará mais do que um certo número de processos zumbis.

Então basicamente - sim - normalmente é um sinal de um problema.

Mas eu vi programas que geram processos zumbis como parte de suas operações "normais". Esses processos zumbis desapareceram quando o acordo de nível superior-api (eu não digo processo pai aqui) foi chamado com o comando "sair / sair".

Então, nesses casos, parece que o aplicativo cuidou (e talvez necessário) desses zumbis. Então, para o monitoramento, tive que definir uma exceção nos servidores em que esses aplicativos estavam sendo executados.

Em outros casos, os zumbis desapareceram após um curto período de tempo - para que você possa ter certos estados não-persistentes do sistema com processos zumbis.

No seu caso: Se gvim estiver pronto, não deve haver mais nenhum zumbi - então provavelmente um bug.

    

Answer 5

No Unix / Linux, novos processos são criados pela chamada do sistema fork(2) (ou alguma versão alterada do mesmo, ou talvez por outra variante do clone(2) ). É responsabilidade dos pais fazer uma variante de wait(2) para coletar o status de saída do processo filho (se o pai terminar antes do filho, init(8) cuidará do órfão). Um processo finalizado cujo status de saída não foi coletado é um zumbi . Zumbis são um sinal de paternidade irresponsável.