¿Qué pasa si 'kill -9' no funciona?

Tengo un proceso con el que no puedo matar kill -9 <pid>. ¿Cuál es el problema en tal caso, especialmente porque soy el dueño de ese proceso? Pensé que nada podría evadir esa killopción.

kill -9( SIGKILL ) siempre funciona, siempre que tenga permiso para eliminar el proceso. Básicamente, el proceso debe ser iniciado por usted y no ser setuid o setgid, o debe ser root. Hay una excepción: incluso el root no puede enviar una señal fatal al PID 1 (el initproceso).

Sin embargo, kill -9no se garantiza que funcione de inmediato . Todas las señales, incluida SIGKILL, se entregan de forma asíncrona: el núcleo puede tardar en entregarlas. Por lo general, la entrega de una señal lleva como máximo unos pocos microsegundos, justo el tiempo que le toma al objetivo obtener un segmento de tiempo. Sin embargo, si el objetivo ha bloqueado la señal , la señal se pondrá en cola hasta que el objetivo la desbloquee.

Normalmente, los procesos no pueden bloquear SIGKILL. Pero el código del núcleo puede y los procesos ejecutan el código del núcleo cuando llaman a las llamadas del sistema . El código del kernel bloquea todas las señales cuando la interrupción de la llamada del sistema daría como resultado una estructura de datos mal formada en algún lugar del kernel, o más generalmente en la violación de algún invariante del kernel. Entonces, si (debido a un error o diseño incorrecto) una llamada del sistema se bloquea indefinidamente, es posible que no haya forma de matar el proceso. (Sin embargo, el proceso va a ser matado si alguna vez se completa la llamada al sistema.)

Un proceso bloqueado en una llamada al sistema está en suspensión ininterrumpida . El comando pso top(en la mayoría de los dispositivos) lo mostrará en estado D(originalmente para " d isk", creo).

Un caso clásico de suspensión prolongada e ininterrumpida es el acceso a archivos a través de NFS cuando el servidor no responde; Las implementaciones modernas tienden a no imponer la suspensión ininterrumpida (por ejemplo, en Linux, la intropción de montaje permite que una señal interrumpa el acceso a los archivos NFS).

A veces puede ver entradas marcadas Z(o Hen Linux, no sé cuál es la distinción) en la salida pso top. Estos no son técnicamente procesos, son procesos zombies, que no son más que una entrada en la tabla de procesos, guardados para que el proceso padre pueda ser notificado de la muerte de su hijo. Se irán cuando el proceso principal preste atención (o muera).

En algún momento el proceso existe y no puede ser eliminado debido a:

• siendo zombie Es decir, procesar qué padre no leyó el estado de salida. Dicho proceso no consume ningún recurso, excepto la entrada PID. En topella se señala Z
• sueño ininterrumpido erróneo. No debería suceder, pero con una combinación de código de kernel defectuoso y / o hardware defectuoso lo hace en algún momento. El único método es reiniciar o esperar. En topella está señalado por D.

Parece que podrías tener un proceso zombie . Esto es inofensivo: el único recurso que consume un proceso zombie es una entrada en la tabla de procesos. Desaparecerá cuando el proceso padre muera o reaccione a la muerte de su hijo.

Puedes ver si el proceso es un zombie usando topo el siguiente comando:

ps aux | awk '$8=="Z" {print $2}'

Verifique su /var/log/kern.logy /var/log/dmesg(o equivalentes) en busca de pistas. En mi experiencia, esto me ha sucedido solo cuando la conexión de red de una montura NFS se ha caído repentinamente o un controlador de dispositivo se ha bloqueado. Podría suceder si un disco duro también falla, creo.

Puede usar lsofpara ver qué archivos de dispositivo ha abierto el proceso.

Si las respuestas de @ Maciej y @ Gilles no resuelven su problema, y ​​no reconoce el proceso (y preguntar qué es con su distribución no arroja respuestas). Verifique si hay Rootkit y cualquier otro signo que le haya pertenecido . Un rootkit es más que capaz de evitar que mates el proceso. De hecho, muchos son capaces de evitar que los veas. Pero si se olvidan de modificar 1 programa pequeño, podrían verse (por ejemplo, modificaron top, pero no htop). Lo más probable es que este no sea el caso, pero es mejor prevenir que curar.

Matar en realidad significa enviar una señal. Hay múltiples señales que puede enviar. kill -9 es una señal especial.

Al enviar una señal, la aplicación se ocupa de ello. si no, el kernel lo trata. para que pueda atrapar una señal en su aplicación.

Pero dije que matar -9 era especial. Es especial porque la aplicación no lo entiende. va directamente al kernel que luego mata realmente la aplicación en la primera oportunidad posible. en otras palabras, lo mata

kill -15 envía la señal SIGTERM que significa SIGNAL TERMINATE en otras palabras, le dice a la aplicación que se cierre. Esta es la manera amigable de decirle a una aplicación que es hora de cerrarla. pero si la aplicación no responde, kill -9 la matará.

si kill -9 no funciona, probablemente significa que su núcleo está fuera de control. un reinicio está en orden. No recuerdo que eso haya pasado.

Primero, verifique si es un proceso Zombie (que es muy posible):

ps -Al

Verás algo como:

0 Z  1000 24589     1  0  80   0 -     0 exit   ?        00:00:00 soffice.bin <defunct>

(Tenga en cuenta la "Z" a la izquierda)

Si la quinta columna no es 1, significa que tiene un proceso padre. Intenta eliminar esa identificación de proceso principal .

Si es PPID = 1, ¡NO LO MATES ! , piense qué otros dispositivos o procesos pueden estar relacionados con él.

Por ejemplo, si estaba utilizando un dispositivo montado o una samba, intente desmontarlo. Eso puede liberar el proceso Zombie.

NOTA : Si ps -Al(o top) muestra una "D" en lugar de "Z", podría estar relacionado con el montaje remoto (como NFS). En mi experiencia, reiniciar es la única forma de llegar allí, pero puede verificar las otras respuestas que cubren ese caso con más detalle.

El proceso de inicio es inmune a SIGKILL.

Esto también es cierto también para los hilos del núcleo, es decir, "procesos" con un PPID igual a 0.

Como otros han mencionado, un proceso en sueño ininterrumpido no se puede matar de inmediato (o, en algunos casos, en absoluto). Vale la pena señalar que se agregó otro estado de proceso, TASK_KILLABLE, para resolver este problema en ciertos escenarios, particularmente el caso común donde el proceso está esperando en NFS. Ver http://lwn.net/Articles/288056/

Desafortunadamente, no creo que esto se use en ningún otro lugar del núcleo, excepto en NFS.

¡Hice un pequeño guión que me ayudó mucho a echar un vistazo!

Puede usarlo para eliminar cualquier proceso con un nombre de pila en su camino (¡preste atención a esto!) O puede eliminar cualquier proceso de un usuario determinado utilizando el parámetro "-u nombre de usuario".

#!/bin/bash

if [ "$1" == "-u" ] ; then\n
        PID=`grep "$2" /etc/passwd | cut -d ":" -f3`
        processes=`ps aux | grep "$PID" | egrep -v "PID|ps \-au|killbyname|grep" | awk '{ print $2}'`
        echo "############# Killing all processes of user: $2 ############################"
else
        echo "############# Killing processes by name: $1 ############################"
        processes=`ps aux | grep "$1" | egrep -v "killbyname|grep" | awk '{ print $2}' `
fi


for process in $processes ; do
        # "command" stores the entire commandline of the process that will be killed
        #it may be useful to show it but in some cases it is counter-productive
        #command=`ps aux | grep $process | egrep -v "grep" | awk '{ print $2 }'`
        echo "Killing process: $process"
        echo ""
        kill -9 $process
done

Hay casos en los que incluso si envía un kill -9 a un proceso, ese pid se detendrá, pero el proceso se reinicia automáticamente (por ejemplo, si lo intenta con gnome-panel, se reiniciará): ¿podría ser ese el caso aquí?

de aquí originalmente :

comprobar si strace muestra algo

strace -p <PID>

intente adjuntar al proceso con gdb

gdb <path to binary> <PID>

si el proceso estaba interactuando con un dispositivo que puede desmontar, quitar el módulo del núcleo o desconectar / desconectar físicamente ... intente eso.

Tuve una especie de este problema. Este era un programa que había lanzado stracee interrumpido con Ctrl+ C. Terminó en un estado T(rastreado o detenido). No sé cómo sucedió exactamente, pero no se pudo matar SIGKILL.

En pocas palabras, logré matarlo con gdb:

gdb -p <PID>
> kill
Kill the program being debugged? (y or n) y
> quit

Basado en una pista de la respuesta de Gilles, tenía un proceso marcado "Z" en la parte superior ( <defunct>en ps) que estaba usando recursos del sistema, incluso tenía un puerto abierto que estaba ESCUCHANDO y se podía conectar a ese puerto. Esto fue después de ejecutar un kill -9en él. Su padre era "1" (es decir init) teóricamente, debería repetirse y desaparecer. Pero no fue así, se quedó, aunque no estaba corriendo, y "no moría"

Entonces, en mi caso, era zombie pero aún consumía recursos ... FWIW.

Y no era killable por cualquier número de kill -9's

Y su padre era initpero no estaba siendo cosechado (limpiado). Es decir, inittenía un niño zombi.

Y reiniciar no fue necesario para solucionar el problema. Aunque un reinicio "habría funcionado" en torno al problema / hizo que el apagado fuera más rápido. Simplemente no agraciado, que todavía era posible.

Y era un puerto LISTEN propiedad de un proceso zombie (y algunos otros puertos también como el estado CLOSE_WAIT conectado localhost a localhost). Y aun así aceptó conexiones. Incluso como un zombie. Supongo que todavía no había llegado a limpiar los puertos, por lo que las conexiones entrantes todavía se agregaron a la cartera de pedidos del puerto de escucha tcp, aunque no tenían ninguna posibilidad de ser aceptadas.

Muchos de los anteriores se declaran como "imposibles" en varios lugares en las redes.

Resulta que tenía un hilo interno dentro que estaba ejecutando una "llamada al sistema" (ioctl en este caso) que estaba demorando unas horas en regresar (este era el comportamiento esperado). Aparentemente, el sistema no puede matar el proceso "hasta el final" hasta que regrese de la ioctlllamada, supongo que entra en la tierra del kernel. Después de unas horas regresó, las cosas se aclararon y los enchufes se cerraron automáticamente, etc., como se esperaba. ¡Ese es un tiempo de languidez en el corredor de la muerte! El grano esperaba pacientemente para matarlo.

Entonces, para responder el OP, a veces hay que esperar. Mucho tiempo. Entonces la muerte finalmente se llevará.

También verifique dmesg para ver si hubo un kernel panic (es decir, un error del kernel).