¿kill -9 no funciona? Por qué el proceso sigue vivo

2026-05-27

Si kill -9 no funciona, es que SIGKILL nunca llegó a nada vivo: el proceso ya es un zombi, está atascado en el kernel en sueño ininterrumpible, o un supervisor le da un PID nuevo cada vez. ps -eo pid,ppid,stat,comm te dice cuál de los tres casos tienes. Así se lee y así se resuelve cada uno.

1. Primero, averigua en qué estado está el proceso

clai

$ clai muestra el estado de un proceso y qué está haciendo→ ps -eo pid,ppid,stat,comm | awk '$3 ~ /^Z/' 339320  339308 Z    sd_espeak-ng-mb1053146  902286 Z    headless_shell1053147  902286 Z    headless_shell

La primera letra de STAT lo decide todo. Z es zombi, D es sueño ininterrumpible, S/R es un proceso vivo que simplemente ignora la señal.

2. Mira los estados de toda la máquina

clai

$ clai cuenta los procesos por estado→ ps -eo stat --no-headers | cut -c1 | sort | uniq -c | sort -rn    588 S    141 I      4 Z      1 R

Unos pocos zombis son normales — no ocupan nada más que una entrada en la tabla de procesos. Miles es un bug en un padre que nunca llama a wait().

3. Un zombi no se puede matar — ya está muerto

clai

$ clai encuentra el padre del proceso zombi 339320→ ps -o ppid= -p 339320 339308

Un zombi es el registro de un proceso que ya terminó y cuyo padre nunca recogió con wait(). Enviarle señales no sirve de nada — hay que ocuparse del padre. Cuando el padre muere, init adopta al zombi y lo limpia.

4. D-state: el proceso está atascado dentro del kernel

clai

$ clai muestra los procesos en sueño ininterrumpible y qué están esperando→ ps -eo pid,stat,wchan:20,comm | awk '$2 ~ /^D/'

D significa que está esperando E/S dentro del kernel — normalmente un sistema de archivos de red colgado o un disco fallando. Un proceso así ni siquiera acepta SIGKILL, porque no está ejecutando código de usuario. La columna wchan muestra en qué función del kernel está parado. Se arregla en el origen: remontar el NFS, cambiar el disco. A veces solo lo soluciona un reinicio.

5. El proceso está vivo, pero algo lo reinicia

clai

$ clai comprueba si systemd reinicia este servicio después de matarlo→ systemctl show -p Restart -p RestartUSec app.service

Si el proceso vuelve con un PID nuevo, no estás peleando con él sino con el supervisor. Detenlo con systemctl stop, no con kill.

6. La secuencia que realmente funciona

clai

$ clai detén el proceso 12345 con cuidado, y si en 5 segundos sigue vivo, forzado→ kill 12345; sleep 5; kill -0 12345 2>/dev/null && kill -9 12345

Primero SIGTERM, para que el proceso cierre archivos y vacíe sus buffers. kill -0 no mata nada, solo comprueba si el proceso sigue vivo. SIGKILL es el último recurso — después de él, lo que quedaba en los buffers se pierde.

Trampas

kill -9 nunca llega al proceso — lo maneja el kernel. Por eso es inútil contra el D-state: no hay nadie que lo atienda, el proceso no está ejecutando su propio código.
Un zombi no ocupa ni memoria ni CPU. Ocupa una entrada en la tabla de procesos y una línea en ps. No hay que asustarse por tres zombis — es un síntoma, no un problema.
SIGKILL no le da al proceso ninguna oportunidad de cerrar bien. Los buffers sin escribir desaparecen, los bloqueos quedan puestos. Para bases de datos y servidores de archivos es un riesgo real de corrupción de datos.

Preguntas relacionadas

¿Por qué no funciona kill -9? Tres razones: el proceso ya es un zombi (muerto, no hay nada que matar), está en D-state (no ejecuta código de usuario), o un supervisor lo está reiniciando.

¿Cómo mato todos los zombis de una vez? No se puede, directamente no. Busca a sus padres con ps -eo ppid,stat | awk '$2 ~ /^Z/' y reinícialos — o espera a que ellos mismos llamen a wait().

¿Hace falta reiniciar para el D-state? Muchas veces no. Primero arregla la causa de la espera: restaura el sistema de archivos de red, revisa dmesg en busca de errores de disco. Reinicia solo si el origen es inalcanzable.

Ver también

CliAI no arregla un hilo atascado en el kernel, pero te libra de adivinar flags de ps y awk a las 2 de la madrugada. Instálalo en una línea.