infra / linux-bash
Processus et services (ps, top, kill, systemctl)
Explication
Chaque programme en cours d'exécution — un navigateur, un serveur web, ton propre script — devient un processus dès qu'il démarre, identifié par un numéro unique appelé le PID. Comprendre les processus, c'est comprendre ce qui se passe "sous le capot" de la machine à tout instant, et savoir intervenir dessus sans tout casser.
Ce que vous allez apprendre
- Observer les processus actifs et leur consommation avec
ps aux,topetpstree - Comprendre la différence entre
SIGTERM(arrêt propre) etSIGKILL(arrêt brutal) - Savoir pourquoi un processus lancé en SSH s'arrête à la déconnexion, et comment l'éviter avec
nohup - Utiliser
jobs,fg,bgpour gérer des tâches au premier plan et en arrière-plan - Gérer un service durablement avec
systemctlplutôt que de lancer un binaire à la main
Dans quel contexte ?
Un ingénieur DevOps lance un script de migration de base de données qui doit tourner 45 minutes, via une connexion SSH sur un serveur distant. S'il ferme son terminal par erreur, ou si sa connexion réseau coupe, le script s'arrête net au milieu de la migration — sauf s'il a pensé à le lancer avec nohup ou à le confier à un service systemd. C'est exactement le genre de situation que cette leçon prépare à éviter.
Une fois qu'on a des processus, comment leur parler ?
On n'arrête pas un programme en l'"éteignant" physiquement comme un interrupteur. On lui envoie un signal, une sorte de message que le processus peut choisir d'écouter ou d'ignorer.
| Signal | Commande | Effet |
|---|---|---|
| SIGTERM (15) | kill 1234 | Demande polie : le programme peut fermer proprement |
| SIGKILL (9) | kill -9 1234 | Arrêt immédiat et brutal, sans nettoyage possible |
| SIGHUP (1) | kill -HUP 1234 | Souvent utilisé pour recharger la config sans redémarrer |
SIGTERM demande poliment l'arrêt : le programme a alors l'occasion de fermer proprement ses fichiers et sauvegarder son état. SIGKILL, au contraire, est exécuté par le noyau sans que le programme ait son mot à dire.
Piège fréquent
Réserve kill -9 au tout dernier recours : un processus tué en SIGKILL n'a pas l'occasion de fermer proprement ses fichiers ouverts ou ses connexions à une base de données, ce qui peut corrompre des données en cours d'écriture. Essaie toujours kill (SIGTERM) en premier et laisse quelques secondes avant d'escalader.
Il reste un problème : que devient un processus quand tu fermes ton terminal ?
Un processus lancé normalement "occupe" ton terminal jusqu'à ce qu'il se termine. Concrètement, fermer le terminal (ou perdre la connexion SSH) lui envoie un signal qui l'arrête automatiquement. C'est un problème très concret dès que tu travailles sur un serveur distant et que tu veux qu'un traitement continue même après ta déconnexion.
Des outils comme nohup existent précisément pour ça : ils rendent un processus "sourd" à ce signal de fermeture. Le processus continue alors à tourner même après que tu t'es déconnecté.
Maintenant que tu sais gérer un processus isolé, voyons les services
systemctl ne se contente pas de lancer un programme : il délègue toute sa gestion à systemd, le "chef d'orchestre" moderne des services Linux. Cela inclut le démarrage automatique au boot, le redémarrage en cas de crash, et la journalisation de son activité.
Bonne pratique
Pour un service qui doit tourner en continu (une API, un serveur web), préfère toujours systemctl à nohup ... & : systemctl redémarre automatiquement le service s'il plante, ce que nohup seul ne fait jamais. nohup reste pertinent pour une tâche ponctuelle lancée à la main.
Une fois cette leçon en tête, tu es prêt à écrire tes propres scripts bash, la brique suivante pour automatiser tout ce que tu viens d'apprendre.
Commandes & code
Processus et services
ps aux # tous les processus, format BSD (user, %cpu, %mem, cmd)
ps aux | grep nginx # filtrer un processus par nom
ps -ef # format System V (PPID visible, utile pour l'arbre)
ps -ef --forest # affiche l'arborescence parent/enfant
pstree # arbre des processus, plus lisible
pstree -p # avec les PID
top # vue temps réel (interactive)
# Dans top : q quitte, k tue un process, M trie par mémoire, P trie par CPU
# Envoyer un signal à un processus
kill 1234 # SIGTERM : demande poliment l'arrêt
kill -9 1234 # SIGKILL : tue immédiatement, sans nettoyage
kill -HUP 1234 # SIGHUP : souvent utilisé pour recharger la config
killall nginx # tue tous les processus nommés "nginx"
pkill -f "python manage.py" # tue par pattern sur la ligne de commande complète
# Premier / arrière-plan
long_script.sh & # lance en arrière-plan, retourne la main tout de suite
jobs # liste les jobs en arrière-plan du shell courant
fg %1 # ramène le job 1 au premier plan
bg %1 # relance le job 1 en arrière-plan (après un Ctrl+Z)
disown %1 # détache le job : il survivra à la fermeture du shell
nohup long_script.sh & # ignore SIGHUP : survit à la déconnexion SSH
# Services avec systemctl (systemd)
systemctl status nginx # état du service
systemctl start nginx # démarre
systemctl stop nginx # arrête
systemctl restart nginx # redémarre (coupe puis relance)
systemctl reload nginx # recharge la config sans couper les connexions
systemctl enable nginx # démarre automatiquement au boot
systemctl disable nginx # retire du démarrage automatique
systemctl is-enabled nginx # vérifie si activé au boot
systemctl list-units --type=service --state=running # tous les services actifs
# Priorité d'un processus (nice = -20 le plus prioritaire, 19 le moins prioritaire)
nice -n 10 ./tache_lourde.sh # lance avec une priorité basse
renice -n 5 -p 1234 # change la priorité d'un process déjà lancéRésumé
ps aux/top/pstreepour observer,kill/pkillpour agir.SIGTERM(défaut) laisse le programme se fermer proprement ;SIGKILL(-9) est brutal.systemctlest l'outil standard pour gérer les services sur les distributions modernes.
Exercices pratiques
Mission : sécuriser une migration de base de données lancée en SSH
Objectif : Lancer un traitement long qui survit à une déconnexion SSH, puis choisir la bonne méthode d'arrêt et de supervision.
Contexte
Tu es connecté en SSH sur un serveur de production pour lancer ~/scripts/migrate_db.sh, une migration PostgreSQL qui doit tourner 45 minutes. Ta connexion réseau est instable et tu ne peux pas rester connecté en continu. Tu dois garantir que le script survive à une déconnexion, puis savoir réagir si quelque chose tourne mal pendant qu'il écrit dans la base.