Una buena explicación de la diferencia entre SIGKILL y SIGTERM (y por qué debería probar SIGTERM primero)
Enviar señales a procesos que usan kill en un sistema Unix no es un tema nuevo para la mayoría de los administradores de sistemas, pero muchas veces me han preguntado sobre la diferencia entre kill y kill -9.
Cada vez que usas kill en un proceso, en realidad estás enviando una señal al proceso (en casi todas las situaciones, me ocuparé de eso pronto). Las aplicaciones C estándar tienen un archivo de encabezado que contiene los pasos que el proceso debe seguir si recibe una señal particular. Puede obtener una lista completa de las señales disponibles en su sistema verificando la página de manual para matar.
Considere un comando como este:
kill 2563
Esto enviaría una señal llamada SIGTERM al proceso. Una vez que el proceso recibe el aviso, pueden suceder algunas cosas diferentes:
- el proceso puede detenerse de inmediato
- el proceso puede detenerse luego de un breve retraso luego de limpiar los recursos
- el proceso puede seguir ejecutándose indefinidamente
La aplicación puede determinar qué quiere hacer una vez que se recibe un SIGTERM. Si bien la mayoría de las aplicaciones limpiarán sus recursos y se detendrán, algunas no. Una aplicación puede configurarse para hacer algo completamente diferente cuando se recibe un SIGTERM. Además, si la aplicación está en mal estado, como esperando E / S de disco, es posible que no pueda actuar sobre la señal que se envió.
La mayoría de los administradores de sistemas generalmente recurren a la señal más abrupta cuando una aplicación no responde a un SIGTERM:
kill -9 2563
El -9 le dice al comando kill que desea enviar la señal # 9, que se llama SIGKILL. Con un nombre como ese, es obvio que esta señal tiene un poco más de peso.
Aunque SIGKILL se define en el mismo archivo de encabezado de señal que SIGTERM, el proceso no puede ignorarlo. De hecho, el proceso ni siquiera se da cuenta de la señal SIGKILL, ya que la señal va directamente al kernel init. En ese punto, init detendrá el proceso. El proceso nunca tiene la oportunidad de captar la señal y actuar en consecuencia.
Sin embargo, el núcleo puede no ser capaz de matar con éxito el proceso en algunas situaciones. Si el proceso espera E / S de red o disco, el núcleo no podrá detenerlo. Los procesos de zombis y los procesos atrapados en un sueño ininterrumpido tampoco pueden ser detenidos por el núcleo. Se requiere un reinicio para borrar esos procesos del sistema.
Cuando envió Killall (SIGTERM) a los procesos de Thunderbird, solicitó que se detuvieran. Algunos de esos procesos no funcionaban correctamente (probablemente por qué necesitabas matarlos en primer lugar), por lo que no podían actuar en la señal SIGTERM.
killall
acepta la mayor parte de la misma sintaxis quekill
. En particular, no hay necesidad de escribir nada elegante para hacerkillall
el equivalente dekill -9
. Esto funciona bien:(Por supuesto, como se discutió, generalmente debe ser reacio a usarlo
killall -9
o, de manera equivalentekillall -KILL
, a menos que otras medidas ya se hayan intentado sin éxito).fuente