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

Siempre tengo muchas dudas de ejecutar kill -9 , pero veo que otros administradores lo hacen casi de manera rutinaria.

Me imagino que probablemente haya un punto medio sensible, entonces:

  1. ¿Cuándo y por qué se debería kill -9 ? ¿Cuándo y por qué no?
  2. ¿Qué debería intentarse antes de hacerlo?
  3. ¿Qué tipo de debugging un process "bloqueado" podría causar más problemas?

Solutions Collecting From Web of "¿Cuándo no debería matar -9 un process?"

Generalmente, debes usar kill -15 before kill -9 para darle al process objective la oportunidad de limpiarlo. (Los processs no pueden detectar o ignorar SIGKILL , pero pueden capturar SIGTERM y con frecuencia lo hacen). Si no le da al process la oportunidad de terminar lo que está haciendo y limpiar, puede dejar files corruptos (u otro estado) alnetworkingedor que no podrá entender una vez reiniciado.

strace / truss , ltrace y gdb son generalmente buenas ideas para ver por qué un process estancado está atascado. ( truss -u en Solaris es especialmente útil; me parece que ltrace demasiada frecuencia presenta arguments a las llamadas de la biblioteca en un formatting inutilizable). Solaris también tiene herramientas útiles /proc basadas en /proc , algunas de las cuales se han portado a Linux. ( pstack menudo es útil).

Randal Schwartz solía publicar con frecuencia "Uso inútil de (x)" en las lists. 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).

(Citar abominación)

No no no. No uses kill -9.

No le da al process una oportunidad de limpieza:

1) cerrar las conexiones de socket

2) limpiar files 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 uno o dos segundos, y si eso no funciona, envíe 2, y si eso no funciona, envíe 1. Si eso no sucede, ELIMINAR EL BINARIO porque el progtwig se comportó mal.

No uses kill -9. No saque la cosechadora solo para poner en order la maceta.

Solo otro uso inútil de Usenet,

(.firma)

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

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

La razón: muchos clientes lo hacen a cosas que los progtwigdores preferirían y luego no. La testing de matar aleatoriamente -9 es un escenario de testing bueno y justo, y si su sistema no lo maneja, su sistema está quebrado.

Utilizo kill -9 casi de la misma manera que arrojo utensilios de cocina en el lavavajillas: si un utensilio de cocina es arruinado por el lavavajillas, entonces no lo quiero.

Lo mismo ocurre con la mayoría de los progtwigs (incluso las bases de datos): si no puedo matarlos sin que las cosas se vuelvan locas, realmente no quiero usarlos. (Y si usa una de estas bases de datos que lo anima a pretender que han conservado los datos cuando no lo han hecho: bueno, supongo que es hora de que empiece a pensar en lo que está haciendo).

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

La gente debería escribir software que sea tolerante a los lockings. En particular en serveres. Debería aprender a diseñar software que asume que las cosas se romperán, se colgarán, etc.

Lo mismo aplica para el software de escritorio. Cuando quiero apagar mi browser, generalmente se necesita AGES para cerrar. No hay nada que mi browser necesite hacer, que debería tomar más de un par de segundos. Cuando le pido que se apague, debería hacer eso inmediatamente. Cuando no lo hace, bueno, sacamos kill -9 y lo hacemos.

No se menciona en todas las demás respuestas un caso en el que kill -9 no funciona en absoluto, cuando un process está <defunct> y no se puede matar:

¿Cómo puedo eliminar un process <extinto> cuyo padre es init?

¿Qué es lo que falta para un process y por qué no se mata?

Entonces, antes de intentar kill -9 un process <defunct> ejecute ps -ef para ver cuál es su padre e intente -15 (TERMINAR) o -2 (INT) y por último -9 (MATAR) en su padre.

Nota: qué hace ps -ef .

Edición posterior y precaución: Proceda con precaución al matar processs, sus padres o sus hijos, ya que pueden dejar files abiertos o dañados, conexiones inacabadas, pueden dañar bases de datos, etc. a less que sepa lo que kill -9 hace por un process, utilícelo solo como un último recurso, y si necesita ejecutar kill use las señales especificadas anteriormente antes de usar -9 (KILL)

Nunca nunca kill -9 1 . También evita matar en ciertos processs como mount`. Cuando tengo que matar una gran cantidad de processs (digamos, por ejemplo, una session X se cuelga y tengo que matar a todos los processs de un determinado usuario), invierto el order de los processs. 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 count que kill no detiene un process y libera sus resources. Todo lo que hace es enviar una señal SIGKILL al process; podrías terminar con un process que está colgado.

Los processs de asesinatos no son un movimiento sencillo: los datos pueden perderse, las aplicaciones mal diseñadas pueden romperse en forms sutiles que no pueden repararse sin una reinstallation … pero depende completamente de saber qué es y qué no es seguro en una situación dada. y lo que estaría en riesgo El usuario debe tener alguna idea de lo que un process es, o debería ser, hacer y cuáles son sus limitaciones (IOPS de disco, rss / swap) y ser capaz de estimar cuánto time debe llevar un process de larga ejecución (digamos una copy de file, reencoding de mp3, migration de correo electrónico, copy de security, [su marcador de time favorito aquí]).

Además, enviar SIGKILL a un pid no es garantía de matarlo. Si está atrapado en un syscall o ya está zombie ( Z en ps ), puede seguir siendo zombie. Este es a menudo el caso de ^ Z un process de larga ejecución y olvidarse de bg antes de tratar de kill -9 . Un fg simple volverá a conectar stdin / stdout y probablemente desbloqueará el process, normalmente seguido del final del process. Si está atrapado en otro lugar o en alguna otra forma de punto muerto del núcleo, solo un reinicio puede ser capaz de eliminar el process. (Los processs Zombie ya están muertos después de que SIGKILL es procesado por el kernel (no se ejecutarán más códigos de usuario), por lo general hay una razón de kernel (similar a ser "bloqueado" esperando que finalice un syscall) para que el process no termine).

Además, si quieres matar a un process y a todos sus hijos, adquiere el hábito de llamar kill con el PID negado, no solo el PID . No hay garantía de SIGHUP , SIGPIPE o SIGINT u otras señales de limpieza después de él, y tener un montón de processs desconocidos para la limpieza (¿restring mestizo?) Es molesto.

Bonificación mal: kill -9 -1 es un poco más dañino que kill -9 1 (No lo hagas como root a less que quieras ver lo que sucede en una máquina virtual no importante y desechable)

Por qué no quieres kill -9 un process normalmente

De acuerdo con la man 7 signal :

Las señales SIGKILL y SIGSTOP no se pueden capturar, bloquear ni ignorar.

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

Lo que debes hacer antes de ejecutar kill -9 en un process

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

  1. Asegúrese de que el process no esté ocupado (es decir, haga "trabajo"); enviar un kill -9 al process esencialmente dará como resultado la pérdida de estos datos.
  2. Si el process es una database no receptiva, asegúrese de que haya limpiado sus cachings primero. Algunas bases de datos admiten el envío de otras señales al process para forzar el enjuague de su caching.

Creé 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 SIGTERM y SIGKILL , o incluso SIGTERM , SIGINT y SIGKILL . Sin embargo, doy más opciones en la respuesta completa.

Por favor, siéntase libre de downloadlo (clonarlo) desde el repository de Github para matarlo con agrado 1