Cuando solía killall -9 namematar un programa, el estado se convirtió en zombie. Algunos minutos después, se detuvo realmente. Entonces, ¿qué está pasando durante esos minutos?
39
El programa en realidad nunca recibe la señal SIGKILL, ya que SIGKILL es manejado completamente por el sistema operativo / kernel.
Cuando se envía SIGKILL para un proceso específico, el programador del kernel deja de darle a ese proceso más tiempo de CPU para ejecutar el 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 planificador 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 ejecutaba el programador, ¡por definición no ejecutaba el proceso al mismo tiempo!)
Si el proceso / subproceso está ejecutando el código del kernel (por ejemplo, una llamada al sistema o una operación de E / S asociada con un archivo mapeado en memoria) en el momento de SIGKILL, se vuelve un poco más complicado: solo algunas llamadas del sistema son interrumpibles, por lo que kernel marca internamente el proceso como un estado especial de "muerte" hasta que se resuelven las llamadas del sistema o las operaciones de E / S. El tiempo de CPU para resolverlos se programará como de costumbre. Las llamadas de sistema interrumpible o las operaciones de E / S comprobarán si el proceso que las llamó se está muriendo en algún punto de detención adecuado, y se cerrará temprano en ese caso. Las operaciones ininterrumpidas se completarán y verificará si hay un estado de "muerte" justo antes de regresar al código de espacio de usuario.
Una vez que se resuelven las rutinas del kernel en proceso, el estado del proceso cambia de "moribundo" a "muerto" y el kernel comienza a limpiarlo, de forma 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 el proceso fue cancelado por una señal; vea esta respuesta para los detalles desordenados ), y el proceso pasará al estado "zombie" . El padre del proceso cancelado será notificado con una señal SIGCHLD.
Como resultado, el proceso en sí nunca tendrá la oportunidad de procesar realmente la información que ha recibido un SIGKILL.
Cuando un proceso está en un estado "zombie" significa que el proceso ya está muerto, pero su proceso padre aún no lo ha reconocido al leer el código de salida del proceso muerto mediante la wait(2)llamada al sistema. Básicamente, el único recurso que un proceso zombie está consumiendo es una ranura en la tabla de proceso 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 wait(2)para que los procesos huérfanos no se queden como zombis.
Si el proceso de zombie tarda varios minutos en desaparecer, sugiere que el proceso padre del zombie está luchando o no está haciendo su trabajo correctamente.
Hay una descripción irónica sobre qué hacer en caso de problemas de zombis en sistemas operativos tipo Unix: "No puedes hacer nada por los zombis, ya que ya están muertos. ¡En lugar de eso, mata al malvado maestro zombie! " (es decir, el proceso principal de los zombis problemáticos)
ps: 'S' es para E / S en espera que el núcleo puede cancelar para entregar una señal, y 'D' para aquellos que no puede.