systemctl : gérer les services et unités systemd dans l’écosystème Linux

Sous Linux, systemctl joue un rôle central dans la gestion du système d’initialisation et du gestionnaire de services systemd. Avec systemctl, les utilisateurs ont le contrôle sur les services, unités et configurations systemd, ce qui en fait un outil indispensable pour l’administration système. De la gestion du démarrage à la personnalisation des états système, systemctl propose une gamme complète de fonctionnalités. À découvrir dans cet article !

Qu’est-ce que systemctl ?

systemctl est un outil en ligne de commande pour gérer systemd, un système d’initialisation et un gestionnaire de système pour les systèmes d’exploitation Linux. systemd est devenu le système d’initialisation par défaut de nombreuses distributions Linux ou distributions de serveurs Linux comme Ubuntu, Debian, Fedora, Red Hat Enterprise Linux (RHEL), CentOS, Arch Linux, Mageia ou Gentoo. Cet outil n’est cependant pas systématiquement implémenté dans toutes les distributions.

Dans l’écosystème systemd, systemctl joue un rôle central dans la gestion des services système, la configuration, le démarrage et la maintenance du système. Les fonctionnalités de cet outil vont au-delà du simple démarrage et de l’arrêt des services et offrent un contrôle complet sur presque tous les aspects d’un système Linux.

Dans ce tutoriel, vous trouverez des exemples de code pratiques, ainsi que des commandes Linux pour l’utilisation de systemctl sur la base d’Ubuntu 22.04.

Gestion des services

L’objectif premier du système d’initialisation est de lancer les composants nécessaires après le démarrage du noyau Linux (les composants userland). De plus, le système d’initialisation permet de contrôler efficacement les services et les démons sur un serveur à tout moment de l’exécution du système.

Dans systemd, la plupart des processus sont centrés sur ce que l’on appelle les unités (Units en anglais), qui sont des ressources gérées par systemd. Ces unités sont classées selon le type de ressource qu’elles représentent et sont définies par des fichiers d’unités. Le type d’une unité est identifiable par l’extension du fichier.

Pour la gestion des services, les unités de service se terminant par le suffixe .service sont particulièrement importantes. Souvent, il n’est cependant pas nécessaire d’indiquer ce suffixe pour les commandes de gestion de services, car systemd reconnaît généralement que ces commandes désignent des services.

Démarrer et arrêter des services

Parmi les tâches les plus courantes effectuées sous Linux avec systemctl, on retrouve le démarrage et l’arrêt de services. Ces fonctions sont fondamentales pour l’administration système et permettent de maintenir le contrôle sur les processus en cours d’exécution sur un système. Pour démarrer un service, utilisez la commande start. Si vous travaillez en tant qu’utilisateur sans privilèges root, vous devrez utiliser sudo :

$ sudo systemctl start application.service

Étant donné que systemd est conçu pour rechercher automatiquement les fichiers .service pour les commandes de gestion des services, la commande peut également être simplifiée :

$ sudo systemctl start application

Pour démarrer le serveur Web Apache, par exemple, vous entreriez :

$ sudo systemctl start apache2

Si vous souhaitez arrêter un service en cours, utilisez stop :

$ sudo systemctl stop application.service

Redémarrer et recharger

Pour redémarrer un service, ce qui est souvent nécessaire après un changement de configuration, utilisez la commande restart :

$ sudo systemctl restart application.service

Si l’application en question est capable de recharger ses fichiers de configuration sans redémarrer, la commande reload peut être utilisée pour initier ce processus :

$ sudo systemctl reload application.service

Si vous n’êtes pas certain qu’un service offre la possibilité de recharger sa configuration, vous pouvez utiliser la commande reload-or-restart. Celle-ci recharge la configuration, si cette option est prise en charge. Si cela n’est pas possible, la commande effectue à la place un redémarrage du service afin d’appliquer la configuration mise à jour.

$ sudo systemctl reload-or-restart application.service

Activer et désactiver des services

En activant et en désactivant des services, vous pouvez déterminer si un service doit être lancé automatiquement ou non au démarrage du système. Cela joue un rôle central, notamment pour les performances du système, la sécurité et la gestion des dépendances entre différents services. Pour configurer un service afin qu’il s’exécute automatiquement au démarrage du système, utilisez la commande enable :

$ sudo systemctl enable application.service

En exécutant ce processus, un lien symbolique est créé. Ce lien relie la copie du fichier de service système, qui se trouve généralement sous /lib/systemd/system ou /etc/systemd/system, au répertoire du disque dur dans lequel systemd recherche les fichiers pour le démarrage automatique, ce qui se fait généralement sous /etc/systemd/system/some_target.target.wants.

$ sudo systemctl enable application.service

Pour éviter qu’un service ne démarre automatiquement au démarrage, utilisez disable :

$ sudo systemctl disable application.service

Ceci supprime le lien symbolique qui indiquait auparavant que le service devait démarrer automatiquement. Attention : le simple fait d’activer un service ne le démarre pas immédiatement dans la session en cours. Pour démarrer le service immédiatement et le configurer pour qu’il démarre automatiquement au démarrage, vous devez exécuter à la fois les commandes start et enable.

Vérifier l’état des services

systemctl permet d’afficher des informations détaillées sur l’état des services. Cette fonction est particulièrement utile pour surveiller et diagnostiquer l’état actuel des services du système et des applications. Pour la vérification, utilisez la commande status :

$ systemctl status application.service

Cette commande fournit un ensemble d’informations comprenant l’état actuel du service (actif, inactif, en erreur, etc.), les derniers processus exécutés, les messages de log, la hiérarchie cgroup et les premières lignes des logs.

Pour vérifier l’état d’activité actuel d’un service sous Linux avec systemctl, on utilise is-active. Cette commande indique si un service est actuellement actif ou non :

$ systemctl is-active application.service

L’état actuel est généralement indiqué par active, si le service est actif, ou inactive, si le service est inactif.

Pour vérifier si un service est configuré de manière à être activé automatiquement au démarrage du système, vous pouvez utiliser la commande is-enabled. Ceci est particulièrement utile pour gérer la configuration de démarrage des services sur un système Linux.

$ systemctl is-enabled application.service

La commande indique si le service est activé ou désactivé et définit en conséquence le code de sortie à « 0 » ou « 1 », en fonction de la réponse.

La commande is-failed permet de vérifier si un certain service présente un statut d’erreur :

$ systemctl is-failed application.service

Si l’exécution a réussi, active est affiché, failed dans le cas contraire. Si l’unité a été volontairement arrêtée, unknown ou inactive peut apparaître comme réponse. Un état de sortie 0 signale l’apparition d’une erreur, tandis que 1 indique tout autre état.

Aperçu de l’état du système

Les commandes présentées jusqu’à présent se sont concentrées sur la gestion de services individuels, mais elles ne donnent pas un aperçu complet de l’état actuel du système. Il existe cependant un grand nombre de commandes systemctl qui fournissent précisément ce type d’informations.

list-units est un outil utile pour obtenir une vue d’ensemble des unités actuelles sur Linux :

$ systemctl list-units

Lorsque vous exécutez cette commande, systemctl affiche une liste d’unités que systemd gère. La sortie de cette liste contient différentes colonnes avec des informations spécifiques sur chaque unité. Ces colonnes sont affichées :

• UNIT : le nom de l’unité, souvent le nom de fichier du fichier d’unité correspondant, par exemple sshd.service pour le démon SSH.
• LOAD : indique si le fichier d’unité a été chargé avec succès ; les valeurs possibles sont loaded, not-found ou error.
• ACTIVE : l’état d’activité de l’unité ; celui-ci peut prendre des valeurs telles que active, inactive, activating ou deactivating.
• SUB : l’état d’activité subordonné, qui donne plus de détails sur l’état de l’unité ; par exemple, une unité active pourrait avoir un état SUB de running, exited ou failed.
• DESCRIPTION : une brève description de l’unité, qui reflète souvent l’objectif ou la fonctionnalité de l’unité

Toutefois, la commande n’affiche par défaut que les unités actives, c’est pourquoi dans la sortie, la colonne LOAD indique typiquement loaded et la colonne ACTIVE active. Avec des indicateurs supplémentaires, systemctl peut être configuré pour afficher des informations avancées. Par exemple, pour afficher toutes les unités chargées par systemd, quel que soit leur état d’activité actuel, utilisez le drapeau --all :

$ systemctl list-units --all

La sortie peut être encore affinée en utilisant des indicateurs supplémentaires comme --state= pour filtrer des états spécifiques dans les catégories LOAD, ACTIVE ou SUB. Il est important de conserver le drapeau --all pour que les unités inactives soient également affichées :

$ systemctl list-units --all --state=inactive

Avec le filtre --type=, vous pouvez n’afficher que certains types d’unités, pour ne voir par exemple que les unités de service actives :

$ systemctl list-units --type=service

Lister tous les fichiers d’unité

Pour afficher une liste de tous les fichiers unitaires disponibles sur Linux avec systemctl (y compris ceux que systemd n’a pas essayé de charger), vous pouvez utiliser list-unit-files. Cette commande affiche tous les fichiers d’unité connus de systemd, couvrant les services, les sockets, les cibles (targets) et plus encore.

$ systemctl list-units-files

La commande affiche différents états des fichiers d’unités (unit files). Ces états indiquent comment les unités respectives sont configurées, en particulier en ce qui concerne leur comportement au démarrage du système. Les états les plus courants sont :

• Enabled : l’unité est configurée de manière à être activée automatiquement au démarrage du système.
• Disabled : l’unité n’est pas configurée pour démarrer automatiquement au démarrage.
• Masked : l’unité est complètement désactivée, de sorte qu’elle ne peut pas être démarrée manuellement ou automatiquement.
• Static : l’unité n’est pas lancée de manière autonome, mais dépend typiquement d’une autre unité et n’est lancée que dans ce contexte.

Gestion des unités

La gestion des unités est l’une des tâches principales de systemctl. Pour obtenir des informations plus spécifiques sur des unités individuelles et les gérer, systemctl propose une série de commandes et d’options utiles.

Afficher un fichier d’unité

La commande cat permet d’afficher le contenu d’un fichier d’unités spécifique directement dans la console. Par exemple, pour voir le fichier d’unité d’un service tel que ssh.service, entrez :

$ systemctl cat ssh.service

Afficher les dépendances

Les dépendances d’une unité donnée peuvent être affichées sous forme d’arborescence grâce à list-dependencies. La commande se présente comme suit :

$ systemctl list-dependencies sshd.service

Par défaut, les dépendances sont affichées pour les unités .target, qui représentent différents états du système. Pour une liste complète et récursive de toutes les dépendances, utilisez le drapeau --all.

Pour afficher les dépendances inverses, c’est-à-dire les unités qui dépendent de celle qui est spécifiée, ajoutez --reverse à la commande. De plus, les indicateurs --before et --after permettent de voir les dépendances qui commencent avant et après l’unité en question.

Masquer et démasquer des unités

Le masquage d’une unité la désactive effectivement, de sorte qu’elle ne puisse pas être démarrée manuellement ou automatiquement. Cela est souvent utilisé pour s’assurer qu’un service ou une unité ne soit pas démarré accidentellement ou automatiquement par des dépendances. Le masquage s’effectue en créant un lien symbolique du fichier d’unité concerné vers /dev/null avec la commande mask :

$ sudo systemctl mask nginx.service

Cela permet de s’assurer que le service Nginx, tant qu’il est en mode masqué, ne peut pas être lancé manuellement ou automatiquement.

Démasquer annule l’état de masquage d’une unité afin qu’elle puisse à nouveau être démarrée normalement. La commande de démasquage est unmask :

$ sudo systemctl unmask nginx.service

Modifier les fichiers d’unités

systemctl dispose d’options permettant d’adapter et de modifier les fichiers unitaires. Cette capacité a été introduite avec la version 218 de systemd. Lorsque vous utilisez la commande edit, un fichier d’unité de l’unité sélectionnée est automatiquement ouvert pour être modifié :

$ sudo systemctl edit nginx.service

Lors de l’édition, un fichier vide est créé pour ajouter ou modifier des instructions spécifiques à une définition d’unité. Pour chaque unité, par exemple nginx.service, un sous-dossier est créé dans le répertoire /etc/systemd/system, qui porte le nom du fichier suivi de .d - donc dans ce cas nginx.service.d.

Le fichier override.conf est créé dans ce sous-dossier. Lorsque systemd charge l’unité, il combine le contenu de ce fichier snippet avec le fichier d’unité original, en donnant la priorité aux instructions du snippet. Pour traiter l’ensemble du fichier d’unité, on peut utiliser le drapeau --full :

$ sudo systemctl edit --full nginx.service

--full permet d’ouvrir le fichier d’unité existant dans un éditeur afin d’y apporter des modifications. En quittant l’éditeur, le système enregistre le fichier modifié dans /etc/systemd/system.

Pour annuler les modifications que vous avez vous-même effectuées, vous pouvez soit supprimer le répertoire de configuration .d de l’unité, soit le fichier modifié dans /etc/systemd/system :

$ sudo rm -r /etc/systemd/system/nginx.service.d

Un fichier d’unité entièrement révisé est supprimé avec la commande suivante :

$ sudo rm /etc/systemd/system/nginx.service

Après avoir supprimé le fichier ou le répertoire, il est nécessaire de recharger systemd pour qu’il cesse de faire référence aux fichiers supprimés et revienne à la place à la copie native :

$ sudo systemctl daemon-reload

Personnalisation de l’état du système (runlevel) avec des objectifs

Dans systemd, les cibles sont principalement utilisées pour regrouper différentes unités en vue d’atteindre des états spécifiques du système, de manière similaire aux niveaux d’exécution (runlevel) dans d’autres systèmes init. Les fichiers portant l’extension .target agissent comme des points de repère indiquant l’état de disponibilité de certaines fonctionnalités, et permettant ainsi aux utilisateurs de spécifier l’état global souhaité plutôt que les différentes unités nécessaires.

Un exemple concret est la swap.target, qui représente l’état de préparation de l’espace d’échange. Les unités impliquées dans le processus d’échange peuvent être alignées sur cette cible à l’aide d’options de configuration telles que WantedBy= ou RequiredBy=. D’autre part, les unités qui dépendent de l’espace d’échange peuvent le marquer à l’aide de paramètres tels que Wants=, Requires= et After=, afin d’exprimer leur dépendance et leur ordre de démarrage par rapport à l’espace d’échange.

Récupérer et configurer la destination par défaut

La récupération et la configuration de la cible par défaut permettent de définir un état par défaut du système que votre système doit atteindre au démarrage. Voici comment trouver la destination par défaut de votre système :

$ systemctl get-default
Output
multi-user.target

Si vous voulez changer la cible par défaut, utilisez la commande set-default avec le nom de la cible. La commande suivante permet de définir la cible par défaut sur graphical.target, ce qui lance une interface utilisateur graphique :

$ sudo systemctl set-default graphical.target

Lister les cibles disponibles

Pour lister toutes les cibles disponibles sur votre système, vous pouvez utiliser la commande suivante :

$ systemctl list-unit-files --type=target

Cela affiche une liste de tous les fichiers d’unité cible installés sur votre système. Pour chaque cible, le chemin d’accès et l’état actuel (par exemple : activé ou désactivé) sont affichés.

Isoler les objectifs

isolate permet d’activer toutes les unités liées à une cible donnée et d’arrêter simultanément toutes les autres unités qui ne lui sont pas liées.

Supposons que vous travaillez dans un environnement où graphical.target est actif et que vous souhaitiez passer à un mode purement multi-utilisateurs sans interface graphique. Dans ce cas, vous pouvez désactiver le système graphique en isolant le multi-user.target. Comme graphical.target dépend de multi-user.target, mais pas l’inverse, tous les services graphiques sont arrêtés lors du changement.

Toutefois, avant d’isoler une cible, il convient de vérifier les dépendances qui lui sont associées. Vous éviterez ainsi l’arrêt involontaire de processus importants.

$ systemctl list-dependencies multi-user.target

Si vous avez vérifié les unités actives que vous souhaitez conserver et que vous êtes d’accord, vous pouvez isoler la cible souhaitée :

$ sudo systemctl isolate multi-user.target

Utiliser des raccourcis pour les événements importants

Il existe des cibles spécifiques pour les opérations essentielles telles que l’arrêt ou le redémarrage du système. Cependant, sous Linux, systemctl propose également des raccourcis pratiques qui fournissent des fonctions supplémentaires. Par exemple, pour mettre le système en mode de sauvetage (mode mono-utilisateur), vous pouvez simplement utiliser rescue au lieu de isolate rescue.target :

$ sudo systemctl rescue

Vous pouvez arrêter le système avec halt :

$ sudo systemctl halt

Vous pouvez déclencher un arrêt complet avec poweroff :

$ sudo systemctl poweroff

Avec reboot, en revanche, vous lancez un redémarrage :

$ sudo systemctl reboot

Ces commandes informent les utilisateurs connectés des événements à venir, ce qui n’est pas obtenu en exécutant simplement ou en isolant la cible. Il est important de noter que de nombreux ordinateurs associent les commandes les plus courtes pour ces actions à systemd afin de garantir une exécution correcte.

Pour un redémarrage du système, par exemple, la commande suivante est généralement suffisante :

$ sudo reboot