(SO: variante Debian.)
Ter um processo com status de zumbi. O PPidpertencia a um gvimprocesso. O conteúdo de /proc/[pid]/wchanédo_exit,
/commestá she /cmdlineestá vazio, /statusé mostrado abaixo.
Isso poderia ser um bug gvim? Da entrada da Wikipedia emProcesso zumbiEu li que um programa pode rejeitar voluntariamente a chamada, waitmas isso foi para uma
gvimsessão que estava inativa há algum tempo. Fechei o gvimprocesso – mas o zumbi ainda está à espreita. Isso poderia indicar um bug do sistema operacional?
Novamente da Wikipedia:
Se o programa pai não estiver mais em execução, os processos zumbis normalmente indicam um bug no sistema operacional.
E com que frequência colhe initprocessos abandonados? Já se passaram pelo menos 60 minutos desde gvimo falecimento, mas ainda está lá.
Por outro lado, poderia ser she não gvim?
O/status arquivoestados SigQde 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 isso destrua meu sono de beleza, mas me pergunto…
Responder1
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_NOCLDWAITsinalizador).
No entanto, este é um bug menor. Os processos zumbis consomem apenas uma entrada na tabela de processos, o que representa 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 (o pai do zumbi) ainda está vivo e funcionando (mas não waitfuncionando). Ou este não é o Gvim, mas algum subprocesso dele, ou você fechou uma janela do Gvim, mas o programa ainda está em execução. Corre ps l 29673para ver como é esse processo.
Responder2
Se você encontrar continuamente um processo zumbi, estou inclinado a pensar que definitivamente há algo errado. O processo zumbi ocorre. Geralmente vejo alguns por mês nos vários sistemas que mantenho no trabalho e em casa.
Geralmente, eles podem ser atribuídos a um erro do operador ou a um problema com um software específico. As reinicializações geralmente os 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) deles gdbpara 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 leria esses recursos adicionais abaixo para obter outras técnicas para tentar lidar com eles.
Referências
Responder3
Isso acontece toda vez que você usa o gvim? O gvim funciona além de deixar um zumbi depois de sair? A menos que cause problemas reais, eu simplesmente ignoraria - os zumbis não sobrecarregam 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/extinto normalmente acontece quando um processo filho é encerrado antes que o pai comece a ouvi-lo. A criança "fica por perto" porque não havia nenhum programa disponível para receber seu status de saída, mesmo que tenha sido encerrado de forma satisfatória - portanto, ela se torna um zumbi. Outra razão pela qual você pega zumbis pode ser quando uma grande árvore de processos desmorona - talvez porque alguém tentou matar um ou mais processos na árvore.
Um zumbi é na verdade uma forma de o sistema operacional manter o status de saída e outras informações sobre um processo que não foi encerrado corretamente, caso alguém esteja interessado. Além de uma entrada na tabela de processos, um zumbi não ocupa nenhum recurso (ou seja, nenhuma memória ou CPU).
IMHO WikiPedia está errada - ou pelo menos fácil de entender mal - quando afirma que zumbis não colhidos significam um erro no sistema operacional se permanecerem após o processo principal ter sido gerado pelas saídas. Não é incomum que um zumbi sobreviva aos pais e, nesse caso, é adotado por init(PID 1). initpode 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 preencham a tabela de processos, eles dificilmente serão um problema.
É claro que os zumbis geralmente significam que algo está errado - que um programa gera um filho que morre antes que os pais esperassem - mas não precisa ser o sistema operacional o problema. Certamente podem ser os componentes do sistema operacional que causam isso - por exemplo. um servidor de som ausente ou mal configurado faz com que um processo filho que deveria manipular o som para um programa saia imediatamente, permanecendo assim como zumbis.
Responder4
Como sempre - depende. A maioria das ferramentas de monitoramento fica amarela ou vermelha se encontrar mais do que um certo número de processos zumbis.
Então, basicamente - sim - normalmente é um sinal de problema.
Mas já vi programas que geram processos zumbis como parte de suas operações "normais". Esses processos zumbis desapareceram quando a API de nível superior correspondente (não digo processo pai aqui) foi chamada com o comando "quit/exit".
Então nesses casos parece que o aplicativo cuidou (e talvez precisasse) desses zumbis. Então para monitoramento tive que definir uma exceção nos servidores onde essas aplicações estavam rodando.
Em outros casos, os zumbis desapareceram após um curto período de tempo - então você pode ter certos estados de sistema não persistentes com processos zumbis.
No seu caso: Se gvimisso for feito, não deverá sobrar nenhum zumbi - provavelmente um bug.