Cuando usé killall -9 name para matar un programa, el estado se convierte en zombi. Unos minutos más tarde, realmente se detuvo.
Entonces, ¿qué está pasando durante esos minutos?
Respuesta aceptada:
En realidad, el programa nunca recibe la señal SIGKILL, ya que SIGKILL es completamente manejado por el sistema operativo/kernel.
Cuando se envía SIGKILL para un proceso específico, el programador del kernel deja de darle inmediatamente a ese proceso más tiempo de CPU para ejecutar código de espacio de usuario. Si el proceso tiene subprocesos que ejecutan código de espacio de usuario en otras CPU/núcleos en el momento en que el programador toma esta decisión, esos subprocesos también se detendrán. (En los sistemas de un solo núcleo, esto solía ser mucho más simple:si el único núcleo de la CPU en el sistema estaba ejecutando el programador, ¡por definición no estaba ejecutando el proceso al mismo tiempo!)
Si el proceso/subproceso está ejecutando código kernel (por ejemplo, una llamada al sistema o una operación de E/S asociada con un archivo asignado a la memoria) en el momento de SIGKILL, se vuelve un poco más complicado:solo algunas llamadas al sistema son interrumpibles, por lo que el kernel marca internamente el proceso como si estuviera en un estado especial de "agonía" hasta que se resuelvan las llamadas al sistema o las operaciones de E/S. El tiempo de CPU para resolverlos se programará como de costumbre. Las llamadas al sistema interrumpibles o las operaciones de E/S verificarán si el proceso que las llamó está muriendo en algún punto de parada adecuado y, en ese caso, saldrá temprano. Las operaciones ininterrumpidas se ejecutarán hasta completarse y buscarán un estado de "agonía" justo antes de volver al código de espacio de usuario.
Una vez que se resuelven las rutinas del kernel en proceso, el estado del proceso cambia de "morir" a "muerto" y el kernel comienza a limpiarlo, de manera similar a cuando un programa sale normalmente. Una vez que se complete la limpieza, se asignará un código de resultado superior a 128 (para indicar que una señal eliminó el proceso; consulte esta respuesta para conocer los detalles desordenados), y el proceso pasará al estado "zombie". . El padre del proceso eliminado será notificado con una señal SIGCHLD.
Como resultado, el proceso en sí nunca tendrá la oportunidad de procesar realmente la información que recibió un SIGKILL.
Cuando un proceso está en un estado "zombie", significa que el proceso ya está muerto, pero su proceso principal aún no lo ha reconocido leyendo el código de salida del proceso muerto usando wait(2) llamada del sistema. Básicamente, el único recurso que consume un proceso zombi es una ranura en la tabla de procesos que contiene su PID, el código de salida y algunas otras "estadísticas vitales" del proceso en el momento de su muerte.
Si el proceso padre muere antes que sus hijos, los procesos hijos huérfanos son adoptados automáticamente por el PID #1, que tiene el deber especial de seguir llamando a wait(2) para que los procesos huérfanos no se queden como zombis.
Si un proceso zombi tarda varios minutos en borrarse, sugiere que el principal el proceso del zombi está luchando o no está haciendo su trabajo correctamente.
Hay una descripción irónica sobre qué hacer en caso de problemas con zombis en sistemas operativos similares a Unix:“No puedes hacer nada por los zombis, ya que ya están muertos. En lugar de eso, ¡mata al malvado maestro de los zombis! ” (es decir, el proceso principal de los zombis problemáticos)