systemd

À quoi il sert

systemd est le premier processus lancé par le noyau (PID 1) sur Debian, Ubuntu, Red Hat, Fedora, Arch et la plupart des distributions actuelles. Il démarre les services dans l'ordre de leurs dépendances, place chacun dans son groupe de contrôle (cgroup) pour connaître et arrêter tous ses processus, les relance selon leur politique (Restart=), et recueille leurs sorties dans le journal (systemd-journald). On le pilote avec systemctl et on lit le journal avec journalctl. Il fournit aussi des minuteurs (.timer), qui remplacent de plus en plus cron, l'activation par socket, et de nombreuses options d'isolation des services.

Quand le choisir

Ce n'est guère un choix sur un serveur : c'est le gestionnaire de services de la distribution. Toute application qui doit tourner en permanence sur une machine Linux mérite son unité .service, plutôt qu'un nohup, un screen ou une ligne dans rc.local. Les alternatives existent sur d'autres systèmes (OpenRC sur Alpine et Gentoo, runit, s6), et les conteneurs délèguent ce rôle à leur moteur ou à Kubernetes.

Points d'attention

Les unités des paquets (/usr/lib/systemd/system/) ne se modifient pas : surchargez avec systemctl edit, qui écrit un drop-in dans /etc/systemd/system/<unité>.d/.
Après une modification manuelle d'un fichier d'unité : systemctl daemon-reload.
start ne rend pas un service persistant au redémarrage : enable (ou enable --now).
ExecStart= n'est pas une ligne de shell : chemin absolu, pas de && ni de |.
Les codes de sortie à partir de 200 (203/EXEC, 217/USER) sont émis par systemd avant le lancement du programme ; leur sens est dans systemd.exec(5).
systemd-analyze security <unité> mesure l'exposition d'un service ; la plupart des unités livrées par défaut peuvent être fortement durcies.

Par où commencer

La leçon Services et journaux du cours Linux : premiers pas, qui écrit l'unité de l'application Signalements et apprend à diagnostiquer un service qui ne démarre pas.