¿Cuándo no debería matar -9 a un proceso?

Siempre dudo mucho en ejecutar kill -9, pero veo que otros administradores lo hacen casi de manera rutinaria.

Me imagino que probablemente haya un punto medio sensible, así que:

1. ¿Cuándo y por qué debería kill -9usarse? ¿Cuándo y por qué no?
2. ¿Qué se debe probar antes de hacerlo?
3. ¿Qué tipo de depuración de un proceso "bloqueado" podría causar más problemas?

En general, debe usar kill(abreviatura kill -s TERMo en la mayoría de los sistemas kill -15) before kill -9( kill -s KILL) para dar al proceso objetivo la oportunidad de limpiarse después de sí mismo. (Los procesos no se pueden detectar o ignorar SIGKILL, pero sí se pueden detectar SIGTERM). Si no le da al proceso la oportunidad de terminar lo que está haciendo y limpiar, puede dejar archivos corruptos (u otro estado) alrededor de eso. no podrá entender una vez reiniciado.

strace/ truss, ltracey gdbgeneralmente son buenas ideas para ver por qué un proceso atascado está atascado. ( truss -uen Solaris es particularmente útil; encuentro que con ltracedemasiada frecuencia presenta argumentos para las llamadas a la biblioteca en un formato inutilizable). Solaris también tiene /procherramientas útiles, algunas de las cuales se han portado a Linux. (A pstackmenudo es útil).

Randal Schwartz solía publicar con frecuencia "Uso inútil de (x)" en las listas. Una de esas publicaciones fue sobre kill -9. Incluye razones y una receta a seguir. Aquí hay una versión reconstruida (citada a continuación).

(Cita abominación)

No no no. No uses kill -9.

No le da al proceso la oportunidad de limpiar:

1) apague las conexiones del zócalo

2) limpiar archivos temporales

3) informar a sus hijos que se va a ir

4) restablecer sus características de terminal

Y así sucesivamente y así sucesivamente y así sucesivamente.

En general, envíe 15 y espere un segundo o dos, y si eso no funciona, envíe 2, y si eso no funciona, envíe 1. Si eso no funciona, ¡QUITE EL BINARIO porque el programa se comportó mal!

No uses kill -9. No saque la cosechadora solo para ordenar la maceta.

Solo otro uso inútil de Usenet,

(.firma)

Siempre debería estar bien hacerlo kill -9, al igual que siempre debería estar bien apagarlo tirando del cable de alimentación. Puede ser antisocial y dejar algo de recuperación por hacer, pero debería funcionar, y es una herramienta poderosa para los impacientes.

Digo esto como alguien que intentará simplemente matar (15) primero, porque le da al programa la oportunidad de hacer un poco de limpieza, tal vez simplemente escribiendo en un registro "saliendo en sig 15". Pero no aceptaré ninguna queja sobre mal comportamiento en un kill -9.

La razón: muchos clientes lo hacen a cosas que los programadores preferirían y luego no. La prueba aleatoria kill -9 es un escenario de prueba bueno y justo, y si su sistema no lo maneja, su sistema está dañado.

Uso kill -9 de la misma manera que arrojo utensilios de cocina en el lavavajillas: si el lavavajillas arruina un implemento de cocina, entonces no lo quiero.

Lo mismo ocurre con la mayoría de los programas (incluso las bases de datos): si no puedo matarlos sin que las cosas se vuelvan locas, realmente no quiero usarlos. (Y si utiliza una de estas no bases de datos que lo alienta a fingir que tienen datos persistentes cuando no lo tienen: bueno, supongo que es hora de que empiece a pensar en lo que está haciendo).

Porque en el mundo real las cosas pueden fallar en cualquier momento por cualquier motivo.

La gente debería escribir software que sea tolerante a los bloqueos. En particular en servidores. Debe aprender a diseñar software que asuma que las cosas se romperán, se estrellarán, etc.

Lo mismo ocurre con el software de escritorio. Cuando quiero cerrar mi navegador, por lo general tardo EDADES en apagarse. No hay nada que mi navegador deba hacer que deba llevar más de un par de segundos. Cuando le pido que se cierre, debería hacerlo inmediatamente. Cuando no lo hace, bueno, entonces sacamos kill -9 y lo hacemos.

No se menciona en todas las otras respuestas es un caso en el kill -9que no funciona en absoluto, cuando un proceso es <defunct>y no puede ser eliminado:

¿Cómo puedo matar un proceso <defunct> cuyo padre es init?

¿Qué es difunto para un proceso y por qué no lo matan?

Entonces, antes de intentar ejecutar kill -9un <defunct>proceso ps -efpara ver cuál es su padre e intentar el -15(TÉRMINO) o -2(INT) y, por último, -9(MATAR) en su padre.

_{Nota: que ps -efhace .}

_{Edición y precaución posteriores: proceda con precaución cuando elimine procesos, sus padres o hijos, ya que pueden dejar archivos abiertos o corruptos, conexiones sin terminar, pueden dañar bases de datos, etc. a menos que sepa qué kill -9hace para un proceso, úselo solo como último recurso , y si necesita ejecutar kill, use las señales especificadas anteriormente antes de usar-9 (KILL)}

Nunca nunca hagas a kill -9 1. También evite matar en ciertos procesos como mount`. Cuando tengo que matar muchos procesos (por ejemplo, una sesión X se cuelga y tengo que matar todos los procesos de un determinado usuario), invierto el orden de los procesos. Por ejemplo:

ps -ef|remove all processes not matching a certain criteria| awk '{print $2}'|ruby -e '$A=stdin.readlines; A.reverse.each{|a| puts "kill -9 #{a}"}'|bash

Tenga en cuenta que killno detiene un proceso y libera sus recursos. Todo lo que hace es enviar una señal SIGKILL al proceso; podrías terminar con un proceso que está colgado.

Los procesos de eliminación no son fáciles: los datos se pueden perder, las aplicaciones mal diseñadas pueden romperse de manera sutil que no se pueden solucionar sin una reinstalación ... pero depende completamente de saber qué es y qué no es seguro en un situación dada y lo que estaría en riesgo. El usuario debe tener una idea de lo que está haciendo o debe hacer un proceso y cuáles son sus limitaciones (disco IOPS, rss / swap) y poder estimar cuánto tiempo debería llevar un proceso de larga duración (digamos una copia de archivo, reencodificación de mp3, migración de correo electrónico, copia de seguridad, [su enlace de tiempo favorito aquí].)

Además, enviar SIGKILLa un pid no es garantía de matarlo. Si está atascado en una llamada al sistema o ya está zombie ( Zin ps), puede continuar siendo zombie. Este suele ser el caso de ^ Z un proceso de larga ejecución y olvidarse bgantes de intentarlo kill -9. Un simple fgvolverá a conectar stdin / stdout y probablemente desbloqueará el proceso, generalmente seguido de la finalización del proceso. Si está atascado en otro lugar o en alguna otra forma de punto muerto del kernel, solo un reinicio puede eliminar el proceso. (Los procesos de Zombie ya están inactivos después SIGKILLde que el núcleo procesa (no se ejecutará más código de usuario), generalmente hay una razón del núcleo (similar a estar "bloqueado" esperando que finalice una llamada al sistema) para que el proceso no finalice).

Además, si desea eliminar un proceso y todos sus elementos secundarios, adquiera el hábito de llamar killcon el PID negado, no solo el PID en sí . No hay ninguna garantía de SIGHUP, SIGPIPEo SIGINTu otras señales de limpiar después de ella, y tener un montón de procesos repudiado a la limpieza (recuerde mestizo?) Es molesto.

Bonus evil: kill -9 -1es un poco más dañino que kill -9 1(No hagas ninguno de los dos como root a menos que quieras ver lo que sucede en un VM descartable y no importante)

Por qué no quieres kill -9un proceso normalmente

De acuerdo a man 7 signal:

Las señales SIGKILL y SIGSTOP no pueden capturarse, bloquearse o ignorarse.

Esto significa que la aplicación que recibe cualquiera de estas señales no puede "atraparlas" para realizar ningún comportamiento de apagado.

Lo que debe hacer antes de ejecutar kill -9un proceso

Debe asegurarse de que antes de enviar la señal al proceso que:

1. Asegúrese de que el proceso no esté ocupado (es decir, haciendo "trabajo"); enviar un mensaje kill -9al proceso esencialmente provocará la pérdida de estos datos.
2. Si el proceso es una base de datos que no responde, asegúrese de que primero haya vaciado sus cachés. Algunas bases de datos admiten el envío de otras señales al proceso para forzar el vaciado de su caché.

He creado un script que ayuda a automatizar este problema.

Se basa en mi respuesta completa 2 en una pregunta muy similar en stackoverflow .

Puedes leer todas las explicaciones allí. Para resumir, recomendaría solo SIGTERMy SIGKILL, o incluso SIGTERM, SIGINTy SIGKILL. Sin embargo, doy más opciones en la respuesta completa.

Por favor, siéntase libre de descargarlo (clonarlo) desde el repositorio de github para matarlo con gracia 1