Systemd : gérer services, unités et journal sous Linux

Systemd est le gestionnaire de système et de services adopté par la majorité des distributions Linux modernes. Il occupe la position de premier processus lancé par le noyau (le processus d’identifiant 1), et orchestre le démarrage de la machine, la supervision des services, la gestion des dépendances et l’accès centralisé aux journaux. Sa logique repose sur des unités déclaratives plutôt que sur des scripts séquentiels, ce qui rend l’état du système lisible et reproductible.

→ Lire l’explication complète de la marmotte

Le rôle de Systemd comme processus d’initialisation

Au démarrage, le noyau Linux monte le système de fichiers racine puis exécute Systemd, qui devient le parent de tous les autres processus. Systemd lit ensuite un ensemble d’unités et active celles rattachées à la cible de démarrage par défaut. Contrairement aux anciens systèmes d’initialisation séquentiels, Systemd démarre les services en parallèle lorsqu’aucune dépendance ne l’interdit, ce qui réduit le temps de mise en service.

La configuration s’appuie sur des fichiers texte au format INI, répartis entre plusieurs répertoires. Les unités fournies par les paquets résident dans /usr/lib/systemd/system/, tandis que les personnalisations locales sont placées dans /etc/systemd/system/, qui prime sur les précédentes.

Les types d’unités Systemd

Une unité est une ressource gérée par Systemd, identifiée par un nom et un suffixe décrivant sa nature. Les types les plus courants sont les suivants :

.service : un démon ou un programme géré comme un service (par exemple nginx.service).
.socket : un point d’écoute réseau ou local, qui peut activer un service à la demande.
.timer : un déclencheur temporel, alternative moderne à cron.
.target : un regroupement d’unités servant de point de synchronisation (par exemple multi-user.target).
.mount et .automount : des points de montage de systèmes de fichiers.
.path : une surveillance de fichier ou de répertoire déclenchant une action.

Cette typologie permet de représenter l’ensemble des ressources d’un système sous une forme homogène et interrogeable.

Anatomie d’une unité de service

Un fichier .service se structure en sections. La section [Unit] décrit les métadonnées et les dépendances, [Service] définit l’exécution proprement dite, et [Install] indique comment l’unité s’active. L’exemple ci-dessous décrit un service applicatif minimal :

[Unit]
Description=API de facturation TortueTech
After=network-online.target postgresql.service
Wants=network-online.target

[Service]
Type=simple
User=facturation
WorkingDirectory=/opt/facturation
ExecStart=/opt/facturation/bin/serveur --port 8080
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

La directive After impose un ordre de démarrage sans créer de dépendance forte, tandis que Wants exprime une dépendance souhaitée mais non bloquante. La directive Restart=on-failure demande à Systemd de relancer le processus après une sortie en erreur, ce qui contribue à la résilience du service.

Le guide Décrire un service systemd détaille pas à pas la rédaction et le déploiement d’une telle unité.

Gérer les services au quotidien avec systemctl

L’outil en ligne de commande systemctl constitue l’interface principale d’administration. Les opérations courantes suivent une syntaxe uniforme :

# Activer au démarrage et lancer immédiatement
sudo systemctl enable --now facturation.service

# Consulter l'état détaillé
systemctl status facturation.service

# Recharger la configuration après modification d'une unité
sudo systemctl daemon-reload

# Redémarrer sans coupure de configuration
sudo systemctl restart facturation.service

La distinction entre enable et start est essentielle : enable inscrit l’unité pour un démarrage automatique via les liens symboliques de la cible, alors que start lance uniquement l’instance courante. La commande combinée enable --now réalise les deux actions.

Les cibles et la synchronisation du démarrage

Les cibles (.target) remplacent les niveaux d’exécution des anciens systèmes. La cible multi-user.target correspond à un système opérationnel sans interface graphique, tandis que graphical.target ajoute le serveur d’affichage. La cible par défaut se consulte et se modifie ainsi :

systemctl get-default
sudo systemctl set-default multi-user.target

La cible network-online.target sert de point de rendez-vous pour les services nécessitant une connectivité réseau établie, ce qui explique son usage fréquent dans les directives After et Wants.

Journal centralisé avec journald

Systemd intègre un service de journalisation, journald, qui collecte les sorties standard et les messages des unités dans un journal structuré et indexé. L’outil journalctl permet des recherches filtrées :

# Journaux d'une unité, en suivi temps réel
journalctl -u facturation.service -f

# Journaux depuis le dernier démarrage
journalctl -b

# Filtrer sur une plage temporelle
journalctl --since "2024-01-01" --until "2024-01-02"

Par défaut, le journal peut être volatil (perdu au redémarrage) ou persistant selon la configuration de Storage dans /etc/systemd/journal.conf. Un stockage persistant nécessite l’existence du répertoire /var/log/journal/.

Isolation et durcissement des services

Systemd offre des directives de confinement qui limitent la surface d’exposition d’un service sans conteneur dédié. Parmi les plus utilisées :

NoNewPrivileges=true : interdit l’acquisition de nouveaux privilèges par le processus.
ProtectSystem=strict : rend l’arborescence système en lecture seule.
ProtectHome=true : masque les répertoires personnels.
PrivateTmp=true : attribue un répertoire temporaire isolé.
CapabilityBoundingSet= : restreint les capacités du noyau accordées.

Ces mécanismes s’inscrivent dans une démarche de simplicité opérationnelle et de réduction des risques, en appliquant le principe de moindre privilège au niveau de chaque service.

Minuteries Systemd comme alternative à cron

Une unité .timer associée à un service permet de planifier des exécutions périodiques avec une granularité fine et un journal unifié. La correspondance repose sur un nom partagé : sauvegarde.timer déclenche sauvegarde.service.

[Unit]
Description=Sauvegarde quotidienne

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

La directive Persistent=true demande le rattrapage d’une exécution manquée si la machine était éteinte à l’heure prévue, comportement absent de cron. Ce mécanisme s’articule utilement avec une stratégie de sauvegardes.

Points de vigilance

Plusieurs erreurs récurrentes méritent attention. L’oubli de systemctl daemon-reload après modification d’un fichier d’unité conduit Systemd à conserver l’ancienne définition en mémoire. Le choix du Type= doit correspondre au comportement réel du programme : Type=simple convient à un processus qui reste au premier plan, tandis que Type=forking s’applique à un démon qui se détache. Une politique de redémarrage trop agressive peut masquer un défaut applicatif ; la directive StartLimitBurst limite le nombre de relances dans un intervalle donné pour éviter les boucles.

Systemd s’intègre dans une compréhension plus large des fondations Linux et prolonge les principes exposés dans les fondations d’architecture.

FAQ

Quelle différence entre enable et start pour une unité ?

La commande start lance l’unité pour la session en cours uniquement, sans effet sur les démarrages suivants. La commande enable crée les liens symboliques nécessaires pour que l’unité s’active automatiquement au démarrage, mais ne la lance pas immédiatement. La forme enable --now combine les deux comportements.

Pourquoi utiliser un timer Systemd plutôt que cron ?

Un timer bénéficie de la journalisation centralisée de journald, du rattrapage des exécutions manquées via Persistent=true, et des mêmes mécanismes de dépendances et d’isolation que les services. Il partage ainsi l’outillage d’administration de Systemd, ce qui homogénéise la supervision.

Comment inspecter les dépendances d’une unité ?

La commande systemctl list-dependencies nom.service affiche l’arbre des unités requises et souhaitées. Elle aide à comprendre l’ordre de démarrage et à diagnostiquer un service bloqué en attente d’une dépendance non satisfaite.

Où placer une unité personnalisée ?

Les unités locales se placent dans /etc/systemd/system/, répertoire qui prend le dessus sur les définitions fournies par les paquets dans /usr/lib/systemd/system/. Pour surcharger partiellement une unité existante sans la remplacer, la commande systemctl edit nom.service crée un fichier de dérogation dans un sous-répertoire dédié.

🐝 Ce qui arrive si on s’en passe

Sans directives de confinement, un service compromis hérite de tout ce que son compte peut atteindre : écriture dans l’arborescence système, lecture des répertoires personnels, répertoire temporaire partagé avec les autres processus, et possibilité d’acquérir de nouveaux privilèges par un programme intermédiaire. Sans journal persistant, un redémarrage efface précisément les traces qui auraient permis de dater l’intrusion ; l’enquête commence alors avec un journal vierge et une machine très propre. Une politique de relance sans limite ajoute sa touche : un service qui plante en boucle sous l’effet d’une entrée malveillante redémarre sans fin, et le symptôme reste invisible tant que personne ne compte les relances.

🦫 Explication de la marmotte 🍫

Quand l’ordinateur démarre, le noyau, c’est-à-dire le cœur du système, prépare le disque principal puis lance un premier programme : Systemd. Tous les autres programmes seront ensuite lancés par lui. Systemd lit des fichiers texte appelés unités, et chaque unité décrit une chose à gérer : un service qui tourne en permanence, un point d’écoute qui réveille un service quand une connexion arrive, une minuterie qui déclenche une tâche à heure fixe, un disque à rattacher, ou une cible, qui regroupe plusieurs unités à atteindre ensemble. Pour un service, le fichier indique quel programme lancer, sous quel utilisateur, après quelles autres unités, et quoi faire s’il s’arrête en erreur, par exemple le relancer après cinq secondes. Systemd démarre en même temps tout ce qui ne dépend de rien, puis le reste dans l’ordre imposé. Si un fichier est modifié sans demander à Systemd de le relire, l’ancienne version reste appliquée. L’administrateur pilote l’ensemble avec la commande systemctl : lancer maintenant, inscrire au démarrage, consulter l’état. Les messages de chaque service sont rassemblés dans un journal unique, que la commande journalctl permet de filtrer ; ce journal disparaît au redémarrage sauf si un stockage permanent est configuré. Enfin, des options interdisent à un service de gagner des droits, de modifier les fichiers du système ou de lire les dossiers personnels, ce qui limite les dégâts s’il est piraté.

Pages voisines

La citent

Systemd : gérer services, unités et journal sous Linux

Elle cite

Systemd : gérer services, unités et journal sous Linux

Systemd : gérer services, unités et journal sous Linux

Le rôle de Systemd comme processus d’initialisation

Les types d’unités Systemd

Anatomie d’une unité de service

Gérer les services au quotidien avec systemctl

Les cibles et la synchronisation du démarrage

Journal centralisé avec journald

Isolation et durcissement des services

Minuteries Systemd comme alternative à cron

Points de vigilance

FAQ

Quelle différence entre enable et start pour une unité ?

Pourquoi utiliser un timer Systemd plutôt que cron ?

Comment inspecter les dépendances d’une unité ?

Où placer une unité personnalisée ?

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines