systemctl : lister, démarrer et diagnostiquer les services Linux

systemctl est la commande centrale pour gérer les services sous Linux. Elle liste, démarre, arrête, recharge et diagnostique tout ce que systemd pilote sur un serveur moderne. Cette page couvre le cycle de vie d'un service, les deux façons de lister les services (celle qui manque à la plupart des lecteurs), la création d'une unité et le diagnostic de base d'un service qui refuse de tourner. Public visé : débutant qui découvre systemctl et administrateur qui veut arrêter de se faire piéger par un start trop optimiste.

Toutes les sorties reproduites ici proviennent d'un serveur Debian 13 avec systemd 257 et nginx installé. Les commandes sont identiques sur Ubuntu, Debian et RHEL ; seules quelques sorties d'enable diffèrent, et c'est signalé.

Ce que vous allez apprendre

• Lister les services avec list-units et list-unit-files, et comprendre pourquoi les deux listes ne se ressemblent pas
• Piloter le cycle de vie : start, stop, restart, reload, status
• Lire un statut ligne par ligne et interroger un service avec is-active, is-enabled, is-failed
• Créer une unité de service personnalisée sans tomber dans le piège de Type=simple
• Diagnostiquer un échec avec journalctl et le code 203/EXEC

LFCS / RHCSA

La gestion des services avec systemctl est un objectif majeur des deux certifications. Vous devez savoir lister, démarrer, arrêter, activer un service, lire son statut et diagnostiquer un échec sans documentation.

Les cinq commandes du quotidien

Quatre-vingt-dix pour cent du travail sur les services tient dans cinq verbes. Chacun agit immédiatement, sur le système tel qu'il tourne en ce moment, et aucun ne survit à un redémarrage de la machine : l'activation au boot est une notion séparée. Toutes ces commandes modifient l'état du système, elles demandent donc les privilèges root via sudo, sauf status qui se contente de lire.

sudo systemctl start nginx      # démarrer maintenant
sudo systemctl stop nginx       # arrêter maintenant
sudo systemctl restart nginx    # arrêter puis redémarrer
sudo systemctl reload nginx     # relire la configuration sans couper
systemctl status nginx          # où en est-on ?

La bonne habitude consiste à enchaîner l'action et sa vérification dans la même ligne de commande. Le shell n'exécute la seconde partie que si la première a réussi, et is-active répond en un mot :

systemctl start nginx && systemctl is-active nginx

active

Le suffixe .service est facultatif : systemctl start nginx et systemctl start nginx.service sont strictement équivalents. Il devient obligatoire dès qu'un timer ou un socket porte le même nom que le service, ce qui arrive souvent.

Recharger sans couper le trafic

reload demande au service de relire sa configuration pendant qu'il continue de servir les requêtes en cours. restart tue le processus puis en lance un nouveau : les connexions en cours tombent. Sur un serveur web en production, la différence se voit dans les logs des clients.

systemctl reload nginx && systemctl is-active nginx

active

reload n'existe pas partout

Un service ne supporte reload que si son unité déclare une directive ExecReload=. Nginx, Apache et PostgreSQL la déclarent. Si le service ne la fournit pas, systemctl reload renvoie une erreur et il faut se rabattre sur restart. La commande systemctl cat nginx affiche l'unité complète et permet de vérifier la présence d'ExecReload= avant de se lancer.

Lire un statut ligne par ligne

systemctl status est la fiche d'identité d'un service : d'où vient son fichier de configuration, s'il tourne, depuis quand, avec quel PID, et les dernières lignes de son journal. C'est le premier réflexe devant un service suspect.

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 Sun 2026-07-12 16:54:11 UTC; 31s ago
 Invocation: 78240b0f696a4bc29a331a580ba0cdd5
       Docs: man:nginx(8)
    Process: 76 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 80 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
   Main PID: 81 (nginx)
      Tasks: 17 (limit: 8616)
     Memory: 10.9M (peak: 11.7M)
        CPU: 29ms
     CGroup: /system.slice/nginx.service
             ├─81 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─82 "nginx: worker process"
             ├─83 "nginx: worker process"
             (... un processus worker par cœur, 17 tâches au total ...)

Jul 12 16:54:11 srv01 systemd[1]: Starting nginx.service - A high performance web server and a reverse proxy server...
Jul 12 16:54:11 srv01 systemd[1]: Started nginx.service - A high performance web server and a reverse proxy server.

Chaque ligne répond à une question précise, et les trois premières suffisent le plus souvent :

Ligne	Ce qu'elle vous dit
Loaded	Chemin du fichier unité utilisé, et si le service est activé au boot (enabled / disabled / masked)
Active	État courant et durée : active (running), inactive (dead), failed
Process	Les commandes déjà terminées et leur code de sortie (status=0/SUCCESS ou une erreur)
Main PID	Le PID du processus principal ; s'il est absent, rien ne tourne
CGroup	L'arborescence réelle des processus rattachés au service

Glissez pour voir

La ligne Loaded est celle qu'on oublie de lire. Elle indique le chemin exact du fichier unité chargé, ce qui évite de passer dix minutes à éditer un fichier que systemd n'utilise pas.

Les réponses en un mot

Dans un script, un status complet est inexploitable : il faut une réponse courte et un code de retour fiable. Trois commandes le font, et elles s'utilisent aussi bien à la main que dans une automatisation Ansible ou un script de déploiement.

systemctl is-active nginx     # active | inactive | failed | activating
systemctl is-enabled nginx    # enabled | disabled | static | masked
systemctl is-failed demo      # failed si l'unité est en échec

Après avoir remis à zéro un service en échec avec reset-failed, is-failed répond par l'état courant :

systemctl reset-failed demo && systemctl is-failed demo

inactive

Lister les services : list-units ou list-unit-files ?

C'est la question la plus posée sur systemctl, et la réponse est piégeuse : il existe deux listes de services, elles ne contiennent pas les mêmes choses, et la commande qu'on trouve partout (systemctl list-units) est justement celle qui cache une partie des services de la machine.

La distinction tient en une phrase : list-units liste les unités chargées en mémoire par systemd ; list-unit-files liste les fichiers d'unité installés sur le disque. Un service installé par un paquet mais jamais démarré existe bien sur le disque, mais systemd ne l'a pas chargé, donc il n'apparaît pas dans list-units. Sur le serveur de démonstration, l'écart est spectaculaire : 14 services chargés contre 119 fichiers d'unité installés.

Les services chargés en mémoire

systemctl list-units --type=service répond à la question « qu'est-ce que systemd manipule en ce moment ? ». C'est la vue runtime, celle qu'on veut quand on inspecte un serveur vivant.

systemctl list-units --type=service

  UNIT                                     LOAD   ACTIVE SUB     DESCRIPTION
  ldconfig.service                         loaded active exited  Rebuild Dynamic Linker Cache
  nginx.service                            loaded active running A high performance web server and a reverse proxy server
  systemd-journal-catalog-update.service   loaded active exited  Rebuild Journal Catalog
  systemd-journal-flush.service            loaded active exited  Flush Journal to Persistent Storage
  systemd-journald.service                 loaded active running Journal Service
● systemd-modules-load.service             loaded failed failed  Load Kernel Modules
  systemd-remount-fs.service               loaded active exited  Remount Root and Kernel File Systems
  systemd-sysctl.service                   loaded active exited  Apply Kernel Variables
  systemd-sysusers.service                 loaded active exited  Create System Users
  systemd-tmpfiles-setup-dev-early.service loaded active exited  Create Static Device Nodes in /dev gracefully
  systemd-tmpfiles-setup-dev.service       loaded active exited  Create Static Device Nodes in /dev
  systemd-tmpfiles-setup.service           loaded active exited  Create System Files and Directories
  systemd-update-done.service              loaded active exited  Update is Completed
  systemd-user-sessions.service            loaded active exited  Permit User Sessions

14 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

Trois colonnes portent l'information utile. LOAD dit si le fichier unité a été lu correctement, ACTIVE donne l'état général et SUB le détail : un service active (exited) a terminé sa tâche avec succès et ne laisse aucun processus derrière lui, ce qui est normal pour les tâches de démarrage. Le point noir en début de ligne signale les unités qui demandent votre attention, ici systemd-modules-load.service en failed.

Les deux dernières lignes de la sortie sont un mode d'emploi que systemd vous donne gratuitement : --all pour voir aussi les unités chargées mais inactives, list-unit-files pour voir tout ce qui est installé.

Les services installés sur le disque

systemctl list-unit-files --type=service répond à la question « qu'est-ce qui est installé sur cette machine, et est-ce que ça démarrera au boot ? ». C'est la vue disque, celle qu'on veut pour un audit ou pour trouver un service qu'on n'a jamais démarré.

systemctl list-unit-files --type=service

UNIT FILE                                    STATE           PRESET
apt-daily-upgrade.service                    static          -
apt-daily.service                            static          -
autovt@.service                              alias           -
console-getty.service                        masked          disabled
debug-shell.service                          disabled        disabled
getty@.service                               enabled         enabled
nginx.service                                enabled         enabled
systemd-networkd.service                     disabled        enabled
systemd-pstore.service                       enabled         enabled
systemd-remount-fs.service                   enabled-runtime enabled
systemd-udevd.service                        masked          enabled
x11-common.service                           masked          enabled

119 unit files listed.

La sortie complète compte 119 lignes ; l'extrait ci-dessus montre un exemplaire de chaque état rencontré. La colonne STATE est le cœur de l'affaire : elle dit ce que systemd fera de ce service au prochain démarrage. La colonne PRESET indique ce que la distribution recommandait par défaut, ce qui permet de repérer d'un coup d'œil les services dont l'état a été modifié à la main.

STATE	Ce que ça signifie
enabled	Démarrera au boot : un lien symbolique existe dans un répertoire .wants
disabled	Ne démarrera pas au boot, mais reste démarrable à la main
static	Aucune section [Install] : ne peut pas être activé, il est tiré par une dépendance
masked	Lié vers /dev/null : impossible à démarrer, même manuellement
alias	Autre nom d'un service existant (kmod.service pointe vers un autre service)
enabled-runtime	Activé jusqu'au prochain reboot seulement, l'activation est en /run et non en /etc
indirect	Activable, mais l'activation réelle passe par un autre service du même groupe
generated	Fabriqué à la volée par un générateur, typiquement à partir d'un vieux script SysV

Glissez pour voir

L'état static est celui qui surprend le plus. Un systemctl enable systemd-tmpfiles-clean.service échouera, non pas à cause d'une erreur de votre part, mais parce que ce service n'a pas vocation à être activé : il est déclenché par d'autres unités. La commande le confirme en un mot.

systemctl is-enabled systemd-tmpfiles-clean.service

static

Les listings qui servent vraiment

Lister les 119 unités d'un serveur n'a aucun intérêt opérationnel. Ce qu'on veut, c'est filtrer : quels services tournent, lesquels sont tombés, lesquels démarreront au prochain boot. Le filtre --state= s'applique aux deux commandes, avec des valeurs différentes puisqu'elles ne parlent pas de la même chose.

Les services qui tournent vraiment, processus vivant à l'appui :

systemctl list-units --type=service --state=running

  UNIT                     LOAD   ACTIVE SUB     DESCRIPTION
  nginx.service            loaded active running A high performance web server and a reverse proxy server
  systemd-journald.service loaded active running Journal Service

2 loaded units listed.

Les services qui démarreront au prochain boot, la commande à connaître pour un audit de serveur :

systemctl list-unit-files --type=service --state=enabled

UNIT FILE              STATE   PRESET
getty@.service         enabled enabled
nginx.service          enabled enabled
systemd-pstore.service enabled enabled

3 unit files listed.

Les services en échec, le premier réflexe quand on prend la main sur une machine dont on ne sait rien :

systemctl list-units --state=failed

  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
● demo.service                 loaded failed failed Demo qui echoue
● systemd-modules-load.service loaded failed failed Load Kernel Modules

2 loaded units listed.

Deux options complètent la panoplie. --all ajoute les unités chargées mais inactives, ce qui fait passer la liste de 14 à 65 entrées sur la machine de démonstration : c'est là que réapparaissent les services arrêtés. --no-legend supprime l'en-tête et la légende, ce qui rend la sortie exploitable dans un script.

systemctl list-units --type=service --no-legend | wc -l

14

Le tableau qui évite l'erreur

Retenez la question que chaque commande pose vraiment. C'est le seul moyen de ne plus hésiter devant un serveur inconnu.

Vous voulez savoir	Commande	Attention
Ce qui tourne en ce moment	systemctl list-units --type=service --state=running	Ne montre pas les services installés mais jamais lancés
Tout ce que systemd a chargé	systemctl list-units --type=service	Ajoutez --all pour inclure les unités inactives
Ce qui est installé sur la machine	systemctl list-unit-files --type=service	La liste la plus longue, c'est la vue disque
Ce qui démarrera au prochain boot	systemctl list-unit-files --type=service --state=enabled	La bonne commande pour un audit
Ce qui est tombé	systemctl list-units --state=failed	Le premier réflexe de diagnostic
Trouver un service par son nom	systemctl list-unit-files | grep docker	Cherchez dans les unit files, pas dans les units chargées

Glissez pour voir

Les états d'un service

Un service traverse plusieurs états au cours de sa vie, et systemctl status les affiche sur la ligne Active. Les connaître évite les faux diagnostics : un service active (exited) n'est pas cassé, il a simplement fini son travail.

État	Signification
active (running)	Le service tourne, un processus est vivant
active (exited)	La tâche s'est terminée avec succès, aucun processus ne subsiste (Type=oneshot)
inactive (dead)	Le service est arrêté, sans erreur
failed	Le service a échoué, le journal contient la raison
activating	Le démarrage est en cours
deactivating	L'arrêt est en cours
masked	Le service est bloqué, un start refusera de faire quoi que ce soit

Glissez pour voir

enabled n'est pas active

C'est la confusion de départ de tout débutant, et elle produit des serveurs qui tournent parfaitement jusqu'au premier redémarrage. Les deux notions sont indépendantes : l'une parle du présent, l'autre du prochain boot.

Concept	Question posée	Commande
active	Le service tourne-t-il en ce moment ?	systemctl is-active nginx
enabled	Démarrera-t-il tout seul au prochain boot ?	systemctl is-enabled nginx

Glissez pour voir

Un service peut être enabled et inactive : il est arrêté maintenant, il repartira au reboot. Il peut être active et disabled : il tourne, mais il ne survivra pas au redémarrage. Ce dernier cas est le scénario classique du service installé un vendredi soir et disparu le lundi matin.

Activer un service au démarrage

Deux commandes suffisent au quotidien. enable crée le lien symbolique qui fera démarrer le service au boot, enable --now fait les deux d'un coup, et disable retire le lien.

sudo systemctl enable nginx          # au prochain boot
sudo systemctl enable --now nginx    # au prochain boot ET maintenant
sudo systemctl disable nginx         # ne démarrera plus au boot
systemctl is-enabled nginx           # vérification

La sortie d'enable dépend de la distribution, et c'est déroutant la première fois. Sur RHEL, systemd affiche le lien symbolique créé. Sur Debian et Ubuntu, un paquet qui embarque encore un script SysV (c'est le cas de nginx) déclenche d'abord une synchronisation, et le message parle de SysV sans mentionner le moindre lien :

Synchronizing state of nginx.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable nginx

Le disable, lui, montre bien la suppression du lien, ce qui confirme la mécanique sous-jacente :

Removed '/etc/systemd/system/multi-user.target.wants/nginx.service'.

Dans tous les cas, la seule vérification qui compte est systemctl is-enabled nginx, qui doit répondre enabled. Ne vous fiez pas au message affiché, fiez-vous à l'état.

L'activation au boot en détail

Les targets, les directives WantedBy=, les presets de distribution, les états static et indirect et le test de persistance après un vrai reboot sont traités dans le guide dédié Activer un service au démarrage.

Masquer un service pour de bon

disable empêche le démarrage automatique, mais laisse la porte ouverte à un systemctl start manuel, y compris déclenché par une dépendance d'un autre service. mask ferme la porte : systemd crée un lien vers /dev/null, et plus rien ne peut lancer le service.

sudo systemctl mask nginx

Created symlink '/etc/systemd/system/nginx.service' → '/dev/null'.

Toute tentative de démarrage échoue alors avec un message sans ambiguïté, et c'est exactement le comportement recherché pour un service qui ne doit jamais tourner sur un serveur, comme Bluetooth, Avahi ou CUPS :

Failed to start nginx.service: Unit nginx.service is masked.

Le retour en arrière se fait avec sudo systemctl unmask nginx, qui supprime le lien vers /dev/null et rend le service démarrable. Un systemctl is-enabled nginx confirme la sortie de l'état masked.

Créer une unité de service

Faire tourner une application métier comme un service systemd apporte trois choses qu'un nohup ne donnera jamais : le redémarrage automatique en cas de crash, le démarrage au boot et les logs centralisés dans le journal. Le fichier d'unité vit dans /etc/systemd/system/ (le répertoire réservé à l'administrateur, prioritaire sur les unités livrées par les paquets).

Un fichier d'unité se lit en trois blocs, et chacun répond à une question différente : [Unit] décrit le service et ses dépendances, [Service] dit comment lancer le processus, [Install] dit quand l'activer au boot. Retenez le piège signalé en bas du schéma : sans section [Install], le service est static et systemctl enable n'aura aucun effet.

1. Créer le fichier d'unité avec l'éditeur intégré, qui gère le chemin et les droits pour vous :

   sudo systemctl edit --full --force mon-app.service

2. Décrire le service, en nommant explicitement l'utilisateur non privilégié qui l'exécutera :

   [Unit]
   Description=API de facturation interne
   After=network-online.target postgresql.service
   Wants=network-online.target
   
   [Service]
   Type=exec
   User=appuser
   Group=appuser
   WorkingDirectory=/opt/mon-app
   ExecStart=/opt/mon-app/bin/api --config /etc/mon-app/api.toml
   ExecReload=/bin/kill -HUP $MAINPID
   Restart=on-failure
   RestartSec=5s
   NoNewPrivileges=true
   
   [Install]
   WantedBy=multi-user.target

3. Recharger systemd pour qu'il relise le fichier, puis démarrer :

   sudo systemctl daemon-reload
   sudo systemctl enable --now mon-app.service

4. Vérifier réellement que le service tient debout, en laissant passer quelques secondes :

   sleep 3 && systemctl is-active mon-app.service

   La sortie doit afficher active. Si elle affiche failed, journalctl -xeu mon-app.service donne la raison.

Oublier daemon-reload après avoir modifié un fichier d'unité est l'erreur la plus fréquente : systemd continue d'utiliser la version qu'il a en mémoire, et vos changements semblent sans effet.

Les trois sections

Un fichier d'unité se lit toujours de la même façon, ce qui rend n'importe quelle unité inconnue déchiffrable en trente secondes.

Section	Rôle
[Unit]	Description, dépendances (After=, Wants=, Requires=), ordre de démarrage
[Service]	Le type, la commande, l'utilisateur, la politique de redémarrage
[Install]	Ce qui se passe à l'enable : la cible qui tirera ce service au boot

Glissez pour voir

Une unité sans section [Install] est justement une unité static : elle ne peut pas être activée, seulement tirée par une dépendance.

Choisir le bon Type

La directive Type= dit à systemd comment savoir que le service est démarré. C'est le réglage le plus mal compris de tout systemd, et le mauvais choix produit des diagnostics faux.

Type	Comportement	Quand l'utiliser
simple	Le processus lancé par ExecStart est le service ; systemd le considère démarré dès le fork	Le défaut historique, à éviter au profit de exec
exec	Comme simple, mais systemd attend que l'exec() réussisse	Le bon défaut pour un binaire au premier plan (systemd 240 et plus)
forking	Le processus se détache, systemd suit le processus fils	Daemons traditionnels avec un PIDFile=
oneshot	Exécute une commande puis se termine	Scripts de maintenance, tâches ponctuelles
notify	Le service prévient systemd qu'il est prêt via sd_notify()	Applications compatibles, idéal pour l'ordre de démarrage
idle	Attend que les autres jobs soient finis	Cas rares, affichage console

Glissez pour voir

Le piège : Type=simple ne vérifie pas que votre binaire existe

Voici le comportement que presque personne n'explique, et qui coûte des heures de débogage. Avec Type=simple, systemd considère le service démarré dès qu'il a forké, donc avant même d'avoir tenté d'exécuter le binaire. Résultat : systemctl start rend la main avec un code de retour 0, is-active répond active, et le service est déjà mort.

Deux unités identiques, un seul détail qui change, et deux comportements opposés. La première déclare Type=simple, la seconde Type=exec, et toutes deux pointent vers un binaire qui n'existe pas :

[Service]
Type=simple
ExecStart=/opt/demo/absent

systemctl start t-simple; echo "code retour de start = $?"; systemctl is-active t-simple

code retour de start = 0
active

Le démarrage est un succès pour le shell, et le service se déclare actif. Avec Type=exec, systemd attend le résultat de l'exec() et refuse de mentir :

systemctl start t-exec; echo "code retour de start = $?"; systemctl is-active t-exec

Job for t-exec.service failed because the control process exited with error code.
See "systemctl status t-exec.service" and "journalctl -xeu t-exec.service" for details.
code retour de start = 1
failed

La conséquence est très concrète. Un script de déploiement qui teste $? après un systemctl start se croit en succès alors que l'application est morte, et le pipeline passe au vert. Un systemctl status lancé une seconde trop tôt affiche un active (running) parfaitement mensonger, avec un Main PID entre doubles parenthèses qui trahit un processus qui n'a jamais réussi son exec() :

● demo.service - Demo qui echoue
     Loaded: loaded (/etc/systemd/system/demo.service; disabled; preset: enabled)
     Active: active (running) since Sun 2026-07-12 16:54:43 UTC; 11ms ago
   Main PID: 551 ((app.py))

La parade

Déclarez Type=exec dès que votre ExecStart= lance un binaire au premier plan : systemd (version 240 et supérieure, donc toutes les distributions maintenues) vérifie alors que l'exécutable existe et est exécutable avant de rendre la main. Si vous devez rester en Type=simple, ne faites jamais confiance au code de retour de start : vérifiez après coup avec sleep 3 && systemctl is-active mon-app.service.

Redémarrer automatiquement en cas de crash

Un service qui meurt à trois heures du matin doit se relever tout seul. La directive Restart= gère ce cas, et les directives StartLimit* empêchent la boucle de redémarrage infinie qui masquerait un vrai problème.

Directive	Valeur	Effet
Restart	on-failure	Redémarre si le code de sortie est non nul, ou après un signal ou un timeout
Restart	always	Redémarre toujours, sauf après un systemctl stop explicite
Restart	no	Ne redémarre jamais (le défaut)
RestartSec	5s	Attend 5 secondes entre deux tentatives
StartLimitBurst	3	Au-delà de 3 tentatives dans la fenêtre, systemd abandonne
StartLimitIntervalSec	60s	La fenêtre de comptage des tentatives

Glissez pour voir

Restart=on-failure couplé à RestartSec=5s est le réglage par défaut raisonnable pour une application métier. Restart=always a un effet de bord vicieux : il relance aussi un service dont la configuration est cassée, ce qui remplit le journal et retarde le diagnostic.

Diagnostiquer un service qui échoue

Quand un service est en failed, la cause est presque toujours écrite noir sur blanc dans le journal. Encore faut-il la lire au bon endroit. Ce workflow en quatre temps résout la majorité des cas.

1. Lire le statut, qui affiche déjà les dernières lignes de journal :

   systemctl status mon-app.service

2. Ouvrir le journal complet de l'unité, avec les explications de systemd :

   journalctl -xeu mon-app.service

   L'option -x ajoute les explications contextuelles, -e saute à la fin, -u filtre sur l'unité.

3. Repérer le code d'échec. Sur un service dont l'ExecStart= pointe vers un fichier absent, le journal est explicite :

   demo.service: Main process exited, code=exited, status=203/EXEC
   demo.service: Failed with result 'exit-code'.

   Le code 203/EXEC est de loin le plus fréquent : l'exécutable est introuvable, non exécutable, ou son chemin comporte une faute de frappe. Un ls -l sur le chemin de l'ExecStart= tranche en une seconde.

4. Corriger, recharger, relancer, dans cet ordre :

   sudo systemctl daemon-reload
   sudo systemctl restart mon-app.service
   sleep 3 && systemctl is-active mon-app.service

Les codes d'échec les plus courants forment un vocabulaire à connaître par cœur : 203/EXEC pour un chemin invalide, 217/USER pour un User= qui n'existe pas, 200/CHDIR pour un WorkingDirectory= absent, 226/NAMESPACE pour une directive de durcissement trop stricte.

Quand le service reste en échec

Le redémarrage en boucle, la limite StartLimitBurst atteinte, systemctl reset-failed et le catalogue complet des codes de sortie sont traités dans le guide Un service ne démarre pas : méthode de diagnostic.

Durcir un service exposé

Un service accessible depuis le réseau ne devrait pas pouvoir lire /home, charger un module noyau ou obtenir de nouveaux privilèges. systemd fournit des directives de sandboxing qui s'ajoutent à la section [Service] sans modifier une ligne de l'application. Ces quatre-là couvrent déjà l'essentiel du risque et cassent rarement quoi que ce soit :

[Service]
NoNewPrivileges=true       # interdit toute élévation de privilèges (suid)
ProtectSystem=strict       # tout le système de fichiers en lecture seule
ReadWritePaths=/var/lib/mon-app
ProtectHome=true           # /home, /root et /run/user invisibles
PrivateTmp=true            # un /tmp isolé, invisible des autres services

La commande systemd-analyze security mon-app.service note le service de 0 à 10 (plus le score est bas, mieux c'est) et liste les protections manquantes une par une. C'est la façon la plus rapide de mesurer l'effet d'une directive : on note avant, on ajoute, on note après.

Durcir une directive à la fois

Une option de sandboxing peut empêcher un service parfaitement sain de démarrer : accès fichier refusé, réseau coupé. Ajoutez les directives une par une, testez entre chaque, et si le service tombe en 226/NAMESPACE, c'est la dernière ajoutée qui est coupable. Le jeu complet de directives et le diagnostic détaillé sont dans le guide Durcir un service systemd avec le sandboxing.

Dépannage

Les symptômes ci-dessous couvrent la quasi-totalité des appels au support sur un service systemd. La colonne de droite donne l'action, pas une piste.

Symptôme	Cause probable	Solution
systemctl start réussit mais le service est mort	Type=simple ne vérifie pas l'exec()	Passer en Type=exec, ou vérifier avec sleep 3 && systemctl is-active <service>
Service failed avec 203/EXEC	Binaire absent, chemin erroné ou non exécutable	ls -l sur le chemin de l'ExecStart=, puis chmod +x si besoin
Le service ne figure pas dans list-units	Il est installé mais jamais chargé	systemctl list-unit-files --type=service | grep <nom>
Modification du fichier d'unité sans effet	systemd utilise sa version en cache	sudo systemctl daemon-reload puis restart
start répond Unit is masked	Service masqué vers /dev/null	sudo systemctl unmask <service>
enable répond unit is static	Aucune section [Install] dans l'unité	Normal : le service est tiré par une dépendance, pas par un enable
Le service tourne mais disparaît après reboot	Jamais activé au boot	sudo systemctl enable <service> puis vérifier is-enabled
Permission denied dans le journal	User= sans droits sur les fichiers	Vérifier le propriétaire des fichiers et les directives de durcissement

Glissez pour voir

Mettre en pratique

Écrire une unité en lisant un guide et la faire tenir debout sur un système réel sont deux exercices distincts. Dans une VM jetable, vous rédigez un fichier .service complet, le chargez avec daemon-reload, l'activez avec enable --now et contrôlez son état réel avec is-active et le journal.

Lab pratique

Créer et activer une unité de service systemd

$ dsoxlab run l3-service-create-unit

Environnement : VM·Durée : ~30 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/linux-dsoxlab-training.git
cd linux-dsoxlab-training

Lancer ce lab, puis valider votre travail :

dsoxlab run l3-service-create-unit
dsoxlab check l3-service-create-unit

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• list-units liste ce qui est chargé en mémoire, list-unit-files ce qui est installé sur le disque. Un service installé mais jamais démarré n'apparaît pas dans list-units sans --all : 14 unités chargées contre 119 fichiers installés sur le serveur de démonstration.
• Pour un audit, la bonne commande est systemctl list-unit-files --type=service --state=enabled : elle dit ce qui démarrera au prochain boot.
• enabled et active sont indépendants : l'un parle du prochain boot, l'autre de maintenant.
• Type=simple ment. Sur un binaire absent, systemctl start renvoie 0 et is-active répond active alors que le service est déjà mort en 203/EXEC. Déclarez Type=exec, ou vérifiez l'état quelques secondes après le démarrage.
• 203/EXEC est le code d'échec le plus fréquent : chemin d'ExecStart= invalide ou fichier non exécutable.
• Après toute modification d'un fichier d'unité, daemon-reload est obligatoire, sinon systemd garde sa version en cache.
• reload relit la configuration sans couper les connexions, restart tue le processus : préférez reload quand l'unité déclare un ExecReload=.
• mask est plus strict que disable : il rend le service impossible à démarrer, même par une dépendance.

Pour aller plus loin

• Activer un service au démarrage : targets, WantedBy, presets et test de persistance après reboot.
• Un service ne démarre pas : codes de sortie, reset-failed et redémarrage en boucle.
• Un service actif qui ne répond pas : quand systemctl affiche active (running) et que le service est pourtant muet.
• Durcir un service systemd avec le sandboxing : le jeu complet des directives de protection et le score systemd-analyze security.
• Planifier une tâche avec les timers systemd : l'alternative à cron, avec journalisation intégrée.

Questions fréquentes

Qu'est-ce que systemd et pourquoi a-t-il remplacé les anciens systèmes d'init ?

systemd est le système d'initialisation et de gestion de services utilisé par la majorité des distributions Linux modernes (Ubuntu, Debian, RHEL, Fedora, Arch). Il offre un démarrage parallèle plus rapide, une gestion automatique des dépendances, une journalisation centralisée via journalctl, une surveillance intégrée et une meilleure isolation via cgroups et namespaces. Les composants principaux sont systemctl pour la gestion des services, journalctl pour les logs, et systemd-analyze pour l'analyse du démarrage.

Quelles sont les commandes systemctl essentielles à connaître ?

Les commandes systemctl essentielles sont : start/stop/restart/reload pour gérer un service, status pour vérifier son état, enable/disable pour l'activation au boot, enable --now pour activer et démarrer simultanément, list-units --type=service pour lister les services, list-units --state=failed pour voir les échecs, et daemon-reload après modification d'un fichier .service.

Comment créer un service systemd personnalisé ?

Pour créer un service personnalisé, créez un fichier .service dans /etc/systemd/system/. Le fichier contient trois sections : [Unit] pour la description et les dépendances, [Service] pour définir le type, l'utilisateur, le répertoire de travail et la commande ExecStart, et [Install] pour spécifier le target. Après création, exécutez daemon-reload, puis enable et start pour activer le service.

Quelle est la différence entre enable, start, restart et reload ?

start démarre le service immédiatement mais pas au reboot. enable active le démarrage automatique au boot sans effet immédiat. restart arrête et redémarre le service. reload recharge la configuration sans interruption (si supporté). La combinaison enable --now permet d'activer au boot et démarrer immédiatement en une seule commande.

Comment diagnostiquer un service qui ne démarre pas ?

Pour diagnostiquer un service en échec : vérifiez l'état avec systemctl status, consultez les logs avec journalctl -u service-name, vérifiez la syntaxe du fichier avec systemd-analyze verify, puis testez manuellement la commande ExecStart. Les codes d'erreur courants sont 203/EXEC pour un chemin invalide, 217/USER pour un utilisateur inexistant, et 200/CHDIR pour un répertoire de travail manquant.

Comment voir les logs d'un service avec journalctl ?

journalctl permet de consulter les logs systemd. Utilisez journalctl -u service pour voir les logs d'un service, -n 100 pour les dernières lignes, -f pour suivre en temps réel, -b pour le boot actuel, --since pour filtrer par date, et -p err pour les erreurs uniquement. Pour gérer l'espace disque, utilisez --vacuum-time ou --vacuum-size pour nettoyer les anciens logs.

Qu'est-ce qu'un target systemd et comment ça fonctionne ?

Un target systemd est un groupe de services qui définit un état du système, équivalent aux anciens runlevels. Les targets courants sont poweroff.target pour l'arrêt, rescue.target pour la maintenance, multi-user.target pour le mode serveur sans GUI, et graphical.target pour le mode desktop. Utilisez get-default pour voir le target actuel et set-default pour le modifier.

Comment masquer un service pour l'empêcher de démarrer ?

Masquer un service avec systemctl mask est plus strict que disable. Disable empêche le démarrage automatique au boot mais permet le démarrage manuel. Mask bloque complètement le service en créant un lien symbolique vers /dev/null, rendant impossible tout démarrage même manuel. Utilisez unmask pour restaurer le service. C'est utile pour les services vulnérables ou incompatibles.

Comment limiter les ressources d'un service (CPU, mémoire) ?

systemd utilise les cgroups pour limiter les ressources. Dans le fichier .service, utilisez MemoryMax pour la limite mémoire, CPUQuota pour le pourcentage CPU, et TasksMax pour le nombre de processus. Vous pouvez aussi appliquer des limites temporaires avec systemctl set-property. L'option OOMPolicy=kill permet de tuer le service en cas de dépassement mémoire.

Comment sécuriser un service systemd ?

systemd offre des options de durcissement pour isoler les services. Les principales sont : User et Group pour exécuter en non-root, NoNewPrivileges pour empêcher l'élévation de privilèges, ProtectSystem=strict et ProtectHome pour protéger le système de fichiers, PrivateTmp pour isoler /tmp, et SystemCallFilter pour filtrer les appels système. Utilisez systemd-analyze security pour évaluer le niveau de sécurité.

Comment analyser le temps de démarrage du système ?

systemd-analyze permet d'identifier les services qui ralentissent le boot. Utilisez systemd-analyze sans argument pour le temps total, blame pour lister les services les plus lents, plot pour générer un graphique SVG du démarrage, et critical-chain pour voir la chaîne de dépendances critique. Les optimisations courantes incluent désactiver les services inutilisés comme snapd ou NetworkManager-wait-online.

Comment redémarrer automatiquement un service qui plante ?

systemd peut redémarrer automatiquement les services en échec avec les options Restart et RestartSec dans la section [Service]. Restart=on-failure redémarre en cas d'erreur, Restart=always redémarre toujours sauf après systemctl stop. RestartSec définit le délai entre redémarrages. StartLimitBurst et StartLimitIntervalSec limitent le nombre de redémarrages par intervalle pour éviter les boucles infinies.

Comment programmer une tâche planifiée avec systemd timer ?

Les timers systemd remplacent avantageusement cron. Créez un fichier .service avec Type=oneshot pour la tâche à exécuter, puis un fichier .timer avec OnCalendar pour définir la planification. La syntaxe OnCalendar accepte daily, hourly, ou des formats comme Mon *-*-* 08:00:00. Persistent=true permet de rattraper les exécutions manquées. Activez le timer avec systemctl enable --now backup.timer.

Quels sont les types de services systemd (simple, forking, oneshot) ?

Le Type définit comment systemd détecte que le service est prêt. simple (défaut) considère le processus ExecStart comme le service. forking attend que le processus se fork et que le parent quitte, utilisé pour les daemons traditionnels avec PIDFile. oneshot exécute une fois et termine, idéal pour les scripts de maintenance. notify attend un signal du service. dbus attend l'acquisition d'un nom D-Bus.

Comment gérer les dépendances entre services ?

systemd gère les dépendances via des directives dans la section [Unit]. After et Before définissent l'ordre de démarrage. Requires crée une dépendance forte où l'échec de l'un arrête l'autre. Wants crée une dépendance souple qui continue même si l'autre échoue. BindsTo synchronise l'arrêt des deux services. Conflicts empêche deux services de tourner ensemble. Utilisez list-dependencies pour visualiser les dépendances.

×

📖 Voir la documentation →