Kill sous Linux : arrêter un processus sans couper le mauvais service

Un processus Linux qui bloque le CPU, garde un port ouvert ou refuse de se fermer peut vite donner envie de lancer un kill -9. Je vous le déconseille en premier réflexe. La bonne méthode consiste à identifier clairement le PID, comprendre si le processus dépend d’un service, puis envoyer un signal propre avant de forcer.

Dans ce guide, on va voir comment arrêter un processus sous Linux sans couper le mauvais service, sans casser une base de données et sans fermer une session active par erreur.

Pourquoi il ne faut pas tuer un processus au hasard

La commande kill ne cherche pas un programme par son nom. Elle envoie un signal à un ou plusieurs PID, c’est-à-dire des identifiants de processus. Si vous ciblez le mauvais PID, Linux exécutera quand même la demande.

Le risque est surtout présent sur un serveur : un processus peut être un worker web, une session SSH, une tâche de sauvegarde, un serveur de base de données ou un service lancé par systemd. Avant d’agir, je préfère toujours répondre à trois questions : quel processus pose problème, à quel utilisateur il appartient, et quel service l’a lancé.

Retrouver le PID avant d’agir

Pour une vue simple, commencez par ps. Cette commande évite de cliquer dans un outil interactif et vous laisse copier le PID proprement.

ps -eo pid,ppid,user,stat,cmd --sort=pid | less

Si vous cherchez un service ou une commande précise, utilisez pgrep avec l’option -a. Elle affiche le PID et la ligne de commande associée.

pgrep -a nginx
pgrep -a php-fpm
pgrep -a -u www-data php

Si vous préférez une vue plus lisible de la charge, vous pouvez aussi passer par htop sous Linux. Gardez simplement en tête que l’outil vous aide à repérer le suspect, pas à décider tout seul ce qu’il faut tuer.

Vérifier si le processus dépend d’un service

Avant d’envoyer un signal, regardez si le PID appartient à un service systemd. C’est souvent plus propre d’arrêter ou de redémarrer le service plutôt que de tuer un processus isolé.

systemctl status nginx --no-pager
systemctl status php8.4-fpm --no-pager

Si vous ne connaissez pas le nom exact du service, la liste des services peut aider. J’ai détaillé cette partie dans le guide sur systemctl et la liste des services Linux.

Regardez aussi les journaux avant de couper. Ils donnent souvent la cause réelle : fichier absent, port déjà utilisé, limite mémoire, erreur de droits ou boucle applicative.

journalctl -u nginx -n 80 --no-pager
journalctl -u nginx -f

Pour suivre un fichier de log applicatif en direct, tail sous Linux reste pratique, surtout quand le service n’écrit pas tout dans le journal systemd.

Comprendre TERM, KILL et les signaux utiles

Le nom kill est trompeur. La commande sert surtout à envoyer un signal. Par défaut, elle envoie SIGTERM, un signal propre qui demande au processus de s’arrêter.

kill -l

Les trois signaux que vous croiserez le plus souvent sont :

• TERM ou 15 : demande d’arrêt propre. C’est le signal à essayer en premier.
• HUP ou 1 : souvent utilisé pour demander à un service de relire sa configuration, selon le programme.
• KILL ou 9 : arrêt forcé immédiat. Le processus ne peut pas nettoyer ses fichiers, fermer correctement ses connexions ou écrire son état.

Les pages de manuel de kill et signal documentent ces signaux. En pratique, retenez surtout ceci : -9 est un dernier recours, pas une commande de confort.

Arrêter un processus proprement avec kill

Une fois le bon PID confirmé, envoyez d’abord un TERM. Exemple avec le PID 1234 :

sudo kill -TERM 1234

Patientez quelques secondes, puis vérifiez si le processus existe encore :

ps -p 1234 -o pid,stat,cmd

S’il a disparu, ne faites rien de plus. Regardez plutôt les logs pour comprendre pourquoi vous avez dû l’arrêter.

journalctl -n 80 --no-pager

Si le processus reste bloqué et que vous avez validé qu’il ne doit plus continuer, vous pouvez forcer :

sudo kill -KILL 1234

Je réserve cette commande aux processus réellement coincés. Sur une base de données, un traitement de fichier ou une sauvegarde, un arrêt forcé peut laisser un état sale. Ce n’est pas systématiquement catastrophique, mais ce n’est pas anodin.

Quand passer par systemctl plutôt que kill

Si le processus appartient à un service, utilisez systemd. Vous gardez une trace plus propre et vous laissez le gestionnaire de service appliquer la bonne séquence d’arrêt.

sudo systemctl stop nginx
sudo systemctl restart nginx
systemctl status nginx --no-pager

Après un redémarrage, contrôlez rapidement l’état du service et les erreurs récentes :

systemctl is-active nginx
systemctl --failed
journalctl -u nginx -b --no-pager

Pour les services critiques, je garde aussi une session ouverte et je teste une nouvelle connexion avant de fermer l’ancienne. C’est particulièrement vrai sur SSH, les pare-feu, les services réseau et les machines distantes sans console de secours.

Utiliser pkill sans faire trop large

pkill permet d’envoyer un signal à des processus trouvés par nom ou motif. C’est pratique, mais dangereux si le motif est trop vague.

Avant de tuer quoi que ce soit, listez ce qui correspond avec pgrep. La page de manuel de pgrep et pkill rappelle justement que ces outils travaillent sur des motifs.

pgrep -a -f 'script-maintenance'
pgrep -a -u deploy 'python'

Si la liste est correcte, envoyez un signal propre :

sudo pkill -TERM -f 'script-maintenance'

Évitez les motifs trop courts comme php, python ou node sur un serveur partagé. Vous risquez d’arrêter plusieurs applications qui n’ont rien à voir avec votre incident.

Vérifier après l’arrêt du processus

Une fois le processus arrêté, ne partez pas tout de suite. Vérifiez au minimum l’état système, le service concerné et les journaux. C’est souvent là que l’on voit si le problème est réglé ou s’il va revenir dans cinq minutes.

systemctl --failed
journalctl -p warning..alert -b --no-pager
ps -eo pid,user,stat,cmd --sort=-%cpu | head

Si le problème était un port bloqué, contrôlez aussi quel processus l’écoute encore :

sudo ss -ltnp | grep ':80'
sudo ss -ltnp | grep ':443'

Et si vous devez relire les journaux du dernier démarrage, le guide sur journalctl après un redémarrage Linux complète bien cette partie.

Si le processus revient tout seul

Un processus qui revient immédiatement n’est pas forcément un problème. Il peut être relancé par systemd, un superviseur, un cron, un timer ou une application principale. Dans ce cas, tuer le PID en boucle ne sert à rien.

systemctl status nom-du-service --no-pager
systemctl list-timers --all
crontab -l
sudo crontab -l

Le plus propre est alors de corriger la cause : configuration, dépendance absente, boucle applicative, droit de fichier, port occupé ou limite mémoire. kill sert à reprendre le contrôle. Il ne remplace pas le diagnostic.

sudo apt update && sudo apt upgrade