Los programas que están mal escritos o que funcionan mal pueden dejar procesos zombis al acecho dentro de su computadora Linux. Descubra cómo se crean los zombis y cómo finalmente puede dejarlos descansar.

Cómo funcionan los estados de proceso en Linux

Linux, por supuesto, tiene que realizar un seguimiento de todas las aplicaciones y demonios que se ejecutan en su computadora. Una de las formas en que lo hace es manteniendo la tabla de procesos. Esta es una lista de estructuras en la memoria del kernel. Cada proceso tiene una entrada en esta lista que contiene información al respecto.

No hay mucho en cada una de las estructuras de la tabla de procesos. Contienen la identificación del proceso, algunos otros elementos de datos y un puntero al bloque de control de proceso (PCB) para ese proceso.

Es el PCB que contiene los muchos detalles que Linux necesita buscar o configurar para cada proceso. La PCB también se actualiza a medida que se crea un proceso, se le da tiempo de procesamiento y finalmente se destruye.

La PCB de Linux contiene más de 95 campos. Se define como una estructura llamada task_struct.h , y tiene más de 700 líneas de largo. La PCB contiene los siguientes tipos de información:

• Estado del proceso: los estados se describen a continuación.
• Número de proceso: su identificador único dentro del sistema operativo.
• Contador de programa: la próxima vez que se le dé acceso a la CPU a este proceso, el sistema utilizará esta dirección para encontrar la siguiente instrucción del proceso que debe ejecutarse.
• Registros: la lista de registros de CPU utilizados por este proceso. La lista puede contener acumuladores, registros de índice y apuntadores de pila.
• Abrir lista de archivos: archivos asociados con este proceso.
• Información de programación de la CPU: se utiliza para determinar la frecuencia y la duración del tiempo de procesamiento de la CPU para este proceso. La prioridad del proceso, los indicadores de las colas de programación y otros parámetros de programación deben registrarse en la PCB.
• Información de administración de memoria: detalles sobre la memoria que utiliza este proceso, como las direcciones de inicio y finalización de la memoria del proceso y los indicadores de las páginas de la memoria.
• Información de estado de E / S: cualquier dispositivo de entrada o salida utilizado por el proceso.

El “Estado del proceso” puede ser cualquiera de los siguientes:

• R: Un proceso en ejecución o ejecutable. Ejecutando significa que está recibiendo ciclos de CPU y ejecutándose. Un proceso ejecutable está listo para ejecutarse y esperando una ranura de CPU.
• S: Un proceso de dormir. El proceso está esperando que se complete una acción, como una operación de entrada o salida, o que un recurso esté disponible.
• D: El proceso se encuentra en un estado de suspensión ininterrumpida. Está usando una llamada al sistema de bloqueo y no puede continuar hasta que se hayan completado las llamadas al sistema. A diferencia del estado de “suspensión”, un proceso en este estado no responderá a las señales hasta que se complete la llamada al sistema y la ejecución haya regresado al proceso.
• T: El proceso ha terminado (detenido) porque recibió la señal SIGSTOP. Solo responderá a las señales SIGKILL o SIGCONT, que terminan el proceso o le indican que continúe, respectivamente. Esto es lo que sucede cuando cambia de las tareas de primer plano (fg) a segundo plano (bg).
• Z: un proceso Zombie. Cuando se completa un proceso, no desaparece simplemente. Libera cualquier memoria que esté usando y se elimina a sí mismo de la memoria, pero su entrada en la tabla de procesos y en la PCB permanecen. Su estado se establece en EXIT_ZOMBIE y se notifica a su proceso padre (mediante la señal SIGCHLD) que el proceso hijo ha finalizado.

En el estado Zombie, el proceso padre llama a una de las familias de funciones wait() cuando se crea el proceso hijo. Luego espera un cambio de estado en el proceso hijo. ¿Se ha detenido, continuado o interrumpido el proceso del niño por una señal? ¿Ha terminado ejecutando la finalización natural de su código?

Si el cambio de estado es uno que significa que el proceso hijo ha dejado de ejecutarse, se lee su código de salida. Luego, la PCB del niño se destruye y se elimina su entrada en la tabla de proceso. Idealmente, todo esto sucede en un abrir y cerrar de ojos, y los procesos en el estado zombie no existen por mucho tiempo.

¿Qué causa los procesos zombies en Linux?

Un proceso padre mal escrito podría no llamar a la función wait() cuando se crea el proceso hijo. Esto significa que nada está pendiente de los cambios de estado en el proceso hijo y se ignorará la señal SIGCHLD . O quizás otra aplicación esté afectando la ejecución del proceso principal, ya sea debido a una programación deficiente o una intención maliciosa.

Sin embargo, si el proceso principal no está atento a los cambios de estado en el proceso secundario, no se producirá el mantenimiento adecuado del sistema. La PCB y la entrada en la tabla de procesos no se eliminarán cuando finalice el proceso hijo. Esto da como resultado que el estado zombi nunca se elimine de la PCB.

Los zombis usan un poco de memoria, pero generalmente no representan un problema. La entrada en la tabla de procesos es pequeña, pero, hasta que se publique, el ID de proceso no se puede reutilizar. En un sistema operativo de 64 bits, es poco probable que esto cause problemas porque la PCB es mucho más grande que la entrada de la tabla de procesos.

Una gran cantidad de zombis podría, posiblemente, afectar la cantidad de memoria que queda libre para otros procesos. Sin embargo, si tienes tantos zombis, tienes un problema grave con la aplicación principal o un error del sistema operativo.

Cómo eliminar procesos Zombie

No puedes matar un proceso zombie porque ya está muerto. No responderá a ninguna señal porque se ha eliminado de la memoria; no hay ningún lugar para enviar una señal SIGKILL . Puede intentar enviar la señal SIGCHLD al proceso principal, pero si no funcionó cuando el proceso secundario terminó, es poco probable que funcione ahora.

La única solución confiable es eliminar el proceso principal. Cuando se termina, sus procesos secundarios son heredados por el proceso init , que es el primer proceso que se ejecuta en un sistema Linux (su ID de proceso es 1).

El proceso init realiza regularmente la limpieza necesaria de zombis, por lo que para matarlos, solo tienes que matar el proceso que los creó. El comando top es una forma conveniente de ver si tienes zombis.

Escriba lo siguiente:

Este sistema tiene ocho procesos zombies. Podemos egrep usando el comando ps y egrep a egrep . Una vez más, los procesos zombies tienen una bandera de estado de “Z” y, por lo general, también verá “extinto”.

Escriba lo siguiente:

Se enumeran los procesos zombies.

Esta es una forma más ordenada de descubrir los ID de proceso de los zombies que desplazarse hacia adelante y hacia atrás en la top . También vemos que una aplicación llamada “badprg” generó estos zombies.

El ID de proceso del primer zombi es 7641, pero necesitamos encontrar el ID de proceso de su proceso padre. Podemos hacerlo usando ps nuevamente. Usaremos la opción de salida ( -o ) para decirle a ps que muestre solo el ID de proceso del padre, y luego lo pasaremos con el ppid= .

El proceso que queremos encontrar se indicará usando la opción -p (proceso) y luego pasando el ID de proceso del zombi.

Por lo tanto, escribimos el siguiente comando para buscar la información del proceso para el proceso 7641, pero solo informará el ID del proceso principal:

Nos dijeron que el ID del proceso principal es 7636. Ahora podemos hacer una referencia cruzada usando ps una vez más.

Vemos que esto coincide con el nombre del proceso principal anterior. Para matar el proceso principal, use la opción SIGKILL con el comando kill de la siguiente manera:

Dependiendo del propietario del proceso principal, es posible que también deba usar sudo .

Los zombis no dan miedo …

… A menos que estén en una horda masiva. Algunos no son motivo de preocupación y un simple reinicio los eliminará.

Sin embargo, si nota que una aplicación o un proceso siempre genera zombis, eso es algo que debería analizar. Lo más probable es que sea solo un programa escrito de manera descuidada, en cuyo caso, quizás haya una versión actualizada que se limpie adecuadamente después de sus procesos secundarios.