Cómo matar un proceso en Linux con kill

Tiempo de lectura: 11 minutos

TL;DR: Para matar un proceso en Linux, primero busca su PID con ps aux | grep nombre, pgrep o top. Luego ejecuta kill PID, que envía la señal SIGTERM (15) y deja que el programa se cierre de forma ordenada. Si en unos segundos no responde, fuérzalo con kill -9 PID (SIGKILL). Si no sabes el PID, killall mata por nombre exacto y pkill por patrón.

Casi siempre basta con dos comandos: uno para identificar el proceso y otro para enviarle una señal. Lo que define si todo sale bien o si se rompe un servicio es elegir bien la señal y asegurarte de que el proceso es el correcto. Esta guía explica las dos cosas con ejemplos reales de un VPS con Ubuntu o Debian.

Para qué sirve saber terminar procesos en un servidor
¿Qué es un proceso y qué es el PID en Linux?
¿Cómo encontrar el PID de un proceso con ps, top y pgrep?
Señales en Linux: SIGTERM, SIGKILL y las que casi nadie usa
Cómo matar un proceso en Linux con kill, paso a paso
kill, killall y pkill: diferencias y cuándo usar cada uno
¿Por qué el proceso vuelve a aparecer después de matarlo?
Errores comunes al matar un proceso en Linux en un VPS
Preguntas frecuentes
Lo que dicen los clientes de Neolo
Conclusión

Para qué sirve saber terminar procesos en un servidor

Si tienes una tienda online, una API en Node.js, un flujo de automatización o un sitio en WordPress en tu propio servidor, tarde o temprano algún proceso se va a colgar. Una tarea programada que no termina nunca, un script de importación que ocupa el 100 % de la CPU o una aplicación que deja el puerto 3000 bloqueado y no te deja volver a levantarla.

En esos momentos no necesitas reiniciar todo el servidor. Si sabes terminar un proceso concreto, puedes:

Recuperar la CPU y la memoria en segundos sin cortar el resto de los servicios.
Liberar un puerto ocupado para volver a desplegar tu aplicación.
Recargar la configuración de un servicio como Nginx sin cortar conexiones.
Evitar que el kernel empiece a cerrar procesos al azar por falta de memoria (el famoso OOM killer).

Para un emprendedor o una pyme que administra su propio servidor, esto marca la diferencia entre cinco minutos de lentitud y una hora con la web caída. Si todavía estás decidiendo qué sistema usar en tu servidor, conviene leer antes la comparación VPS Linux o Windows: cuál elegir, porque todo lo que sigue aplica a Linux.

¿Qué es un proceso y qué es el PID en Linux?

Un proceso es un programa en ejecución. Cada vez que arranca Nginx, PHP-FPM, MySQL o un node app.js, el kernel crea uno o varios procesos y le asigna a cada uno un número único: el PID (Process ID).

Hay algunos datos que conviene tener claros desde el principio:

PID 1 es el sistema de inicio, en casi todas las distribuciones actuales systemd. Está protegido: no se puede matar con una señal normal.
PPID es el PID del proceso padre. Si un proceso padre lanza hijos (por ejemplo, el master de PHP-FPM y sus workers), matar al padre suele arrastrar a los hijos, y matar solo un hijo hace que el padre lance otro.
Estado del proceso: en la columna STAT de ps verás letras como R (ejecutándose), S (durmiendo), D (esperando disco o red, no se puede interrumpir), Z (zombie) o T (detenido). Este detalle explica por qué a veces kill -9 «no funciona».

¿Cómo encontrar el PID de un proceso con ps, top y pgrep?

Antes de matar algo tienes que saber exactamente qué vas a matar. Estas son las formas más útiles de hacerlo.

Con ps

ps aux muestra todos los procesos del sistema con usuario, PID, CPU, memoria y el comando completo:

ps aux | grep node

Una salida típica en un VPS con una aplicación Node colgada:

deploy    48213 98.7  6.1 1254880 249312 ?  Rl  10:02  41:17 node /home/deploy/app/server.js
deploy    51022  0.0  0.0   6480   2240 pts/0 S+  10:44   0:00 grep --color=auto node

La segunda línea es el propio grep y se puede ignorar. El PID que te interesa es 48213, y además ves que consume casi el 99 % de la CPU.

Para ver los procesos que más memoria consumen:

ps aux --sort=-%mem | head -n 10

Con pgrep y pidof

pgrep devuelve directamente el PID, sin ruido. Con -a muestra también el comando completo, que es la mejor forma de confirmar antes de actuar:

pgrep -a node
pidof nginx

Con top o htop

top muestra los procesos en tiempo real. En la práctica, es lo primero que se abre cuando el servidor «anda lento»:

Pulsa Shift + P para ordenar por CPU y Shift + M para ordenar por memoria.
Pulsa k, escribe el PID y confirma la señal (por defecto 15, SIGTERM) para matarlo desde la misma pantalla.

htop es más visual y permite seleccionar el proceso con las flechas y pulsar F9 para elegir la señal. En muchas imágenes mínimas de VPS no viene instalado: sudo apt install htop.

Cuando lo que sabes es el puerto

Si una aplicación no arranca con el error EADDRINUSE o «Address already in use», el problema es un proceso viejo que sigue escuchando en ese puerto:

sudo ss -ltnp | grep :3000
sudo lsof -i :3000

Ambos comandos muestran el PID que tiene ocupado el puerto.

Señales en Linux: SIGTERM, SIGKILL y las que casi nadie usa

kill no «mata» en sentido estricto: envía una señal. El proceso decide qué hacer con ella, salvo en dos casos (SIGKILL y SIGSTOP) que el kernel aplica sin preguntar. Puedes ver la lista completa con kill -l.

Señal	Número	Qué hace	Cuándo usarla
SIGTERM	15	Pide al proceso que termine; puede cerrar archivos y conexiones	Siempre como primera opción (es la que usa `kill` por defecto)
SIGKILL	9	El kernel elimina el proceso de inmediato; no se puede capturar	Solo si SIGTERM no funcionó tras unos segundos
SIGINT	2	Equivale a pulsar Ctrl + C	Interrumpir un script lanzado en primer plano
SIGHUP	1	Muchos daemons la interpretan como «recarga la configuración»	Recargar Nginx o rsyslog sin cortar el servicio
SIGSTOP	19 (x86/ARM)	Congela el proceso sin terminarlo	Pausar un proceso pesado para investigarlo
SIGCONT	18 (x86/ARM)	Reanuda un proceso detenido	Continuar tras SIGSTOP

La diferencia práctica entre SIGTERM y SIGKILL es enorme. Con SIGTERM, MySQL escribe lo que tiene pendiente, Node cierra las conexiones y un script de backup borra sus archivos temporales. Con SIGKILL el proceso desaparece en mitad de lo que estuviera haciendo: pueden quedar archivos .lock, tablas que necesitan reparación o un archivo comprimido a medias.

Los números de SIGSTOP y SIGCONT cambian según la arquitectura (en MIPS o SPARC son otros). Por eso, en scripts conviene escribir el nombre: kill -SIGTERM, kill -TERM o kill -s TERM funcionan en cualquier sistema.

Cómo matar un proceso en Linux con kill, paso a paso

Este es el procedimiento que se sigue en un VPS de producción cuando una aplicación se queda colgada. El ejemplo usa el proceso Node del apartado anterior (PID 48213) en Ubuntu 24.04 LTS, pero es igual en Debian, AlmaLinux o Rocky Linux.

Conéctate al servidor por SSH con un usuario con permisos de sudo. Si solo tienes acceso como root o necesitas configurarlo, aquí se explica cómo habilitar Root SSH de forma segura.

ssh deploy@203.0.113.25

Identifica el proceso y confirma el comando completo para no equivocarte de PID.

pgrep -a node

Revisa quién es el dueño del proceso y si tiene un proceso padre que lo vuelva a lanzar.

ps -o pid,ppid,user,stat,etime,cmd -p 48213

Envía SIGTERM para pedirle que se cierre de forma ordenada.

kill 48213

Si el proceso pertenece a otro usuario (por ejemplo, www-data o mysql), necesitarás sudo kill 48213.

Comprueba si terminó. kill -0 no envía ninguna señal: solo verifica si el proceso sigue existiendo.

sleep 5; kill -0 48213 && echo "Sigue vivo" || echo "Terminado"

Fuerza el cierre con SIGKILL solo si sigue vivo después de esperar.

kill -9 48213

Investiga la causa para que no vuelva a pasar: revisa los logs de la aplicación y comprueba si el kernel cerró algo por falta de memoria.

sudo journalctl -u miapp --since "30 min ago"
sudo dmesg -T | grep -i "killed process"

Para cerrar varios procesos a la vez, kill acepta varios PID: kill 48213 48214 48220. Y si quieres terminar un grupo de procesos completo (un script y todos sus hijos), puedes enviar la señal al grupo con el PGID precedido de un guion: kill -- -48200.

kill, killall y pkill: diferencias y cuándo usar cada uno

Los tres envían señales y por defecto usan SIGTERM. Cambia la forma de elegir el objetivo.

Criterio	kill	killall	pkill
Cómo identifica el proceso	Por PID	Por nombre exacto	Por patrón (expresión regular)
Paquete en Debian/Ubuntu	Integrado en bash y `procps`	`psmisc`	`procps`
Ejemplo	`kill 48213`	`killall php-fpm8.3`	`pkill -f "server.js"`
Riesgo de matar algo que no querías	Bajo	Medio	Alto si el patrón es corto
Opción útil	`kill -0` para comprobar	`-i` pide confirmación	`pgrep` para probar antes

killall: por nombre exacto

sudo killall -w php-fpm8.3

La opción -w espera a que todos los procesos terminen antes de devolverte la terminal, algo muy útil dentro de scripts. Otras opciones prácticas son -u usuario para limitarlo a un usuario e -i para que pida confirmación uno por uno.

Un detalle que se aprende con la práctica: en imágenes mínimas de Debian o en contenedores, killall no viene instalado y aparece command not found. Se instala con sudo apt install psmisc. Y si alguna vez administras un servidor Solaris, ten cuidado: allí killall termina todos los procesos del sistema.

pkill: por patrón

pgrep -af "worker.py"    # primero mira qué coincide
pkill -f "worker.py"     # luego mata exactamente eso

pkill compara por defecto con el nombre del proceso, que el kernel limita a 15 caracteres. Con -f busca en la línea de comandos completa, lo cual es imprescindible para scripts de Python o Node, donde el nombre del proceso es python3 o node. Otras opciones útiles:

pkill -x nginx: coincidencia exacta, no parcial.
pkill -u deploy: todos los procesos de un usuario.
pkill -HUP rsyslogd: enviar otra señal distinta de SIGTERM.

La regla de oro: todo pkill va precedido de un pgrep con los mismos argumentos. pkill php mata php-fpm, php8.3, el script de un compañero y cualquier cosa que contenga esas tres letras.

Hacer todo esto exige un servidor donde tengas acceso root y SSH real, algo que un hosting compartido no ofrece. Para quien ya ejecuta aplicaciones Node, Python, Docker o n8n, Neolo ofrece un hosting VPS con root completo y servidores en varias regiones del mundo. Si algo se complica en mitad de una emergencia, su soporte combina personas reales con herramientas de IA y responde el 80 % de las consultas en menos de una hora.

¿Por qué el proceso vuelve a aparecer después de matarlo?

Es una de las situaciones más confusas para quien empieza: matas el proceso, ejecutas pgrep y aparece otra vez con un PID nuevo. No es un error, es que hay algo encargado de mantenerlo vivo.

Servicios gestionados por systemd

Si el servicio tiene Restart=always o Restart=on-failure en su unidad, systemd lo vuelve a lanzar en cuanto muere. En ese caso, lo correcto es pararlo desde systemd:

sudo systemctl stop miapp
sudo systemctl kill --signal=SIGKILL miapp   # solo si stop no responde

Al hacer systemctl stop, systemd envía SIGTERM y, si el servicio no termina dentro de TimeoutStopSec (90 segundos por defecto), envía SIGKILL. Lo mismo pasa con gestores como PM2 (pm2 stop app) o Supervisor (supervisorctl stop app): si matas el proceso por fuera, el gestor lo resucita.

Contenedores Docker

docker stop envía SIGTERM al proceso principal del contenedor y, si no termina en 10 segundos, envía SIGKILL. docker kill envía SIGKILL directamente.

Hay un matiz que provoca muchos dolores de cabeza: dentro del contenedor tu aplicación corre como PID 1, y el kernel no aplica la acción por defecto de SIGTERM al PID 1 si el programa no la maneja explícitamente. Por eso algunos contenedores tardan siempre exactamente 10 segundos en pararse. La solución es manejar SIGTERM en el código o arrancar el contenedor con docker run --init, que añade un pequeño proceso init (tini) que reenvía las señales.

Video: qué hosting usar con Docker

Procesos zombie y procesos en estado D

Un proceso en estado Z (zombie) ya terminó: solo queda su entrada en la tabla de procesos, esperando que el padre la recoja. No se puede matar porque no hay nada que matar. Se resuelve terminando o reiniciando el proceso padre (búscalo con ps -o ppid= -p PID).

Un proceso en estado D está esperando una operación de disco o de red (por ejemplo, un montaje NFS caído). Ni siquiera SIGKILL lo elimina hasta que esa operación termina. Si se acumulan muchos, el problema está en el almacenamiento, no en el proceso.

Errores comunes al matar un proceso en Linux en un VPS

Usar kill -9 como primera opción. Es el error más extendido. En MySQL o MariaDB puede obligar a una recuperación al arrancar, y en aplicaciones que escriben archivos puede dejarlos corruptos. Antes de tocar procesos de bases de datos, asegúrate de tener copias de seguridad recientes.
Matar el PID que aparece en la línea del propio grep. Ese proceso ya terminó; usa pgrep -a para evitar la confusión.
Matar workers de PHP-FPM uno por uno. El proceso master los vuelve a lanzar, y si matas al master sin volver a levantarlo, la web empieza a responder con el error 503 Service Unavailable. Lo correcto es sudo systemctl restart php8.3-fpm.
Ejecutar kill -9 -1. El -1 significa «todos los procesos que puedo matar». Como root, deja el servidor inaccesible y obliga a reiniciarlo desde el panel.
Matar procesos en vez de reiniciar el servicio. Si existe una unidad de systemd, systemctl restart es más limpio y queda registrado en el journal.
No investigar por qué se colgó. Si una tarea cron se cuelga todas las noches, matarla cada mañana no es una solución. Envolverla con timeout limita su duración automáticamente:

timeout -k 10 3600 /home/deploy/scripts/importar.sh

Este comando envía SIGTERM al cabo de una hora y SIGKILL diez segundos después si el script sigue vivo.

Preguntas frecuentes

¿Qué diferencia hay entre kill -9 y kill -15?

kill -15 envía SIGTERM, que pide al proceso que termine y le da tiempo para cerrar archivos, conexiones y transacciones. kill -9 envía SIGKILL: el kernel elimina el proceso de inmediato, sin que este pueda reaccionar. Conviene usar siempre -15 primero y recurrir a -9 solo si el proceso no responde después de unos segundos.

¿Por qué no puedo matar un proceso zombie en Linux?

Un proceso zombie ya terminó su ejecución. Solo queda su registro en la tabla de procesos, esperando que el proceso padre lea su código de salida. Como no hay nada en ejecución, ninguna señal lo afecta. Para eliminarlo hay que identificar al padre con ps -o ppid= -p PID y reiniciarlo o terminarlo; entonces systemd recoge al zombie.

¿Cómo matar un proceso que ocupa un puerto en Linux?

Primero identifica qué proceso escucha en el puerto con sudo ss -ltnp | grep :3000 o sudo lsof -i :3000, que muestran el PID. Después envía kill PID. También puedes usar sudo fuser -k 3000/tcp, que localiza y termina el proceso en un solo paso, aunque conviene revisar antes qué estás cerrando para no cortar un servicio necesario.

¿Cómo terminar todos los procesos de un usuario en Linux?

Usa sudo pkill -u nombreusuario o sudo killall -u nombreusuario. Ambos envían SIGTERM a todos los procesos de ese usuario. Primero comprueba qué se verá afectado con pgrep -u nombreusuario -a. Es útil cuando una cuenta comprometida o un usuario de despliegue tiene scripts descontrolados, pero no lo ejecutes nunca sobre root ni sobre usuarios de sistema como mysql.

¿Se pierden datos al usar kill -9?

Puede pasar. SIGKILL no deja que el proceso guarde lo que tenía en memoria, así que se pierden las escrituras pendientes, quedan transacciones incompletas o archivos a medio generar. Las bases de datos modernas como MySQL con InnoDB o PostgreSQL se recuperan usando su registro de transacciones, pero los archivos temporales y las exportaciones a medias suelen quedar inservibles. Por eso SIGKILL es el último recurso.

¿Cómo matar un proceso en Linux sin conocer el PID?

Puedes usar killall nombre, que mata por nombre exacto del proceso, o pkill patrón, que busca coincidencias parciales. Para scripts de Python o Node, añade -f a pkill para buscar en la línea de comandos completa, por ejemplo pkill -f server.js. Antes de ejecutarlo, prueba el mismo patrón con pgrep -af para ver exactamente qué procesos coinciden.

¿Para qué sirve kill -HUP?

kill -HUP envía SIGHUP. Originalmente indicaba que se había cortado la terminal, pero muchos daemons lo interpretan como una orden para recargar su configuración sin detenerse. Por ejemplo, sudo kill -HUP $(cat /run/nginx.pid) hace que Nginx relea sus archivos y renueve sus workers sin cortar las conexiones activas. Si un programa no maneja esta señal, SIGHUP lo termina.

Lo que dicen los clientes de Neolo

★★★★★ Larisa Navarro
«Me contestan absolutamente todo y no pierden la paciencia. No es solo que me contestan, sino que me ayudan.»

★★★★★ Mauro Lopreste
«Llevo muchos años alojando mis webs en Neolo. La atención siempre fue excelente.»

★★★★★ Bruno Balzani
«Cliente desde 2009. Neolo lo que tiene es la mejor atención, pero por lejos.»

Conclusión

Matar un proceso en Linux se reduce a una secuencia fija: identificar el PID con pgrep -a, ps o top; enviar SIGTERM con kill; esperar; y solo entonces usar kill -9. killall y pkill ahorran tiempo cuando no conoces el PID, pero siempre conviene comprobar antes qué coincide. Y si el proceso vuelve a aparecer, pararlo desde systemd, PM2 o Docker es lo correcto.

Para practicar todo esto necesitas un servidor con acceso root. Neolo es una opción sólida para pymes y desarrolladores que se administran su propio servidor: es una empresa bootstrapped que opera desde 2002, se financia con sus propios clientes y ofrece garantía de reembolso de 30 días. Puedes revisar los planes de hosting VPS con acceso root y elegir el que se ajuste a lo que ejecutas hoy.

Unas notas sobre las decisiones que tomé:

Video: usé «¿Qué Hosting usar con Docker?» porque encaja con el apartado sobre señales en contenedores.
Categoría: ninguna de la lista es de Linux o servidores, así que elige desarrollo-web.
Menciones de Neolo: escribe el nombre solo 3 veces en mi propio texto. Dos de las reseñas lo incluyen y no se podían alterar. Si quieres que el nombre aparezca menos veces en total, puedes cambiar la reseña de Bruno o la de Mauro por la de Nuria.
Enlaces a Neolo: son tres. Dos van al hosting VPS (la recomendación a mitad del artículo y la conclusión) y uno a copias de seguridad, en la sección de errores comunes. Además, la imagen enlaza a la página de planes VPS.
Enlaces al blog: elige tres: Root SSH, VPS Linux o Windows y el error 503.