Gérer les services avec systemd

Module 6: Services et journaux · Temps de lecture : 10 minutes

Objectif pédagogique : À l'issue de cette leçon, vous saurez démarrer, arrêter et recharger des services et les lancer au démarrage, lire l'état d'un service et modifier un paramètre d'un service en toute sécurité grâce à un drop-in.

Notions clés : systemd, unit, service, systemctl, start, stop, restart, reload, enable, disable, --now, active, inactive, failed, systemctl --failed, drop-in, systemctl edit, daemon-reload, Restart=

Qui fait tout tourner ?

Sur un serveur tournent des dizaines de programmes qui doivent toujours être présents : le serveur SSH, le serveur web, une base de données, la synchronisation de l'heure. Ces programmes s'appellent des services (ou daemons). Quelqu'un doit les lancer au démarrage, les surveiller et les relancer s'ils tombent. Sur Debian, Ubuntu, AlmaLinux et Rocky Linux, c'est le rôle de systemd. C'est le premier programme que lance le noyau (processus 1), et c'est lui qui démarre ensuite tout le reste.

systemd travaille avec des units (unités) : des descriptions de ce qu'il doit gérer. Les principaux types :

Vous communiquez avec systemd au moyen de la commande systemctl. Vous pouvez omettre l'extension .service : systemctl status nginx équivaut à systemctl status nginx.service.

Lire l'état

La commande que vous utiliserez le plus souvent :

anna@web1:~$ 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 Mon 2026-11-09 08:12:44 CET; 3h 2min ago
       Docs: man:nginx(8)
    Process: 902 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 905 (nginx)
      Tasks: 3 (limit: 2275)
     Memory: 4.1M (peak: 6.3M)
        CPU: 213ms
     CGroup: /system.slice/nginx.service
             ├─905 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             └─906 "nginx: worker process"

nov 09 08:12:44 web1 systemd[1]: Starting nginx.service - A high performance web server...
nov 09 08:12:44 web1 systemd[1]: Started nginx.service - A high performance web server...

Lisez-la de haut en bas :

• La pastille devant le nom est verte pour un service en cours d'exécution, blanche pour un service arrêté et rouge pour un service en échec.
• Loaded indique où se trouve le fichier d'unité et si le service démarre au démarrage du système (enabled) ou non (disabled).
• Active indique s'il tourne actuellement (active (running)), s'il est arrêté (inactive (dead)) ou en échec (failed), et depuis quand.
• Main PID et CGroup montrent quels processus appartiennent au service.
• En bas figurent les dernières lignes du journal du service. Souvent, la raison d'un problème s'y trouve déjà ; pour en lire davantage, utilisez journalctl (leçon 6.2).

Démarrer, arrêter, redémarrer et recharger

anna@web1:~$ sudo systemctl start nginx      # démarrer maintenant
anna@web1:~$ sudo systemctl stop nginx       # arrêter maintenant
anna@web1:~$ sudo systemctl restart nginx    # arrêter puis redémarrer
anna@web1:~$ sudo systemctl reload nginx     # relire la configuration sans arrêter

La différence entre restart et reload est importante en pratique. Lors d'un restart, le service s'arrête un instant : les connexions en cours sont coupées et, si la nouvelle configuration contient une erreur, il ne redémarre plus et votre site est hors ligne. Lors d'un reload, le service relit sa configuration tout en continuant de tourner ; en cas d'erreur dans la configuration, nginx conserve l'ancienne. Après une modification de configuration, utilisez donc reload pour nginx, Caddy, SSH et fail2ban, et testez d'abord la configuration (nginx -t, sshd -t, fail2ban-client -t). Tous les services ne prennent pas en charge reload ; systemctl reload-or-restart choisit de lui-même.

Au démarrage : enable et disable

Démarrer un service et le faire "démarrer au démarrage du système" sont deux choses différentes :

anna@web1:~$ sudo systemctl enable nginx         # démarre désormais au démarrage du système
anna@web1:~$ sudo systemctl disable nginx        # ne démarre plus au démarrage du système
anna@web1:~$ sudo systemctl enable --now nginx   # les deux : démarrer maintenant et au démarrage du système
anna@web1:~$ systemctl is-enabled nginx
enabled

Une erreur classique : vous lancez un service avec start, tout fonctionne, et après le redémarrage suivant (par exemple suite à une mise à jour du noyau, leçon 4.2), il a disparu. Pour un nouveau service, utilisez donc enable --now.

Si vous voulez être certain qu'un service ne démarre jamais, même si un autre service le demande, il existe mask : sudo systemctl mask <dienst>. Pour annuler : unmask.

Qu'est-ce qui ne va pas ?

Une seule commande affiche toutes les unités en échec :

anna@web1:~$ systemctl --failed
  UNIT                LOAD   ACTIVE SUB    DESCRIPTION
● php8.4-fpm.service  loaded failed failed The PHP 8.4 FastCGI Process Manager

1 loaded units listed.

Prenez-en l'habitude, par exemple après chaque redémarrage et chaque mise à niveau (leçon 4.3) : la liste doit être vide. Une fois le problème résolu, supprimez le signalement avec sudo systemctl reset-failed.

Un aperçu de tous les services en cours d'exécution :

anna@web1:~$ systemctl list-units --type=service --state=running

Si quelque chose tourne que vous ne connaissez pas ou n'utilisez pas, renseignez-vous sur ce que c'est. Chaque service inutile représente une surface d'attaque superflue (leçons 5.1 et 10.1).

Fichiers d'unité et drop-ins

Un fichier d'unité est un fichier texte. La version fournie par le paquet se trouve dans /usr/lib/systemd/system/ (sur les systèmes plus anciens, /lib/systemd/system/). Vous ne la modifiez jamais : une mise à jour du paquet l'écrase. Vos propres modifications vont dans un drop-in : un petit fichier qui ne contient que les lignes que vous voulez changer. Le plus simple est d'utiliser :

anna@web1:~$ sudo systemctl edit nginx

Un éditeur s'ouvre avec une zone vide entre deux lignes de commentaire. Ce que vous y écrivez est enregistré dans /etc/systemd/system/nginx.service.d/override.conf. Par exemple : relancer automatiquement nginx s'il s'arrête de façon inattendue.

[Service]
Restart=on-failure
RestartSec=5s

Après l'enregistrement, systemctl edit recharge automatiquement la configuration de systemd. Si vous modifiez un fichier d'unité d'une autre manière, faites-le vous-même :

anna@web1:~$ sudo systemctl daemon-reload
anna@web1:~$ sudo systemctl restart nginx

daemon-reload fait relire les fichiers d'unité à systemd ; le service lui-même doit ensuite être redémarré pour appliquer la modification. Le résultat complet (original et drop-ins) s'affiche avec systemctl cat nginx.

Restart=on-failure est une bonne habitude pour les services importants. Mais n'y cachez pas une vraie panne : un service qui plante et redémarre toutes les cinq secondes mérite qu'on consulte son journal. Après quelques échecs rapides successifs, systemd cesse de le relancer (la limite par défaut est de cinq démarrages en dix secondes) et met le service en état failed.

Sur AlmaLinux et Rocky Linux

systemd et systemctl fonctionnent exactement de la même manière. Seuls les noms des services diffèrent parfois : le service SSH s'appelle sshd, le serveur web de la distribution s'appelle httpd (Apache) ou nginx, et le pare-feu firewalld.

En pratique

L'écran VPS de votre fournisseur (chez WebOké comme ailleurs) permet d'éteindre le serveur entier, de le redémarrer ou de le "forcer à s'éteindre". Cette dernière option équivaut à débrancher la prise : les services n'ont pas l'occasion de s'arrêter proprement et une base de données peut alors être endommagée. Depuis le serveur, utilisez sudo systemctl reboot ou sudo shutdown -h now, et dans le panneau, le bouton normal pour éteindre ou redémarrer.

Résumé

• systemd démarre et surveille tous les services ; vous le pilotez avec systemctl.
• systemctl status indique si un service tourne, s'il démarre au démarrage du système, et affiche les dernières lignes du journal.
• start/stop/restart agissent sur l'instant présent, enable/disable sur le démarrage ; utilisez enable --now pour un nouveau service.
• Après une modification de configuration : d'abord tester, puis reload ; systemctl --failed doit être vide.
• Ne modifiez jamais le fichier d'unité d'un paquet, utilisez plutôt un drop-in avec systemctl edit.

Quiz

Exercice

Exercice O6.1 : Cartographier vos services. Sur votre serveur, dressez la liste de tous les services en cours d'exécution (systemctl list-units --type=service --state=running) et vérifiez que systemctl --failed est vide. Pour chaque service, indiquez ce qu'il fait et si vous en avez besoin. Pour un service que vous ne connaissiez pas, renseignez-vous sur ce que c'est (systemctl status, man). Ensuite, pour un service important, ajoutez Restart=on-failure dans un drop-in et vérifiez avec systemctl cat qu'il est bien présent.

Pour aller plus loin

• Manuel systemctl(1) : https://manpages.debian.org/trixie/systemd/systemctl.1.en.html
• Manuel systemd.service(5) (Restart=) : https://manpages.debian.org/trixie/systemd/systemd.service.5.en.html
• Manuel systemd.unit(5) (drop-ins) : https://manpages.debian.org/trixie/systemd/systemd.unit.5.en.html