Processus et services : ps, kill, systemctl

Un processus est un programme en cours d'exécution, identifié par un numéro (PID) ; un service est un processus lancé au démarrage et surveillé par systemd, le premier processus du système. Ce chapitre montre comment observer les processus et la charge d'une machine, leur envoyer des signaux, puis piloter les services avec systemctl, écrire une unité systemd pour une application maison et modifier un service existant sans toucher au fichier du paquet.

Observer les processus

Chaque processus a un PID, un processus parent (PPID), un propriétaire, et consomme du processeur et de la mémoire. Le noyau les expose dans /proc/<PID>/.

clambert@srv-web:~$ ps aux | grep [n]ginx
root         620  0.0  0.1  11404  1640 ?        Ss   08:12   0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data     621  0.0  0.3  12960  6196 ?        S    08:12   0:01 nginx: worker process
www-data     622  0.0  0.3  12960  6196 ?        S    08:12   0:01 nginx: worker process

Le processus maître de nginx tourne en root pour ouvrir le port 443, puis lance des processus de travail sous www-data, qui traitent les requêtes : c'est le moindre privilège appliqué par le logiciel lui-même. Les crochets de [n]ginx évitent que grep se trouve lui-même dans la liste.

La charge moyenne (load average) compte les processus qui s'exécutent ou attendent le processeur (ou un disque). Elle se compare au nombre de cœurs : 0.80 sur une machine à 2 cœurs, c'est calme ; 6.00 durablement, des processus font la queue. nproc affiche le nombre de cœurs.

Les signaux

On agit sur un processus en lui envoyant un signal :

pkill nginx et killall nginx envoient un signal par nom. Pour un service, on passe plutôt par systemctl stop ou systemctl kill : systemd sait quels processus appartiennent au service.

Priorité. La valeur nice va de -20 (le plus prioritaire) à 19 (le plus gentil avec les autres), 0 par défaut. nice -n 10 tar czf archive.tgz /srv/journaux lance une compression en arrière-plan sans ralentir le reste ; sudo renice -n 15 -p 2741 change la priorité d'un processus déjà lancé. Seul root peut augmenter une priorité.

Avant-plan et arrière-plan. Dans un terminal, commande & lance en arrière-plan ; Ctrl+Z suspend la commande en cours ; jobs liste, bg relance en arrière-plan, fg ramène au premier plan. Une commande lancée ainsi s'arrête quand la session SSH se ferme : pour un long traitement, utilise nohup commande &, ou mieux une session tmux qu'on retrouve après une déconnexion.

systemd et les unités

systemd est le premier processus lancé par le noyau (PID 1). Il démarre tous les autres, dans le bon ordre, les surveille, les relance s'ils s'arrêtent, et collecte leurs journaux. Il décrit chaque chose à gérer par une unité (unit), un fichier texte :

Les unités livrées par les paquets sont dans /usr/lib/systemd/system/ ; celles de l'administrateur, et ses modifications, dans /etc/systemd/system/, qui a priorité. On ne modifie jamais les fichiers de /usr/lib : une mise à jour du paquet les écraserait.

Piloter un service avec systemctl

clambert@srv-web:~$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since mer. 2026-11-04 08:12:03 CET; 1h 40min ago
       Docs: man:nginx(8)
    Process: 612 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 618 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 620 (nginx)
      Tasks: 3 (limit: 2307)
     Memory: 4.1M (peak: 4.6M)
        CPU: 38ms
     CGroup: /system.slice/nginx.service
             ├─620 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─621 "nginx: worker process"
             └─622 "nginx: worker process"

Trois lignes à lire en premier : Loaded dit où est le fichier et si le service est activé au démarrage (enabled) ; Active dit s'il tourne (active (running)), s'il a échoué (failed) ou s'il est arrêté (inactive (dead)) ; les dernières lignes du journal, sous le cadre, donnent souvent la cause d'un échec.

Écrire une unité pour une application

Le site de suivi des livraisons s'appuie sur une petite application (une API écrite en Python) qui écoute sur 127.0.0.1:8080, derrière nginx. Plutôt que de la lancer à la main dans un terminal, on en fait un service : elle démarrera avec la machine, sera relancée si elle plante, tournera sous un compte dédié sans privilège, et ses messages iront dans le journal.

sudo adduser --system --group --home /opt/suivi suivi    # compte système dédié
sudo nano /etc/systemd/system/suivi-api.service

[Unit]
Description=API du site de suivi des livraisons
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=suivi
Group=suivi
WorkingDirectory=/opt/suivi
ExecStart=/usr/bin/python3 /opt/suivi/app.py
Restart=on-failure
RestartSec=5
UMask=0027
# Durcissement : pas de nouveaux privilèges, système en lecture seule, /tmp privé
NoNewPrivileges=yes
ProtectSystem=full
ProtectHome=yes
PrivateTmp=yes

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now suivi-api
systemctl status suivi-api
journalctl -u suivi-api -f

systemd-analyze verify /etc/systemd/system/suivi-api.service vérifie la syntaxe, et systemd-analyze security suivi-api note l'exposition du service, de 0 (très protégé) à 10, avec la liste des protections qui manquent.

Modifier un service sans toucher au paquet

Pour changer le comportement d'un service fourni par un paquet, on écrit une surcharge (drop-in) : un petit fichier qui ajoute ou remplace des directives. systemctl edit la crée au bon endroit :

sudo systemctl edit nginx

L'éditeur s'ouvre sur /etc/systemd/system/nginx.service.d/override.conf. On y écrit seulement ce qui change :

[Service]
Restart=on-failure
RestartSec=10

À l'enregistrement, systemctl edit recharge la configuration de systemd. systemctl cat nginx affiche le fichier d'origine suivi de la surcharge. Une mise à jour du paquet nginx remplacera son fichier dans /usr/lib, jamais ta surcharge.

Les cibles et le démarrage

Une cible regroupe les unités d'un état du système. Les principales :

systemctl get-default affiche la cible de démarrage (multi-user.target sur un serveur sans bureau). systemd-analyze blame liste les unités les plus lentes au démarrage ; systemd-analyze critical-chain montre la chaîne qui a retardé l'arrivée à la cible. Le démarrage complet, de l'UEFI à la cible, est détaillé avec le dépannage au chapitre 17.

Exercices

● suivi-api.service - API du site de suivi des livraisons
     Loaded: loaded (/etc/systemd/system/suivi-api.service; enabled; preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since mer. 2026-11-04 10:31:12 CET; 3s ago
    Process: 3310 ExecStart=/usr/bin/python3 /opt/suivi/app.py (code=exited, status=1/FAILURE)
   Main PID: 3310 (code=exited, status=1/FAILURE)

nov. 04 10:31:12 srv-web python3[3310]: PermissionError: [Errno 13] Permission denied: '/var/lib/suivi/exports'
nov. 04 10:31:12 srv-web systemd[1]: suivi-api.service: Failed with result 'exit-code'.