systemctl au quotidien

Pourquoi on voit ça

Tu sais maintenant ce qu’est une unité et comment elle est écrite. Reste à piloter systemd : c’est le rôle de la commande systemctl.

C’est sans doute la commande que tu taperas le plus souvent sur un serveur. Déployer une application, appliquer une configuration, comprendre une panne à 3 h du matin : tout passe par elle. L’objectif de cette leçon est que tu ne confondes plus jamais deux commandes qui se ressemblent.

Dans les exemples, on prend le service nginx. Tu peux écrire nginx ou nginx.service : sans extension, systemctl comprend .service. Ces commandes se lancent en root (ou avec sudo), sauf celles qui ne font que lire.

Regarder : status

systemctl status nginx

C’est la commande à lancer en premier, toujours. Elle affiche notamment :

● nginx.service - A high performance web server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; ...)
     Active: active (running) since ...
   Main PID: 812 (nginx)

Ligne	Ce qu’elle t’apprend
Loaded	où se trouve le fichier d’unité, et si le service est activé au démarrage (enabled ou disabled)
Active	l’état en ce moment : active (running), inactive (dead) ou failed
les dernières lignes	les derniers messages du service

Agir maintenant : start, stop, restart, reload

Commande	Effet
systemctl start nginx	démarre le service
systemctl stop nginx	arrête le service
systemctl restart nginx	l’arrête puis le redémarre
systemctl reload nginx	lui demande de relire sa configuration, sans s’arrêter

La différence entre restart et reload compte en production. restart coupe le service un instant : les connexions en cours tombent. reload garde le processus en vie. Quand le service le permet, on préfère donc reload après une modification de sa configuration.

Maintenant ou au démarrage : start contre enable

C’est le piège le plus classique. Il y a deux questions indépendantes :

Question	Pour dire oui	Pour dire non
Le service tourne-t-il maintenant ?	start	stop
Sera-t-il lancé au démarrage du serveur ?	enable	disable

Les quatre combinaisons existent. Un service peut tourner sans être activé : il disparaîtra au prochain redémarrage. Il peut être activé sans tourner : il ne démarrera qu’au prochain redémarrage.

C’est comme un réveil : start, c’est te lever maintenant ; enable, c’est régler le réveil pour tous les matins. L’un ne fait pas l’autre.

Pour faire les deux d’un coup :

systemctl enable --now nginx

enable --now active le service au démarrage et le démarre tout de suite.

enable utilise la ligne WantedBy= de la section [Install] vue dans la leçon précédente : il accroche le service à cette cible.

Concrètement, enable crée un lien dans /etc/systemd/system/multi-user.target.wants/ (le dossier de la cible nommée par WantedBy=), qui pointe vers le fichier de l’unité. disable supprime ce lien.

Interdire un service : mask

disable empêche le lancement automatique, mais n’importe qui peut encore faire start, et une autre unité peut encore l’entraîner comme dépendance. Pour l’interdire complètement :

systemctl mask apache2

Un service masqué ne peut plus être démarré du tout, ni à la main, ni par une autre unité. Pour lever l’interdiction :

systemctl unmask apache2

Concrètement, mask crée dans /etc/systemd/system un lien au nom de l’unité, qui pointe vers /dev/null : systemd n’y trouve plus qu’un fichier vide. unmask supprime ce lien.

Niveau	Commande	Le service peut encore être lancé…
arrêté	stop	à la main, et au démarrage s’il est activé
désactivé	disable	à la main, ou par une autre unité
masqué	mask	jamais, jusqu’à unmask

Après avoir modifié un fichier d’unité : daemon-reload

systemd lit les fichiers d’unité une fois, puis les garde en mémoire. Si tu modifies un fichier .service, il ne le voit pas tout seul. Tu dois le lui dire :

systemctl daemon-reload
systemctl restart monapp

daemon-reload fait relire tous les fichiers d’unité à systemd. Il ne redémarre aucun service : c’est pour ça qu’on enchaîne avec restart.

À ne pas confondre :

Tu as modifié…	Commande
la configuration du service (ex. /etc/nginx/nginx.conf)	systemctl reload nginx
le fichier d’unité (ex. monapp.service)	systemctl daemon-reload, puis restart

Remettre le compteur à zéro : reset-failed

Quand un service plante, il passe dans l’état failed, et il y reste affiché même si la cause a disparu. Pour effacer cet état :

systemctl reset-failed monapp

reset-failed ne répare rien et ne démarre rien : il efface l’état d’échec. C’est utile après une réparation, ou quand un service a planté trop de fois de suite et que systemd refuse de le relancer.

Poser une question simple : is-active, is-enabled

systemctl is-active nginx
systemctl is-enabled nginx

Commande	Réponses possibles	Correspond à
is-active	active, inactive, failed	start / stop
is-enabled	enabled, disabled, masked	enable / disable

Une réponse d’un seul mot : c’est idéal dans un script.

Lire les journaux : journalctl -u

status ne montre que les dernières lignes. Pour lire tous les messages d’un service :

journalctl -u nginx

-u comme unit. Sans cette option, journalctl affiche le journal de tout le système. C’est dans ces messages que tu trouves la vraie raison d’une panne : fichier introuvable, port déjà utilisé, permission refusée.

La méthode de dépannage

Un service refuse de démarrer ? On observe avant de toucher à quoi que ce soit, et on vérifie à la fin.

À retenir

• systemctl status nom d’abord : Loaded dit si le service est activé au démarrage, Active dit s’il tourne maintenant.
• start / stop = maintenant. enable / disable = au démarrage. enable --now = les deux.
• reload : le service relit sa configuration sans s’arrêter. restart : il s’arrête et repart.
• mask : le service ne peut plus être démarré du tout, jusqu’à unmask.
• Fichier d’unité modifié → systemctl daemon-reload, puis restart. reset-failed efface l’état d’échec.
• Dépannage : status, puis journalctl -u nom, puis corriger, daemon-reload, start, et vérifier avec is-active.