systemd : ce que c'est, son fonctionnement et la gestion des services sous Linux

systemd est le système d'initialisation et le gestionnaire de services utilisé par la plupart des distributions Linux modernes : Debian, Ubuntu, Fedora, RHEL et leurs dérivés. Après le démarrage, le noyau lance systemd comme premier processus, de PID 1, puis celui-ci met en route le réseau, monte les disques, démarre le serveur web, la base de données et tout le reste. En résumé, systemd est le « répartiteur » qui sait quels services doivent tourner, dans quel ordre les démarrer et quoi faire lorsqu'un service tombe.

Pour vérifier que vous utilisez systemd, il suffit de lancer :

$ ps -p 1 -o comm=
systemd

Pourquoi systemd a été créé

Auparavant, Linux utilisait SysV init : un ensemble de scripts shell dans /etc/init.d/, exécutés les uns après les autres. Ce schéma était compréhensible, mais lent et fragile. Chaque script écrivait son propre fichier PID, décidait seul de la manière de vérifier qu'un processus était vivant, et il fallait ajouter séparément le redémarrage d'un service tombé.

systemd résout ces problèmes de façon centralisée :

• Démarrage parallèle. Les services démarrent simultanément lorsqu'il n'existe pas de dépendance entre eux, ce qui accélère le démarrage.
• Dépendances et ordre. La description du service indique explicitement ce dont il a besoin (par exemple le réseau) et après quoi le lancer.
• Supervision. systemd connaît tous les processus d'un service grâce aux cgroups et peut le redémarrer après une panne.
• Journal unique. La sortie de tous les services est collectée par journald ; on consulte les journaux avec une seule commande.
• Interface unique. Chaque service se gère de la même façon : systemctl start|stop|restart|status.

En plus du gestionnaire de services, le projet systemd comprend plusieurs composants : journald (journalisation), logind (sessions des utilisateurs), timesyncd (synchronisation de l'heure), resolved (DNS), networkd (réseau). Toutes les distributions n'utilisent pas l'ensemble, mais systemd en tant que PID 1 et journald sont presque partout présents.

Unités : de quoi est constitué systemd

Tout ce que gère systemd est décrit par des unités (units). Une unité est un fichier texte au format INI ; son type se déduit de l'extension.

Où se trouvent les fichiers d'unités

Les fichiers d'unités sont rangés dans plusieurs répertoires, selon un ordre de priorité :

• /usr/lib/systemd/system/ (sous Debian et Ubuntu aussi /lib/systemd/system/) — unités installées par les paquets. On ne les modifie pas à la main : une mise à jour du paquet écraserait vos changements.
• /etc/systemd/system/ — unités et surcharges de l'administrateur. Elles ont la priorité la plus haute.
• /run/systemd/system/ — unités temporaires créées pendant le fonctionnement.

Pour voir le contenu effectif d'une unité avec toutes ses surcharges, utilisez systemctl cat nginx.service.

Des targets à la place des niveaux d'exécution

Les anciens runlevels ont été remplacés par les targets. multi-user.target est le mode serveur habituel, sans graphique ; graphical.target est le mode avec interface graphique ; rescue.target est le mode de récupération mono-utilisateur. La cible par défaut s'affiche avec systemctl get-default et se modifie avec systemctl set-default multi-user.target.

systemctl : gérer les services

systemctl est l'outil principal pour travailler avec systemd. La plupart des commandes modifient l'état du système et nécessitent sudo.

Lire systemctl status

$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-10-12 09:14:03 UTC; 2h 5min ago
       Docs: man:nginx(8)
   Main PID: 812 (nginx)
      Tasks: 3 (limit: 2307)
     Memory: 6.1M
        CPU: 154ms
     CGroup: /system.slice/nginx.service
             ├─812 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─813 "nginx: worker process"
             └─814 "nginx: worker process"

La ligne Loaded indique d'où provient le fichier d'unité et si le démarrage automatique est activé (enabled). La ligne Active donne l'état courant : active (running), inactive (dead) ou failed. Le bloc CGroup liste tous les processus du service — c'est ainsi que systemd sait ce qui lui appartient.

enable ou start

C'est une confusion fréquente. start lance le service immédiatement, mais après un redémarrage il ne revient pas tout seul. enable crée un lien symbolique dans le répertoire de la target (par exemple /etc/systemd/system/multi-user.target.wants/) : le service démarre alors au boot, mais il ne tourne pas encore. En général, il faut les deux — utilisez enable --now.

Il existe aussi un troisième état, mask. systemctl mask service relie l'unité à /dev/null, et elle ne peut plus être lancée ni manuellement ni comme dépendance. C'est utile lorsqu'un service doit être coupé de façon certaine.

journalctl : les journaux des services

Tout ce qu'un service écrit sur stdout et stderr est capturé par systemd-journald et conservé dans un journal binaire avec les métadonnées : nom de l'unité, PID, priorité, heure. On lit le journal avec la commande journalctl.

journalctl -u nginx              # journal d'un service
journalctl -u nginx -f           # suivre en temps réel, comme tail -f
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx -n 50        # les 50 dernières lignes
journalctl -b                    # depuis le démarrage courant
journalctl -b -1                 # le démarrage précédent
journalctl -p err -b             # uniquement les erreurs et plus graves
journalctl -k                    # messages du noyau
journalctl --disk-usage          # espace occupé par le journal

L'option -p filtre selon la priorité syslog : emerg, alert, crit, err, warning, notice, info, debug. Le niveau choisi inclut tout ce qui est plus grave que lui.

Le journal après un redémarrage

Si le répertoire /var/log/journal n'existe pas et que /etc/systemd/journald.conf contient Storage=auto, le journal n'est conservé qu'en mémoire (/run/log/journal) et disparaît au redémarrage. Pour le rendre permanent, réglez Storage=persistent ou créez le répertoire puis redémarrez journald. La taille est limitée par le paramètre SystemMaxUse=, et les anciennes entrées se suppriment avec journalctl --vacuum-time=2weeks ou --vacuum-size=500M.

journald fonctionne souvent avec rsyslog : le journal transmet les messages à rsyslog, qui écrit les fichiers texte classiques dans /var/log/ et peut envoyer les journaux vers un serveur centralisé.

Démarrage automatique de votre propre service : exemple de fichier d'unité

Supposons que vous ayez une application — un script ou un binaire — qui doit rester en marche, démarrer au boot et redémarrer en cas de panne. Créez le fichier /etc/systemd/system/myapp.service :

[Unit]
Description=Mon application web
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/opt/myapp/bin/server --port 8080
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Examinons les sections :

• [Unit] — description et dépendances. After= ne fixe que l'ordre, Wants= est une dépendance souple (l'unité est tirée au démarrage, mais l'échec de sa mise en route n'empêche pas le reste). Une dépendance stricte est Requires=.
• [Service] — comment le lancer. Type=simple signifie que le processus de ExecStart est le service lui-même et ne passe pas en arrière-plan. User= le lance sous un utilisateur sans privilèges. Restart=on-failure redémarre le service s'il s'est terminé en erreur, après RestartSec secondes.
• [Install] — ce que fait enable. WantedBy=multi-user.target signifie « démarrer lors d'un démarrage normal ».

Application :

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
sudo systemctl daemon-reload
sudo systemctl enable --now myapp
systemctl status myapp
journalctl -u myapp -f

Erreurs fréquentes dans les fichiers d'unités

• Chemin relatif dans ExecStart. Le chemin du programme doit être absolu. systemd ne cherche pas les commandes dans le PATH de l'utilisateur comme le fait un shell.
• Oubli de daemon-reload. Après une modification du fichier, systemd continue d'utiliser l'ancienne version et le signale dans status.
• Le démon passe en arrière-plan. Si le programme se duplique lui-même alors que Type=simple est indiqué, systemd considère que le service s'est arrêté. Soit le programme reste au premier plan, soit vous utilisez Type=forking avec PIDFile=.
• Variables d'environnement du profil. Le service ne voit ni ~/.bashrc ni /etc/profile. Les variables se définissent avec Environment= ou EnvironmentFile=.

Modifier sans toucher à l'unité du paquet

Pour changer les paramètres d'un service installé par un paquet sans modifier son fichier, utilisez un drop-in :

sudo systemctl edit nginx

Un éditeur s'ouvre et les modifications sont enregistrées dans /etc/systemd/system/nginx.service.d/override.conf. Vous pouvez par exemple y ajouter une section [Service] avec Restart=always. Une fois l'éditeur fermé, systemd relit la configuration tout seul.

Les timers systemd à la place de cron

Un timer est une unité qui lance selon un calendrier le service du même nom. Par rapport à cron, ses avantages sont les suivants : les journaux de la tâche sont dans le journal, les dépendances sont prises en charge, et les exécutions manquées peuvent être rattrapées (Persistent=true). Exemple — une sauvegarde quotidienne :

# /etc/systemd/system/backup.service
[Unit]
Description=Sauvegarde nocturne

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/backup.timer
[Unit]
Description=Lancer la sauvegarde chaque jour

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers

Vous pouvez vérifier une expression OnCalendar avec systemd-analyze calendar "*-*-* 03:00:00" : la commande indique quand aura lieu la prochaine exécution.

Diagnostic de la durée de démarrage

systemd conserve l'heure de démarrage de chaque unité, ce qui permet d'analyser facilement un démarrage lent :

systemd-analyze                  # durée totale du démarrage
systemd-analyze blame            # unités triées par durée de démarrage
systemd-analyze critical-chain   # la chaîne qui a retardé le démarrage
systemd-analyze verify /etc/systemd/system/myapp.service   # vérifier un fichier d'unité

Synthèse

systemd est le PID 1 et le gestionnaire de services de Linux moderne. Il décrit tout par des unités, se pilote avec systemctl, rassemble les journaux dans un journal que lit journalctl, et peut lancer des tâches avec des timers à la place de cron. Pour l'utiliser en confiance, maîtrisez status, enable --now, journalctl -u, et sachez écrire un fichier d'unité simple avec Restart=on-failure. systemd, journald et la journalisation sont traités en pratique dans notre cours sur Linux.