¿Qué son los procesos zombie?
Los procesos zombis son aquellos procesos que terminaron su tarea, pero el proceso principal (lo más probable) murió o se bloqueó inesperadamente. También pueden ser indicativos de código con errores. La mayoría de los usuarios no tienen una buena comprensión de qué son los procesos zombis y cómo afectan a un host de Linux. En primer lugar, un número bajo (digamos diez, por ejemplo) de procesos zombis no contribuye a la carga del sistema. De hecho, miles de zombis no contribuirían a la carga del sistema.
Por definición, los procesos zombie no consumen recursos, en su mayor parte. A cada proceso zombi todavía se le asigna un número de ID de proceso o PID. En los sistemas de 32 bits, la cantidad máxima de PID disponibles es 32767. En los sistemas de 64 bits, esa cantidad aumenta exponencialmente a más de 4 millones.
También se utiliza una pequeña cantidad de memoria para cada proceso zombie. Técnicamente, se necesitarían decenas de miles, quizás cientos de miles de procesos zombis para causar un agotamiento significativo de los recursos del sistema.
Hay 2 escenarios que discutiré aquí. El primero es un proceso que genera numerosos PID secundarios, y luego el PID principal falla o muere sin obtener los PID secundarios. Normalmente, este problema indicaría un posible error con el programa o el código. Cuando esto sucede, el PID 1 (o el proceso de inicio) se hace cargo de ellos. A los efectos de este tutorial, la forma más rápida de deshacerse de estos zombis es reiniciar. También es posible crear un proceso ficticio y transferir la propiedad de esos procesos zombis al PID ficticio para que los limpie. Eso está fuera del alcance aquí. ¡Reinicia y listo!
El segundo escenario es cuando un proceso se bloquea hasta el punto en que el sistema operativo lo ve en ejecución, pero el proceso en realidad no está haciendo nada. El ejemplo que estoy usando para esta discusión es el daemon de la herramienta de informe automático de errores (abrtd ) que se incluye con Red Hat Enterprise Linux y algunas otras distribuciones. Esta es una gran herramienta, y me gusta tenerla en funcionamiento en un sistema porque me da, como administrador de sistemas, una mejor visión de lo que está fallando, o fallando, pero sin invocar el kernel bloqueado.
En mi entorno, este demonio también es un poco un talón de Aquiles. Por defecto, abrtd solo crea información para aplicaciones firmadas. Se puede firmar cualquier aplicación para generar un error, pero si una aplicación sin firmar activa abrtd , el daemon sigue los pasos para crear un informe de error y luego elimina todo lo que creó. Este comportamiento puede causar problemas con una acción que se cuelga para una aplicación sin firmar.
Echemos un vistazo a un ejemplo. Un usuario envía un informe de incidente que dice que el sistema estaba lento debido a seis procesos zombis. Hay algunos indicios claros de un sistema que abrtd está teniendo problemas. Cuando su - para rootear verás lo siguiente:
'abrt-cli status' timed out
Si revisamos el abrtd proceso podemos ver que todavía se está ejecutando, pero hay un proceso secundario que se ha estado ejecutando desde el 30/5.
[root@$HOSTNAME ~]# systemctl status abrtd
● abrtd.service - ABRT Automated Bug Reporting Tool
Loaded: loaded (/usr/lib/systemd/system/abrtd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2019-04-27 08:36:47 EDT; 2 months 13 days ago
Main PID: 1161 (abrtd)
Tasks: 12
Memory: 34.0M
CGroup: /system.slice/abrtd.service
├─ 1161 /usr/sbin/abrtd -d -s
├─60777 abrt-server -s
├─60867 /usr/libexec/abrt-handle-event -i -e post-create -- /var/spool/abrt/unsigned-app-2019-05-30-01:48:24-57451
├─64714 abrt-server -s
├─68157 abrt-server -s
├─70725 abrt-server -s
├─74101 abrt-server -s
├─77136 abrt-server -s
├─81417 abrt-server -s
├─84637 abrt-server -s
├─88183 abrt-server -s
└─90022 abrt-server -s
Así que abrtd todavía se está ejecutando técnicamente, pero ese proceso posterior a la creación ha creado un estado en el que algunos nuevos informes de fallas de ABRT intentaron ejecutarse, pero se volvieron zombis. En este punto, puede reiniciar el abrtd servicio, y esa acción borrará todos los procesos zombis.
Pero, si no sabía que ese era el caso, así es como rastrea qué PID es el padre de los zombis usando el ps -xal dominio. Este comando genera mucho mucho de información, así que solo voy a mostrar las columnas que necesitamos:
[root@$HOSTNAME ~]# ps -xal | awk '{ print $4 " " $10 " " $13 }' | sort -n
1739 Ssl+ java
1903 S bin/rscd
1903 S bin/rscd
2391 Ssl+ node
2816 Ssl+ java
2889 Ssl+ java
3785 Ss appcollect
3785 Ss appconfigcollect
3926 Ssl+ java
4696 Ss /bin/sh
4731 S bin/bash
4827 Sl /myappbinaries/jre/bin/java
7074 Ss+ httpd
7095 S+ httpd
La cuarta columna es el PID principal, la décima columna es el estado del proceso secundario (obviamente, estaría buscando PID en un estado Z) y la decimotercera columna es el proceso secundario. Usando el PID principal en la columna cuatro, ahora puede eliminar ese proceso principal y sus hijos zombies también desaparecerán. A menos que el PID principal sea 1, en cuyo caso será necesario reiniciar.
Al estar en operaciones, no siempre tenemos el lujo de reiniciar en cualquier momento. Personalmente, creo que reiniciar debería ser el último recurso. Los reinicios ocultan una multitud de pecados y dejan que esos pecados se presenten en el momento más inoportuno, ¡generalmente a altas horas de la noche o los fines de semana festivos!
Ah, y la carga en este sistema no disminuyó ni un poco después de reiniciar abrtd y eliminar esos 6 zombis.