Maîtrise de systemctl : Commandes essentielles pour la gestion des services Linux

Si vous gérez des serveurs Linux, vous utiliserez systemctl constamment. Vous l'utilisez lorsque Nginx ne démarre pas, lorsque PostgreSQL doit être lancé après un redémarrage, lorsqu'un déploiement nécessite un redémarrage propre, et lorsqu'un service indique « échec » mais que la véritable erreur est enfouie dans le journal.

La commande n'est pas difficile, mais elle comporte quelques distinctions importantes : démarrer n'est pas la même chose qu'activer, recharger n'est pas la même chose que redémarrer, et désactiver n'est pas la même chose que masquer. Une fois ces points clarifiés, la gestion des services devient beaucoup moins mystérieuse.

Comprendre systemd et systemctl

systemd est le système d'initialisation et le gestionnaire de services utilisé par de nombreuses distributions Linux majeures, y compris les versions courantes de Debian, Ubuntu, Fedora et la famille RHEL. Il initialise l'espace utilisateur et gère les processus, sessions, minuteries, sockets, points de montage et services.

systemctl est l'utilitaire en ligne de commande principal utilisé pour contrôler et inspecter l'état du gestionnaire systemd et de ses composants (unités). Les services, qui sont les programmes s'exécutant en arrière-plan (démons), sont gérés en tant qu'unités de service (se terminant généralement par .service).

Concepts clés : Unités et cibles

Bien que cet article se concentre sur les services, rappelez-vous que systemctl gère diverses unités :

Unités de service (.service) : Pour gérer les processus d'arrière-plan (par exemple, nginx.service).
Unités cibles (.target) : Pour regrouper des unités afin de représenter un état système spécifique (par exemple, multi-user.target, qui représente un environnement serveur typique).

Commandes essentielles pour le contrôle des services (état d'exécution)

Ces commandes contrôlent directement si un service est actuellement en cours d'exécution ou arrêté dans la session système active.

1. Démarrer un service

Utilisez la commande start pour lancer immédiatement un service, indépendamment de sa configuration de démarrage.

sudo systemctl start <nom_service>.service
# Exemple : Démarrer le serveur web Apache
sudo systemctl start apache2.service

2. Arrêter un service

Utilisez la commande stop pour terminer proprement un service en cours d'exécution.

sudo systemctl stop <nom_service>.service
# Exemple : Arrêter le service de base de données MySQL
sudo systemctl stop mariadb.service

3. Redémarrer un service

Cette commande est couramment utilisée après des modifications de fichiers de configuration. Elle arrête le service puis le redémarre immédiatement.

sudo systemctl restart <nom_service>.service
# Exemple : Redémarrer le démon SSH
sudo systemctl restart sshd.service

4. Recharger la configuration

De nombreux services prennent en charge une opération de rechargement, qui applique les nouveaux fichiers de configuration sans interrompre les connexions existantes ni arrêter complètement le processus. C'est plus rapide et moins perturbateur qu'un redémarrage complet.

sudo systemctl reload <nom_service>.service
# Exemple : Recharger la configuration de Nginx
sudo systemctl reload nginx.service

Astuce : Vérifiez toujours la documentation du service. Si un service ne prend pas en charge le reload, l'utilisation de restart est nécessaire après les modifications de configuration.

Commandes essentielles pour la persistance des services (état de démarrage)

Alors que démarrer un service le fait fonctionner maintenant, l'activer ou le désactiver contrôle s'il démarrera automatiquement au démarrage du système.

1. Activer un service

Pour garantir qu'un service démarre automatiquement après un redémarrage, vous devez l'activer. Cela crée les liens symboliques nécessaires dans les répertoires de configuration de systemd (/etc/systemd/system/).

sudo systemctl enable <nom_service>.service
# Exemple : Activer PostgreSQL pour qu'il démarre au démarrage
sudo systemctl enable postgresql.service

2. Désactiver un service

Pour empêcher un service de démarrer automatiquement au démarrage, vous devez le désactiver. Cela supprime les liens symboliques créés par la commande enable.

sudo systemctl disable <nom_service>.service
# Exemple : Désactiver le service Bluetooth sur un serveur
sudo systemctl disable bluetooth.service

3. Masquer un service

Masquer une unité empêche son démarrage manuel, automatique ou via des dépendances. Utilisez-le lorsque « ne pas démarrer ceci » doit être plus fort que disable.

sudo systemctl mask <nom_service>.service

# Pour annuler le masquage :
sudo systemctl unmask <nom_service>.service

Vérification de l'état et des informations du service

Savoir si un service est en cours d'exécution et pourquoi il pourrait échouer est essentiel pour le dépannage.

1. Vérification de l'état

La commande status fournit un aperçu détaillé et immédiat du service, indiquant s'il est actif, chargé, son ID de processus et les entrées de journal récentes.

systemctl status <nom_service>.service
# Exemple : Vérifier l'état du pare-feu
systemctl status firewalld.service

Interprétation de la sortie :

Recherchez trois lignes clés dans la sortie :

Loaded : Indique si le fichier d'unité a été chargé correctement (par exemple, loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)).
Active : Indique l'état d'exécution actuel (par exemple, active (running) ou failed).
CGroup : Affiche l'arborescence des processus associée au service.

2. Interrogation de la persistance au démarrage

Vous pouvez vérifier si un service est configuré pour démarrer automatiquement sans consulter la sortie d'état complète :

systemctl is-enabled <nom_service>.service
# La sortie sera 'enabled', 'disabled' ou 'masked'

3. Consultation des journaux avec journalctl

Bien que status affiche les dernières lignes de sortie, pour un débogage approfondi, vous devez utiliser journalctl. Cette commande interroge le journal systemd, qui collecte tous les journaux système et de service.

Pour consulter les journaux spécifiquement pour un service :

# Afficher tous les journaux du service depuis le dernier redémarrage
journalctl -u <nom_service>.service

# Afficher les journaux en temps réel (comme tail -f)
journalctl -u <nom_service>.service -f

# Afficher les journaux depuis hier
journalctl -u <nom_service>.service --since "yesterday"

Avertissement : Si un service affiche un état failed, journalctl -u <service> -r (ordre inverse, affichant les plus récents en premier) est souvent le moyen le plus rapide de voir le message d'erreur à l'origine de l'échec.

4. Vérifier si un service est en cours d'exécution dans des scripts

Pour les scripts shell, systemctl status est trop verbeux. Utilisez les commandes d'interrogation :

systemctl is-active --quiet nginx.service
echo $?

systemctl is-failed nginx.service
systemctl is-enabled nginx.service

is-active --quiet renvoie un code de sortie utile sans imprimer la page d'état complète. Cela le rend meilleur pour les vérifications de santé et l'automatisation.

if ! systemctl is-active --quiet nginx.service; then
    echo "nginx n'est pas en cours d'exécution" >&2
    exit 1
fi

5. Lister les unités

Lorsque vous ne connaissez pas le nom exact du service, listez les unités :

systemctl list-units --type=service
systemctl list-units --type=service --state=failed
systemctl list-unit-files --type=service

list-units affiche les unités chargées et leur état d'exécution actuel. list-unit-files affiche les fichiers d'unité et s'ils sont activés, désactivés, statiques, masqués ou générés. Cette distinction explique pourquoi un service peut exister sur le disque mais ne pas apparaître dans la liste des unités actives.

Gestion de l'état du système (cibles)

systemctl est également utilisé pour gérer les états globaux du système, principalement via des cibles.

1. Affichage de l'état actuel du système

Pour voir dans quelle cible le système a démarré (par exemple, environnement serveur ou bureau graphique) :

systemctl get-default

2. Modification de la cible de démarrage par défaut

Si vous configurez un serveur qui ne doit jamais lancer d'interface graphique, vous pouvez définir la cible par défaut sur multi-user.target :

sudo systemctl set-default multi-user.target

3. Redémarrage et arrêt

Bien que les commandes reboot et shutdown fonctionnent toujours, systemctl fournit la méthode native pour effectuer ces actions :

# Redémarrer le système immédiatement
sudo systemctl reboot

# Arrêter le système (mise hors tension)
sudo systemctl poweroff

Rechargement de systemd après des modifications d'unités

Lorsque vous modifiez un fichier d'unité ou ajoutez un fichier de remplacement sous /etc/systemd/system, systemd ne le relit pas automatiquement. Exécutez :

sudo systemctl daemon-reload

Puis redémarrez ou rechargez le service concerné :

sudo systemctl restart myapp.service

Pour inspecter l'unité finale après la fusion des fichiers fournisseur et des fichiers de remplacement :

systemctl cat myapp.service
systemctl show myapp.service -p FragmentPath -p DropInPaths

C'est l'un des moyens les plus rapides de détecter les problèmes du type « j'ai modifié le mauvais fichier ».

Un flux de dépannage réel

Lorsqu'un service ne démarre pas, travaillez dans cet ordre :

Vérifiez l'état :

systemctl status myapp.service

Lisez les journaux de cette unité :

journalctl -u myapp.service -r

Si vous avez récemment modifié le fichier de service, rechargez systemd :

sudo systemctl daemon-reload

Redémarrez-le et suivez les journaux en direct :

sudo systemctl restart myapp.service
journalctl -u myapp.service -f

S'il échoue immédiatement, vérifiez la définition de l'unité :

systemctl cat myapp.service
systemctl show myapp.service -p ExecStart -p User -p WorkingDirectory

La plupart des échecs sont ordinaires : mauvais chemin dans ExecStart, fichier d'environnement manquant, problème de permission, mauvais répertoire de travail, port déjà utilisé ou une erreur de syntaxe de configuration dans l'application elle-même.

Démarrer, Activer, Redémarrer, Recharger : Le modèle mental

Ces quatre verbes sont faciles à confondre :

start modifie l'état d'exécution actuel.
enable modifie le comportement au démarrage.
restart arrête et redémarre le processus.
reload demande au processus existant de relire la configuration, si le service le prend en charge.

Par exemple, après l'installation de Nginx :

sudo systemctl start nginx.service
sudo systemctl enable nginx.service

La première commande le démarre maintenant. La deuxième commande le fait démarrer après un redémarrage. Si vous exécutez uniquement start, le service peut disparaître après le prochain redémarrage. Si vous exécutez uniquement enable, il peut ne pas s'exécuter avant le prochain redémarrage, sauf si l'unité a un comportement d'installation spécial.

Après avoir modifié une configuration Nginx, testez d'abord la configuration de l'application, puis rechargez :

sudo nginx -t
sudo systemctl reload nginx.service

Si l'application ne prend pas en charge le rechargement, utilisez le redémarrage et planifiez l'interruption :

sudo systemctl restart myapp.service

Utilisation plus sûre du masquage

Le masquage est utile, mais il peut dérouter la personne suivante qui essaie de démarrer le service.

sudo systemctl mask bluetooth.service
systemctl is-enabled bluetooth.service

Le service signale masked. Pour annuler :

sudo systemctl unmask bluetooth.service

Utilisez le masquage pour des conflits clairs, comme empêcher un ancien service d'être démarré après l'avoir remplacé par un nouveau. Pour un comportement normal de « ne pas démarrer au démarrage », utilisez disable.

Modification des unités de manière maintenable

Lorsque vous devez modifier un service fourni par un paquet, évitez de modifier directement les fichiers sous /usr/lib/systemd/system ou /lib/systemd/system. Les mises à jour de paquets peuvent remplacer ces fichiers. Utilisez un fichier de remplacement :

sudo systemctl edit myapp.service

Cela crée un fichier de remplacement sous /etc/systemd/system/myapp.service.d/. Par exemple :

[Service]
Environment=APP_ENV=production
Restart=on-failure
RestartSec=5s

Appliquez-le ensuite :

sudo systemctl daemon-reload
sudo systemctl restart myapp.service

Si vous devez supprimer un fichier de remplacement ultérieurement, inspectez d'abord les fichiers de remplacement :

systemctl show myapp.service -p DropInPaths

Puis supprimez le fichier de remplacement spécifique et exécutez daemon-reload. Cela maintient les modifications locales visibles et plus faciles à auditer.

Services utilisateur

Tous les services ne sont pas des services système. Les outils de bureau, les démons de développement et les processus d'arrière-plan par utilisateur peuvent s'exécuter sous le gestionnaire utilisateur :

systemctl --user status pipewire.service
systemctl --user restart my-user-job.service

Les services utilisateur n'utilisent pas sudo de la même manière et vivent sous l'instance systemd de l'utilisateur. Si une commande fonctionne avec systemctl --user mais pas avec systemctl simple, vous avez affaire à une unité utilisateur, pas à une unité système.

Pour les services utilisateur de longue durée sur les serveurs, le comportement de connexion/session peut être important. Certaines distributions nécessitent le maintien en activité pour que les services d'un utilisateur continuent de s'exécuter après la déconnexion :

loginctl enable-linger deploy

Utilisez-le délibérément. Un service utilisateur peut être l'outil approprié pour le développement ou l'automatisation au niveau de l'utilisateur, mais les démons de production sont souvent plus clairs en tant que services système avec des utilisateurs et des permissions explicites.

Résumé des commandes systemctl essentielles

Action	Syntaxe de la commande	Objectif
Démarrer maintenant	`sudo systemctl start nom.service`	Exécute le service immédiatement.
Arrêter maintenant	`sudo systemctl stop nom.service`	Termine le service en cours d'exécution.
Redémarrer	`sudo systemctl restart nom.service`	Arrête puis démarre le service.
Recharger	`sudo systemctl reload nom.service`	Applique les modifications de configuration sans redémarrage complet, si pris en charge.
Activer	`sudo systemctl enable nom.service`	Configure le service pour qu'il démarre au démarrage.
Désactiver	`sudo systemctl disable nom.service`	Empêche le service de démarrer au démarrage.
État	`systemctl status nom.service`	Vérifie l'état d'exécution et les journaux récents.
Consulter les journaux	`journalctl -u nom.service`	Accède à l'historique complet du journal systemd pour le service.

Ces commandes couvrent la plupart des travaux quotidiens sur les services. Démarrer et arrêter contrôlent le processus actuel. Activer et désactiver contrôlent le comportement au démarrage. L'état, is-active et journalctl vous disent ce qui s'est passé. daemon-reload maintient systemd synchronisé avec les modifications des fichiers d'unité. Lorsque vous gardez ces rôles séparés, systemctl devient un outil de dépannage pratique plutôt qu'une commande que vous copiez à partir d'anciennes notes.