Cómo matar procesos zombies en Linux

Fatmawati Achmad Zaenuri / Shutterstock

Los programas mal escritos o que funcionan mal pueden dejar procesos zombis ocultos dentro de su computadora Linux. Descubra cómo se crean los zombis y cómo finalmente puede acabar con ellos.

Cómo funcionan los estados de proceso en Linux

Linux, por supuesto, debe realizar un seguimiento de todas las aplicaciones y demonios que se ejecutan en su computadora. Una de las formas de hacer esto es mantener 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 sobre él.

No hay mucho en cada una de las estructuras de la tabla de procesos. Sostienen el Identificacion de 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 debe buscar o definir para cada proceso. La PCB también se actualiza a medida que se crea un proceso, considerando el tiempo de procesamiento y finalmente se destruye.

La PCB de Linux contiene más de 95 campos. está definido como una estructura llamada task_struct.hy tiene más de 700 líneas. La PCB contiene los siguientes tipos de información:

• Estado de 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 este proceso tenga acceso a la CPU, el sistema utilizará esta dirección para encontrar la siguiente instrucción de proceso que se ejecutará.
• 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 planificación del procesador: Se utiliza para determinar con qué frecuencia y durante cuánto tiempo se asigna el tiempo de procesamiento de la CPU a 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 gestión de la memoria: Detalles sobre la memoria utilizada por este proceso, como las direcciones de inicio y finalización de la memoria del proceso y los punteros a 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 uno de los siguientes:

• A: Un proceso en ejecución o ejecutable. En ejecución, eso significa que recibe ciclos de CPU y se ejecuta. Un proceso ejecutable está listo para ejecutarse y está esperando una ranura de CPU.
• S: Un proceso de sueño. El proceso espera a que se complete una acción, como una entrada o salida, o que un recurso esté disponible.
• D: El proceso se encuentra en un estado de sueño ininterrumpido. Está utilizando una llamada al sistema de bloqueo y no puede continuar hasta que se completen 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 finalizó (se detuvo) porque recibió la SIGSTOP señal. Esta solo responderé a la SIGKILL Dónde SIGCONT señales, que matan el proceso u ordenan que continúe, respectivamente. Esto es lo que pasa cuando cambias primer plan (fg) Para Contexto (bg) Tareas.
• Z: Un proceso zombi. Cuando un proceso termina, no desaparece simplemente. Libera toda la memoria que usa y se elimina a sí mismo de la memoria, pero su entrada en la tabla de procesos y la PCB permanecen. Su estado se establece en EXIT_ZOMBIE, y su proceso padre es notificado (por el SIGCHLD señal) que el proceso hijo ha terminado.

En el estado Zombie, el proceso padre llama a uno de los wait() familias de funciones al crear el proceso hijo. Luego espera un cambio de estado en el proceso hijo. ¿El proceso del niño ha sido detenido, continuado o anulado por una señal? ¿Terminó pasando por la finalización natural de su código?

Si el cambio de estado 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 de estado zombi no existen por mucho tiempo.

¿Cuáles son las causas de los procesos zombie en Linux?

Un proceso de padres mal escrito puede no llamar al wait() función cuando se crea el proceso hijo. Esto significa que nada está monitoreando los cambios de estado en el proceso hijo, y el SIGCHLD la señal será ignorada. O tal vez otra aplicación está afectando la ejecución del proceso principal, debido a una mala programación o intenciones maliciosas.

Sin embargo, si el proceso padre no supervisa los cambios de estado en el proceso hijo, 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. Como resultado, el estado zombi nunca se elimina de la PCB.

Los zombis usan un poco de memoria, pero generalmente no son 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, en teoría, afectar la cantidad de memoria disponible para otros procesos. Si tiene tantos zombis, tiene un problema grave con la aplicación principal o un error del sistema operativo.

Cómo eliminar procesos zombies

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

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

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

Escriba lo siguiente:

top

Este sistema tiene ocho procesos zombies. Nosotros puede enumerar estos utilizando el ps pedido y conéctalo a egrep. Una vez más, los procesos zombies tienen un indicador de estado de «Z» y, por lo general, también verá «fallecido».

Escriba lo siguiente:

ps aux | egrep "Z|defunct"

Se enumeran los procesos zombies.

Es una forma más limpia de descubrir ID de procesos zombies que desplazarse hacia adelante y hacia atrás 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 hacer esto usando ps de nuevo. Usaremos la opción de salida (-o) decir ps para mostrar solo el ID de proceso del padre, luego páselo con el ppid= bandera.

El proceso que queremos encontrar se indicará mediante el -p (proceso), luego pasando el ID de proceso del zombi.

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

ps -o ppid= -p 7641

Se nos dice que la identificación del proceso padre es 7636. Ahora podemos hacer una referencia cruzada usando ps una vez más.

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

kill -SIGKILL 7636

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 de temer y un simple reinicio los borrará.

Sin embargo, si nota que una aplicación o un proceso todavía está generando zombis, esto es algo que debería echarle un vistazo. Lo más probable es que se trate de un programa mal escrito, en cuyo caso puede haber una versión actualizada que se limpie correctamente después de los procesos secundarios.