Linux sans magie #18 — systemctl : démarrer, arrêter et diagnostiquer un service sans magie

Dans l’article précédent, nous avons vu que systemd ne se contente pas de remplacer les scripts /etc/init.d : il gère des unités, leurs dépendances et leur état. L’étape suivante consiste à apprendre à dialoguer avec ce gestionnaire sans traiter systemctl comme une suite de commandes à mémoriser.

systemctl est l’outil principal pour interroger et piloter le gestionnaire systemd. Il permet notamment d’observer l’état d’une unité, de la démarrer, de l’arrêter, de la redémarrer, de demander un rechargement applicatif lorsqu’il est supporté, et de vérifier si elle est active ou prévue pour être activée automatiquement.

L’objectif de cet article est de construire un raisonnement simple : observer d’abord, agir ensuite, puis vérifier le résultat.

Contexte et problème

Quand un service semble « ne pas marcher », plusieurs questions différentes se mélangent souvent :

• le service est-il démarré maintenant ?
• est-il en échec ?
• démarrera-t-il automatiquement au prochain boot ?
• faut-il le redémarrer ou seulement recharger sa configuration ?
• l’action demandée a-t-elle réellement produit l’état attendu ?

Ces questions ne se répondent pas toutes avec la même commande.

Une confusion fréquente consiste par exemple à croire qu’un service enabled est forcément en cours d’exécution. Ce n’est pas le cas. Dans systemd, activation automatique et état courant sont deux notions distinctes.

La documentation de systemctl l’exprime clairement : une unité peut être activée pour démarrer automatiquement sans être actuellement lancée, ou être lancée sans être activée pour le prochain boot.

Concept ou architecture

status : comprendre l’état courant

La commande :

systemctl status <unite>

affiche une vue de diagnostic destinée à l’humain.

Pour un service, elle permet notamment d’observer :

• l’état global de l’unité ;
• son état actif ;
• le processus principal lorsqu’il existe ;
• quelques informations récentes utiles au diagnostic.

Exemple :

systemctl status ssh.service

Le nom exact du service dépend de la distribution. N’utilisez donc pas cet exemple pour agir sans avoir identifié l’unité réellement présente sur votre machine.

Pour les scripts ou les tests automatiques, status n’est pas toujours le meilleur choix : son affichage est pensé pour être lu par un humain. Des commandes plus ciblées existent pour obtenir un état exploitable directement.

is-active : le service fonctionne-t-il maintenant ?

systemctl is-active <unite>

vérifie si l’unité est active.

La documentation systemd indique que la commande renvoie un code de sortie nul lorsqu’au moins une unité demandée est active, et un code non nul sinon.

Pour une vérification manuelle :

systemctl is-active example.service

peut afficher par exemple :

active

ou :

inactive

Cette commande répond à la question : « est-ce actif maintenant ? »

is-enabled : démarrera-t-il automatiquement ?

systemctl is-enabled <unite>

ne répond pas à la même question.

Elle vérifie l’état d’activation du fichier d’unité. Un résultat enabled signifie en pratique que l’unité est reliée aux emplacements prévus pour une activation automatique selon sa configuration.

On peut donc avoir :

is-active  → active
is-enabled → disabled

Un service peut avoir été lancé manuellement sans être configuré pour démarrer automatiquement.

Inversement :

is-active  → inactive
is-enabled → enabled

peut être parfaitement cohérent si le service n’a pas encore été démarré dans la session actuelle ou s’il a été arrêté manuellement.

Cette distinction est fondamentale pour éviter les diagnostics erronés.

Démarrer, arrêter et redémarrer

start

systemctl start <unite>

demande l’activation immédiate d’une unité.

Pour un service, cela conduit généralement systemd à démarrer le processus défini par l’unité, avec ses dépendances et contraintes associées.

Le point important : start agit sur l’état courant. Il ne signifie pas automatiquement que l’unité sera lancée aux prochains boots.

stop

systemctl stop <unite>

demande la désactivation immédiate de l’unité.

Cette action peut interrompre un service réellement utilisé. Sur un système de production, il faut donc connaître l’impact métier avant de l’exécuter.

restart

systemctl restart <unite>

redémarre une unité. La documentation précise que si l’unité n’est pas déjà active, restart peut également la démarrer.

Autrement dit, restart ne signifie pas seulement :

si actif → arrêter puis relancer

mais peut aussi conduire à :

si inactif → démarrer

C’est une différence importante avec try-restart, qui ne redémarre l’unité que si elle est déjà active.

reload n’est pas restart

La commande :

systemctl reload <unite>

demande au service de recharger sa propre configuration lorsqu’il sait le faire.

Elle ne recharge pas le fichier d’unité systemd lui-même.

Par exemple, si vous modifiez le fichier de configuration d’un serveur qui sait relire sa configuration sans arrêter le processus, reload peut être approprié.

En revanche, si vous modifiez un fichier d’unité systemd, la commande pertinente côté gestionnaire est :

systemctl daemon-reload

Ces deux opérations sont différentes :

systemctl reload service
→ demande au service de relire sa configuration applicative

systemctl daemon-reload
→ demande à systemd de relire les fichiers d’unités

Ne les confondez pas.

Tous les services ne supportent pas reload. Une demande peut donc échouer si l’unité n’expose aucun mécanisme de rechargement.

Prérequis

Le lab utilise une unité transitoire utilisateur afin d’éviter de modifier un service système réel.

Nous allons utiliser systemd-run --user pour lancer un simple sleep 600 comme service temporaire géré par le systemd de l’utilisateur courant.

Une unité transitoire est créée à l’exécution via systemd et n’a pas besoin d’un fichier permanent sous /etc/systemd/system ou ~/.config/systemd/user.

Prérequis :

• une distribution utilisant systemd ;
• une session utilisateur disposant d’un gestionnaire systemd utilisateur actif ;
• les commandes systemd-run, systemctl et sleep.

Vérifiez :

command -v systemd-run
command -v systemctl
command -v sleep

Si systemctl --user ne peut pas joindre un gestionnaire utilisateur dans votre environnement — cas possible dans certains conteneurs ou sessions minimales — n’utilisez pas arbitrairement un service système à la place. Faites le lab sur une VM ou une session systemd utilisateur adaptée.

Mise en pratique

1. Créer un service transitoire sans privilèges root

Exécutez :

systemd-run --user --unit=linux-sans-magie-demo sleep 600

Le service créé porte normalement le nom :

linux-sans-magie-demo.service

Il exécute simplement sleep 600 dans le gestionnaire systemd de votre utilisateur.

Aucun sudo n’est nécessaire.

2. Observer avec status

systemctl --user status linux-sans-magie-demo.service --no-pager

Vous devez observer une unité active avec un processus sleep associé.

Le résultat exact peut varier selon la version de systemd, mais l’état doit permettre d’identifier que le service est en cours d’exécution.

3. Vérifier explicitement l’état actif

systemctl --user is-active linux-sans-magie-demo.service

Résultat attendu :

active

Vous pouvez également observer le code de retour :

systemctl --user is-active --quiet linux-sans-magie-demo.service
echo $?

Résultat attendu :

0

4. Vérifier l’état d’activation

Exécutez :

systemctl --user is-enabled linux-sans-magie-demo.service

Comme l’unité a été créée de façon transitoire et non installée comme unité persistante activée pour une session future, le résultat ne doit pas être interprété comme enabled au sens d’un service configuré pour démarrer automatiquement.

Selon la version de systemd, un état tel que transient peut être affiché.

Le point à retenir est la différence : le service peut être actif maintenant sans être activé pour un futur démarrage.

5. Redémarrer le service

systemctl --user restart linux-sans-magie-demo.service

Vérifiez ensuite :

systemctl --user is-active linux-sans-magie-demo.service

Résultat attendu :

active

Le PID du processus sleep peut avoir changé, ce qui permet d’observer qu’un nouveau processus a été lancé.

Vous pouvez le vérifier avec :

systemctl --user show linux-sans-magie-demo.service -p MainPID

6. Tester l’arrêt

systemctl --user stop linux-sans-magie-demo.service

Puis :

systemctl --user is-active linux-sans-magie-demo.service

Résultat attendu :

inactive

À ce stade, le service n’exécute plus sleep.

7. Comprendre pourquoi reload n’est pas testé ici

Le programme sleep n’expose aucune configuration applicative à recharger.

Il serait donc artificiel d’utiliser :

systemctl --user reload linux-sans-magie-demo.service

comme si tous les services savaient se recharger.

Le bon réflexe est de vérifier si l’unité et l’application supportent réellement une opération de reload avant de l’utiliser.

Vérification

Le lab est réussi si vous pouvez démontrer la séquence suivante :

création d'une unité transitoire utilisateur
        ↓
status → unité observée
        ↓
is-active → active
        ↓
is-enabled → pas assimilé à enabled
        ↓
restart → toujours active, processus relancé
        ↓
stop
        ↓
is-active → inactive

L’objectif n’est pas simplement de mémoriser cinq verbes. Il est de comprendre ce que chacun mesure ou modifie.

Bonnes pratiques

Commencez par observer :

systemctl status <unite>

puis utilisez des commandes ciblées :

systemctl is-active <unite>
systemctl is-enabled <unite>

avant d’agir.

Après un start, stop ou restart, vérifiez toujours l’état obtenu. L’absence de message d’erreur n’est pas une preuve suffisante du bon fonctionnement métier du service.

Sur un système réel, complétez donc la vérification systemd par un contrôle fonctionnel : port d’écoute, endpoint, traitement d’une requête ou autre preuve adaptée à l’application.

Évitez également le réflexe :

sudo systemctl restart ...

sans diagnostic préalable. Un redémarrage peut masquer temporairement un défaut, interrompre des utilisateurs ou détruire des informations utiles au diagnostic.

Sécurité

Les commandes start, stop, restart et reload modifient l’état d’une unité. Sur des unités système, elles nécessitent généralement des privilèges appropriés et peuvent avoir un impact de production.

Le lab utilise donc --user et une unité créée pour l’exercice afin de réduire le risque.

Ne testez pas ces commandes sur un service critique simplement pour reproduire l’article.

Si une commande système exige une élévation de privilèges, vérifiez d’abord que vous avez identifié la bonne unité et compris l’impact de l’opération avant d’utiliser sudo.

Coûts

Le lab ne nécessite aucune ressource payante.

Il peut être exécuté sur une machine Linux ou une VM de laboratoire disposant de systemd. Si vous utilisez une VM cloud temporaire, les coûts éventuels dépendent du fournisseur et de la durée d’utilisation ; supprimez ou arrêtez la ressource après le test.

Limites et points de vigilance

systemctl status ne remplace pas une analyse complète des journaux. L’article suivant sera consacré à journalctl pour retrouver précisément les messages d’un service.

Cet article ne traite pas non plus en profondeur :

• enable, disable et mask ;
• les presets systemd ;
• try-restart et reload-or-restart ;
• les unités templates ;
• les services système nécessitant une politique d’autorisation spécifique ;
• l’analyse détaillée d’un échec avec le journal.

Les résultats d’affichage peuvent varier selon la version de systemd et la distribution. La logique active contre enabled, ainsi que la différence entre reload et daemon-reload, reste cependant essentielle.

Rollback ou nettoyage

Le lab ne crée pas de fichier d’unité persistant.

Si le service transitoire est encore actif :

systemctl --user stop linux-sans-magie-demo.service

Vérifiez :

systemctl --user is-active linux-sans-magie-demo.service

Le résultat attendu est inactive.

Une unité transitoire n’est pas destinée à devenir une configuration permanente. Aucun fichier sous /etc/systemd/system n’est créé par ce lab.

Références officielles

• systemctl — Control the systemd system and service manager — systemd upstream
• systemd-run — Run programs in transient scope units, service units, or path-, socket-, or timer-triggered service units — systemd upstream
• systemd.service — Service unit configuration — systemd upstream

Conclusion

systemctl devient beaucoup plus simple lorsqu’on sépare les questions.

status aide à lire l’état courant. is-active répond à « est-ce actif maintenant ? ». is-enabled répond à une question différente sur l’activation future. start, stop et restart modifient l’état courant, tandis que reload demande au service de relire sa propre configuration lorsqu’il sait le faire.

Le réflexe à retenir est donc :

observer
→ identifier l'état réel
→ agir avec la commande adaptée
→ vérifier le résultat

Dans l’article suivant, nous irons plus loin dans le diagnostic avec journalctl pour retrouver les bons logs d’un service sans fouiller partout.

---