(SO: variante Debian).
Tener un proceso con estado zombie. El PPidpertenecía a un gvimproceso. El contenido de /proc/[pid]/wchanesdo_exit,
/commestá shy /cmdlineestá vacío, /statusse muestra a continuación.
¿Podría ser esto un error gvim? De la entrada de Wikipedia enproceso zombiLeí que un programa puede rechazar voluntariamente una llamada, waitpero esto fue para una
gvimsesión que había estado inactiva durante bastante tiempo. Cerré el gvimproceso, pero el zombi todavía acecha. ¿Podría esto indicar un error del sistema operativo?
De nuevo de Wikipedia:
Si el programa principal ya no se ejecuta, los procesos zombies suelen indicar un error en el sistema operativo.
¿Y con qué frecuencia se initcosechan procesos abandonados? Han pasado al menos 60 minutos desde gvimla desaparición de pero sigue ahí.
Por otro lado ¿podría serlo shy no gvim?
El/status archivoestados SigQde cero.
$ 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
No es que destruya mi sueño reparador, pero preguntarme...
Respuesta1
Ver zombis tiende a indicar un error en el proceso que los generó: se supone que ese proceso cosecha los zombis (llamando a wait) o los ignora explícitamente SIGCLD(o establece la SA_NOCLDWAITbandera).
Sin embargo, este es un error menor. Los procesos zombies solo consumen una entrada en la tabla de procesos, que es una cantidad insignificante de recursos. El problema sólo se vuelve significativo si un proceso deja atrás a miles de zombis.
No has matado el proceso padre del zombie: de lo contrario, el zombie habría desaparecido. El proceso 29673 (el padre del zombie) todavía está vivo y coleando (pero no wait). O esto no es Gvim sino algún subproceso del mismo, o has cerrado una ventana de Gvim pero el programa aún se está ejecutando. Corre ps l 29673a ver cuál es este proceso.
Respuesta2
Si te encuentras continuamente con un proceso zombie, me inclinaría a pensar que definitivamente algo anda mal. Se producen procesos zombis. Generalmente veo algunos al mes en los distintos sistemas que mantengo tanto en el trabajo como en casa.
Por lo general, pueden deberse a un error del operador o a un problema con un software en particular. Los reinicios generalmente los resuelven y normalmente no vuelven a ocurrir durante algún tiempo.
Si te están molestando, puedes intentar adjuntarlo a su ID de proceso principal (PPID) gdbpara ver qué pasa o incluso intentar matarlos:
$ gdb -p 100
(gdb) call waitpid(200, 0, 0)
(gdb) quit
Si está dispuesto, leería estos recursos adicionales a continuación para conocer otras técnicas para tratar de lidiar con ellos.
Referencias
Respuesta3
¿Sucede esto cada vez que usas gvim? ¿Gvim funciona además de dejar un zombie después de que sale? A menos que cause problemas reales, simplemente lo ignoraría: los zombis no gravan los recursos del sistema. No me sorprendería que fuera un error en gvim - o quizás en gtk, pero a menos que el programa no funcione en absoluto, lo ignoraría.
Un proceso zombi/desaparecido suele ocurrir cuando un proceso hijo sale antes de que el padre comience a escucharlo. El niño "se queda" porque no había ningún programa disponible para recibir su estado de salida, a pesar de que terminó satisfactoriamente; por lo tanto, se convierte en un zombi. Otra razón por la que aparecen zombis puede ser cuando un gran árbol de procesos se derrumba, tal vez porque alguien intentó matar uno o más procesos en el árbol.
Un zombi es en realidad una forma que tiene el sistema operativo de mantener el estado de salida y otra información sobre un proceso que no terminó correctamente, en caso de que alguien esté interesado. Aparte de una entrada en la tabla de procesos, un zombie no consume recursos (es decir, ni memoria ni CPU).
En mi humilde opinión, WikiPedia se equivoca, o al menos es fácil de malinterpretar, cuando afirma que los zombis no cosechados significan un error con el sistema operativo si persisten después del proceso principal que fue generado por las salidas. No es inusual que un zombi sobreviva a sus padres, en cuyo caso es adoptado por init(PID 1). initPuede que eventualmente lo coseche, pero algunos zombies, incluso aquellos adoptados por init, pueden permanecer hasta el reinicio. Mientras no tengas tantos zombis que llenen la tabla de procesos, no suponen ningún problema.
Por supuesto, los zombis a menudo significan que algo anda mal (que un programa genera un niño que muere antes de lo que el padre espera), pero no tiene por qué ser el sistema operativo el problema. Sin embargo, ciertamente pueden ser componentes del sistema operativo los que lo causan, por ejemplo. un servidor de sonido faltante o mal configurado hace que los procesos secundarios que se supone deben manejar el sonido de un programa salgan inmediatamente, quedándose así como zombis.
Respuesta4
Como siempre, depende. La mayoría de las herramientas de monitoreo se vuelven amarillas o rojas si encuentran más de un cierto número de procesos zombies.
Básicamente, sí, normalmente es una señal de un problema.
Pero he visto programas que generan procesos zombies como parte de sus operaciones "normales". Estos procesos zombies desaparecieron cuando se llamó a la API de nivel superior correspondiente (aquí no digo proceso principal) con el comando "salir/salir".
Entonces en estos casos parece que la aplicación se encargó (y quizás necesitó) de estos zombies. Entonces, para monitorear tuve que definir una excepción en los servidores donde se ejecutaban estas aplicaciones.
En otros casos, los zombies desaparecieron después de un corto tiempo, por lo que puedes tener ciertos estados del sistema no persistentes con procesos zombies.
En su caso: si gvimse hace, no debería quedar ningún zombi, por lo que probablemente sea un error.