Pourquoi systemd n’est pas un simple « remplaçant » — c’est une refonte de la philosophie du démarrage

Aujourd’hui je serai un peu plus sérieux que d’habitude. Je vais vous parler de Systemd, un terme que vous avait déjà entendu mais connaissez-vous réellement cet outil de base. Avant systemd, les systèmes Linux reposaient majoritairement sur SysVinit, un système init minimaliste hérité des années 1980. Il fonctionnait séquentiellement : chaque processus devait terminer avant que le suivant ne démarre, ce qui rendait le démarrage lent, rigide et peu adaptable aux architectures modernes. SysVinit ne comprenait aucune notion native de dépendances, de supervision continue ou de gestion dynamique des ressources. Il lançait des scripts shell, sans garantie de leur bon déroulement ni capacité à les redémarrer en cas de panne. En somme, il traitait le système comme une liste d’ordres à exécuter — pas comme un ensemble de composants interconnectés travaillant ensembles.

systemd est entré en scène non pas pour ajouter une couche, mais pour réécrire la grammaire du démarrage et de la gestion des services. Il ne remplace pas seulement SysVinit : il supprime la distinction artificielle entre « init » et « gestionnaire de services », fusionnant supervision, journalisation, planification, montage de systèmes de fichiers, gestion des sockets, des bus D-Bus, et même du réseau. Ce n’est pas un daemon parmi d’autres — c’est le premier processus (PID 1), conçu dès l’origine pour modéliser les dépendances entre unités, orchestrer la parallélisation, et réagir en temps réel aux événements du noyau (via udev). Cela change radicalement la manière dont on conçoit la fiabilité, la traçabilité et la reproductibilité des systèmes.

Comment systemd structure la vie d’un service — au-delà du simple « start/stop »

Un service sous systemd n’est plus un script shell obscur lancé dans l’ombre. C’est une unité décrite dans un fichier texte structuré, généralement placé dans /usr/lib/systemd/system/ (pour les paquets) ou /etc/systemd/system/ (pour les configurations locales). Ce fichier — par exemple nginx.service — définit précisément ce qu’est le service : son type (simple, forking, notify), ses exigences (After=network.target, Wants=redis.service), ses limites (MemoryLimit=512M), et même sa politique de redémarrage (Restart=on-failure). Cette description déclare ce que le service doit faire, pas comment il doit être lancé. C’est une rupture avec SysVinit, où tout était implicite dans l’ordre d’exécution des scripts.

Chaque unité est chargée dans un arbre hiérarchique de dépendances, géré en mémoire par le daemon systemd lui-même. Lorsque tu lances systemctl start nginx, systemd ne cherche pas un script dans /etc/init.d/. Il analyse les relations déclarées (After, Requires, BindsTo), vérifie si les conditions sont remplies (ex. : le réseau est prêt), puis lance le processus en parallèle avec d’autres services compatibles. Si nginx échoue, systemd le relance selon la stratégie définie — ou déclenche une action en cascade (ex. : arrêter un service dépendant). Cette approche transforme la gestion des services d’une opération manuelle en une orchestration déclarative, fiable et auditable.

La ligne de commande : comprendre systemctl, pas juste la copier-coller

systemctl est l’interface principale, mais elle n’est pas un simple substitut à service ou chkconfig. Elle manipule un modèle cohérent d’unités, et chaque verbe a un sens technique précis. Par exemple, systemctl enable ne copie pas un script : il crée un lien symbolique vers le fichier unité dans le répertoire wants/ correspondant à un target (ex. : multi-user.target.wants/nginx.service). Ce target est l’équivalent moderne d’un « niveau d’exécution », mais dynamique : multi-user.target représente un état fonctionnel, pas un numéro statique. Tu peux même créer ton propre target personnalisé pour regrouper des services métier spécifiques.

De même, systemctl status ne montre pas seulement « active/inactive » : il affiche l’arbre des dépendances actives, les dernières lignes du journal (grâce à journald, intégré nativement), le PID, les limites mémoire/CPU appliquées, et l’état exact du processus principal. Ce n’est pas un diagnostic — c’est une autopsie en temps réel. Et contrairement à SysVinit, où service nginx status pouvait mentir (le script renvoyant 0 même si nginx avait crashé), systemd sait avec certitude si le processus est vivant, car il le surveille via le noyau (cgroups, signals, exit codes). Pour aller plus loin, systemctl list-dependencies --reverse nginx.service te montre qui dépend de nginx — une information cruciale lors d’une mise à jour ou d’un arrêt planifié.

Astuces concrètes pour maîtriser la parallélisation et les dépendances

La parallélisation n’est pas magique : elle repose sur une déclaration honnête des dépendances. Si ton service démarre trop tôt parce qu’il déclare After=network.target mais qu’il nécessite réellement une interface IP spécifique, alors After=network-online.target est plus adapté — car ce target attend que le réseau soit vraiment opérationnel, pas juste que les interfaces soient levées. Une erreur courante consiste à surcharger Wants= sans After= : cela déclenche le démarrage, mais sans ordre garanti. Préfère toujours After= pour l’ordre, Wants= pour la dépendance faible, et Requires= pour une dépendance forte (le service ne démarre pas si celui-ci échoue).

Autre astuce puissante : utilise les sockets activés. Au lieu de lancer un service au démarrage, crée une unité .socket qui écoute sur un port ou un chemin Unix. systemd lance automatiquement le service associé au premier paquet reçu. Cela économise des ressources, accélère le démarrage, et permet une gestion fine de la charge. Exemple concret : sshd.socket active sshd.service uniquement quand une connexion SSH arrive. Tu peux aussi désactiver un service tout en gardant son socket actif — idéal pour les services occasionnels. Enfin, systemctl show --property=ActiveState,SubState,UnitFileState nginx.service te donne un état machine-lisible, utile dans des scripts d’orchestration ou de surveillance.

Journalisation intelligente : pourquoi journalctl change tout

Avec SysVinit, les logs étaient éparpillés dans /var/log/ — un mélange de syslog, messages, daemon.log, souvent sans corrélation temporelle ni contexte processus. systemd intègre journald, un service de journalisation binaire, indexé, sécurisé et lié aux cgroups. Chaque message est enrichi avec l’UID, le PID, le nom de l’unité, le chemin binaire, et même le nom de la machine. Plus important : journalctl ne lit pas des fichiers — il interroge une base de données structurée. Tu peux filtrer par unité (-u nginx.service), par priorité (-p err), par plage horaire (--since "2 hours ago"), ou même par chaîne dans le message (-g "timeout").

Et surtout, journalctl résout le problème historique des logs perdus au redémarrage : par défaut, il stocke en mémoire volatile, mais tu peux configurer /etc/systemd/journald.conf pour persister les logs sur disque (Storage=persistent) — avec rotation automatique, compression et taille maximale. Tu peux aussi exporter au format JSON (--output=json) pour ingestion dans des outils comme ELK ou Grafana Loki. Ce n’est plus une simple archive : c’est un outil de débogage interactif. Par exemple, journalctl -u nginx.service -n 50 --no-pager | grep -i "failed" te donne les 50 dernières erreurs spécifiques à nginx, sans avoir à ouvrir un éditeur ou parser manuellement des fichiers.

Bidouiller sans crainte : comment modifier, tester et valider ses propres unités

Tu n’es pas condamné à utiliser les fichiers fournis par les paquets. systemd encourage la personnalisation locale via /etc/systemd/system/. Si tu veux modifier nginx.service, ne touche jamais à /usr/lib/systemd/system/nginx.service — crée plutôt /etc/systemd/system/nginx.service.d/override.conf avec la section [Service] et les paramètres à surcharger (ex. : Environment="NGINX_OPTS=-c /etc/nginx/custom.conf"). Cette méthode est sûre, réversible, et persiste lors des mises à jour du paquet. Pour tester une nouvelle unité, utilise systemd-analyze verify mon-service.service : il détecte les erreurs syntaxiques, les dépendances circulaires ou les chemins invalides avant tout lancement.

Une fois ton fichier prêt, recharge la configuration avec systemctl daemon-reload — cette commande force systemd à relire tous les fichiers d’unité, y compris ceux modifiés. Puis lance-le en mode debug avec systemctl start --no-block --wait mon-service.service : le --wait bloque le terminal jusqu’à ce que le service atteigne l’état « active », et --no-block évite que systemctl ne se fige si le service fork. Enfin, valide le comportement avec systemctl is-active mon-service.service && echo "OK" || echo "Échec". Cette chaîne de commandes est reproductible, scriptable, et exploitable dans des pipelines CI/CD — une preuve que la gestion des services peut être aussi rigoureuse que le code lui-même.

systemd n’est pas un monolithe — c’est un écosystème modulaire, extensible et libre

Il est tentant de voir systemd comme un « tout-en-un » opaque, mais sa conception est profondément modulaire. Le daemon principal (systemd) ne fait que coordonner ; chaque fonction est assurée par un binaire dédié (systemd-journald, systemd-networkd, systemd-resolved, systemd-logind) — tous interchangeables. Tu peux désactiver systemd-resolved et utiliser dnsmasq ou unbound à la place. Tu peux remplacer systemd-networkd par NetworkManager ou même un script personnalisé — tant qu’il respecte les conventions d’activation par unité. Rien n’est verrouillé. La licence est LGPLv2.1+, et le code source est entièrement ouvert sur GitHub.

Ce qui distingue systemd des alternatives propriétaires, c’est sa capacité à collaborer, pas à imposer. Il expose des interfaces standardisées (D-Bus, cgroups v2, /run/systemd/), permettant à des outils tiers — comme podman, flatpak, ou des gestionnaires de conteneurs — de s’intégrer nativement sans patchs. Même la communauté SysVinit a bénéficié de cette transparence : des projets comme runit ou openrc ont adopté des concepts similaires (gestion déclarative, supervision continue), prouvant que l’idée a dépassé son implémentation. En fin de compte, systemd ne t’oblige pas à tout adopter. Tu peux l’utiliser uniquement comme système init moderne, avec systemctl pour les services et journalctl pour les logs — et ignorer le reste. J’espère que vous avez appris deux trois choses, et pour finir une blague de geek quand même :

Pourquoi Lennart Poettering commande-t-il toujours un café, une pizza et un billet de train en même temps ?

Parce qu’il refuse de séparer les services et préfère tout gérer sous un seul binaire : systemd-restaurantd.

Oui, j’aurais dû aussi vous dire que systemd a été créé par Lennart Poettering… Encore raté.