systemctl : gérer les services et unités systemd dans l’éco­sys­tème Linux

Sous Linux, systemctl joue un rôle central dans la gestion du système d’ini­tia­li­sa­tion et du ges­tion­naire de services systemd. Avec systemctl, les uti­li­sa­teurs ont le contrôle sur les services, unités et con­fi­gu­ra­tions systemd, ce qui en fait un outil in­dis­pen­sable pour l’ad­mi­nis­tra­tion système. De la gestion du démarrage à la per­son­na­li­sa­tion des états système, systemctl propose une gamme complète de fonc­tion­na­li­té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’ini­tia­li­sa­tion et un ges­tion­naire de système pour les systèmes d’ex­ploi­ta­tion Linux. systemd est devenu le système d’ini­tia­li­sa­tion par défaut de nom­breuses dis­tri­bu­tions Linux ou dis­tri­bu­tions de serveurs Linux comme Ubuntu, Debian, Fedora, Red Hat En­ter­prise Linux (RHEL), CentOS, Arch Linux, Mageia ou Gentoo. Cet outil n’est cependant pas sys­té­ma­ti­que­ment im­plé­menté dans toutes les dis­tri­bu­tions.

Dans l’éco­sys­tème systemd, systemctl joue un rôle central dans la gestion des services système, la con­fi­gu­ra­tion, le démarrage et la main­te­nance du système. Les fonc­tion­na­li­té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’uti­li­sa­tion de systemctl sur la base d’Ubuntu 22.04.

Gestion des services

L’objectif premier du système d’ini­tia­li­sa­tion est de lancer les com­po­sants né­ces­saires après le démarrage du noyau Linux (les com­po­sants userland). De plus, le système d’ini­tia­li­sa­tion permet de contrôler ef­fi­ca­ce­ment 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 res­sources gérées par systemd. Ces unités sont classées selon le type de ressource qu’elles re­pré­sen­tent et sont définies par des fichiers d’unités. Le type d’une unité est iden­ti­fiable par l’extension du fichier.

Pour la gestion des services, les unités de service se terminant par le suffixe .service sont par­ti­cu­liè­re­ment im­por­tantes. Souvent, il n’est cependant pas né­ces­saire d’indiquer ce suffixe pour les commandes de gestion de services, car systemd reconnaît gé­né­ra­le­ment que ces commandes désignent des services.

Démarrer et arrêter des services

Parmi les tâches les plus courantes ef­fec­tuées sous Linux avec systemctl, on retrouve le démarrage et l’arrêt de services. Ces fonctions sont fon­da­men­tales pour l’ad­mi­nis­tra­tion système et per­met­tent 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 tra­vail­lez en tant qu’uti­li­sa­teur sans pri­vi­lèges root, vous devrez utiliser sudo :

$ sudo systemctl start application.service

Étant donné que systemd est conçu pour re­cher­cher au­to­ma­ti­que­ment les fichiers .service pour les commandes de gestion des services, la commande peut également être sim­pli­fié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

Re­dé­mar­rer et recharger

Pour re­dé­mar­rer un service, ce qui est souvent né­ces­saire après un chan­ge­ment de con­fi­gu­ra­tion, utilisez la commande restart :

$ sudo systemctl restart application.service

Si l’ap­pli­ca­tion en question est capable de recharger ses fichiers de con­fi­gu­ra­tion sans re­dé­mar­rer, 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 pos­si­bi­lité de recharger sa con­fi­gu­ra­tion, vous pouvez utiliser la commande reload-or-restart. Celle-ci recharge la con­fi­gu­ra­tion, si cette option est prise en charge. Si cela n’est pas possible, la commande effectue à la place un re­dé­mar­rage du service afin d’appliquer la con­fi­gu­ra­tion mise à jour.

$ sudo systemctl reload-or-restart application.service

Activer et dé­sac­ti­ver des services

En activant et en dé­sac­ti­vant des services, vous pouvez dé­ter­mi­ner si un service doit être lancé au­to­ma­ti­que­ment ou non au démarrage du système. Cela joue un rôle central, notamment pour les per­for­mances du système, la sécurité et la gestion des dé­pen­dances entre dif­fé­rents services. Pour con­fi­gu­rer un service afin qu’il s’exécute au­to­ma­ti­que­ment au démarrage du système, utilisez la commande enable :

$ sudo systemctl enable application.service

En exécutant ce processus, un lien sym­bo­lique est créé. Ce lien relie la copie du fichier de service système, qui se trouve gé­né­ra­le­ment sous /lib/systemd/system ou /etc/systemd/system, au ré­per­toire du disque dur dans lequel systemd recherche les fichiers pour le démarrage au­to­ma­tique, ce qui se fait gé­né­ra­le­ment sous /etc/systemd/system/some_target.target.wants.

$ sudo systemctl enable application.service

Pour éviter qu’un service ne démarre au­to­ma­ti­que­ment au démarrage, utilisez disable :

$ sudo systemctl disable application.service

Ceci supprime le lien sym­bo­lique qui indiquait au­pa­ra­vant que le service devait démarrer au­to­ma­ti­que­ment. Attention : le simple fait d’activer un service ne le démarre pas im­mé­dia­te­ment dans la session en cours. Pour démarrer le service im­mé­dia­te­ment et le con­fi­gu­rer pour qu’il démarre au­to­ma­ti­que­ment 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 in­for­ma­tions dé­tail­lées sur l’état des services. Cette fonction est par­ti­cu­liè­re­ment utile pour sur­veil­ler et diag­nos­ti­quer l’état actuel des services du système et des ap­pli­ca­tions. Pour la vé­ri­fi­ca­tion, utilisez la commande status :

$ systemctl status application.service

Cette commande fournit un ensemble d’in­for­ma­tions com­pre­nant l’état actuel du service (actif, inactif, en erreur, etc.), les derniers processus exécutés, les messages de log, la hié­rar­chie 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 ac­tuel­le­ment actif ou non :

$ systemctl is-active application.service

L’état actuel est gé­né­ra­le­ment 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é au­to­ma­ti­que­ment au démarrage du système, vous pouvez utiliser la commande is-enabled. Ceci est par­ti­cu­liè­re­ment utile pour gérer la con­fi­gu­ra­tion 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 con­sé­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é vo­lon­tai­re­ment arrêtée, unknown ou inactive peut ap­pa­raître comme réponse. Un état de sortie 0 signale l’ap­pa­ri­tion d’une erreur, tandis que 1 indique tout autre état.

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

Les commandes pré­sen­tées jusqu’à présent se sont con­cen­trées sur la gestion de services in­di­vi­duels, 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 four­nis­sent pré­ci­sé­ment ce type d’in­for­ma­tions.

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 dif­fé­rentes colonnes avec des in­for­ma­tions spé­ci­fiques sur chaque unité. Ces colonnes sont affichées :

• UNIT : le nom de l’unité, souvent le nom de fichier du fichier d’unité cor­res­pon­dant, 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é su­bor­donné, 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.
• DES­CRIP­TION : une brève des­crip­tion de l’unité, qui reflète souvent l’objectif ou la fonc­tion­na­lité 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 ty­pi­que­ment loaded et la colonne ACTIVE active. Avec des in­di­ca­teurs sup­plé­men­taires, systemctl peut être configuré pour afficher des in­for­ma­tions 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 in­di­ca­teurs sup­plé­men­taires comme --state= pour filtrer des états spé­ci­fiques dans les ca­té­go­ries 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 dis­po­nibles 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 dif­fé­rents états des fichiers d’unités (unit files). Ces états indiquent comment les unités res­pec­tives sont con­fi­gu­rées, en par­ti­cu­lier en ce qui concerne leur com­por­te­ment au démarrage du système. Les états les plus courants sont :

• Enabled : l’unité est con­fi­gu­rée de manière à être activée au­to­ma­ti­que­ment au démarrage du système.
• Disabled : l’unité n’est pas con­fi­gu­rée pour démarrer au­to­ma­ti­que­ment au démarrage.
• Masked : l’unité est com­plè­te­ment dé­sac­ti­vée, de sorte qu’elle ne peut pas être démarrée ma­nuel­le­ment ou au­to­ma­ti­que­ment.
• Static : l’unité n’est pas lancée de manière autonome, mais dépend ty­pi­que­ment 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 prin­ci­pales de systemctl. Pour obtenir des in­for­ma­tions plus spé­ci­fiques sur des unités in­di­vi­duelles 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é­ci­fique di­rec­te­ment 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é­pen­dances

Les dé­pen­dances d’une unité donnée peuvent être affichées sous forme d’ar­bo­res­cence grâce à list-dependencies. La commande se présente comme suit :

$ systemctl list-dependencies sshd.service

Par défaut, les dé­pen­dances sont affichées pour les unités .target, qui re­pré­sen­tent dif­fé­rents états du système. Pour une liste complète et récursive de toutes les dé­pen­dances, utilisez le drapeau --all.

Pour afficher les dé­pen­dances inverses, c’est-à-dire les unités qui dépendent de celle qui est spécifiée, ajoutez --reverse à la commande. De plus, les in­di­ca­teurs --before et --after per­met­tent de voir les dé­pen­dances qui com­men­cent avant et après l’unité en question.

Masquer et démasquer des unités

Le masquage d’une unité la désactive ef­fec­ti­ve­ment, de sorte qu’elle ne puisse pas être démarrée ma­nuel­le­ment ou au­to­ma­ti­que­ment. Cela est souvent utilisé pour s’assurer qu’un service ou une unité ne soit pas démarré ac­ci­den­tel­le­ment ou au­to­ma­ti­que­ment par des dé­pen­dances. Le masquage s’effectue en créant un lien sym­bo­lique 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é ma­nuel­le­ment ou au­to­ma­ti­que­ment.

Démasquer annule l’état de masquage d’une unité afin qu’elle puisse à nouveau être démarrée nor­ma­le­ment. La commande de dé­mas­quage est unmask :

$ sudo systemctl unmask nginx.service

Modifier les fichiers d’unités

systemctl dispose d’options per­met­tant d’adapter et de modifier les fichiers unitaires. Cette capacité a été in­tro­duite avec la version 218 de systemd. Lorsque vous utilisez la commande edit, un fichier d’unité de l’unité sé­lec­tion­née est au­to­ma­ti­que­ment ouvert pour être modifié :

$ sudo systemctl edit nginx.service

Lors de l’édition, un fichier vide est créé pour ajouter ou modifier des ins­truc­tions spé­ci­fiques à une dé­fi­ni­tion d’unité. Pour chaque unité, par exemple nginx.service, un sous-dossier est créé dans le ré­per­toire /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 ins­truc­tions 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 mo­di­fi­ca­tions. En quittant l’éditeur, le système en­re­gistre le fichier modifié dans /etc/systemd/system.

Pour annuler les mo­di­fi­ca­tions que vous avez vous-même ef­fec­tuées, vous pouvez soit supprimer le ré­per­toire de con­fi­gu­ra­tion .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é en­tiè­re­ment révisé est supprimé avec la commande suivante :

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

Après avoir supprimé le fichier ou le ré­per­toire, il est né­ces­saire 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

Per­son­na­li­sa­tion de l’état du système (runlevel) avec des objectifs

Dans systemd, les cibles sont prin­ci­pa­le­ment utilisées pour regrouper dif­fé­rentes unités en vue d’atteindre des états spé­ci­fiques 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 dis­po­ni­bi­lité de certaines fonc­tion­na­li­tés, et per­met­tant ainsi aux uti­li­sa­teurs de spécifier l’état global souhaité plutôt que les dif­fé­rentes unités né­ces­saires.

Un exemple concret est la swap.target, qui re­pré­sente l’état de pré­pa­ra­tion de l’espace d’échange. Les unités im­pli­quées dans le processus d’échange peuvent être alignées sur cette cible à l’aide d’options de con­fi­gu­ra­tion 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 pa­ra­mètres tels que Wants=, Requires= et After=, afin d’exprimer leur dé­pen­dance et leur ordre de démarrage par rapport à l’espace d’échange.

Récupérer et con­fi­gu­rer la des­ti­na­tion par défaut

La ré­cu­pé­ra­tion et la con­fi­gu­ra­tion de la cible par défaut per­met­tent de définir un état par défaut du système que votre système doit atteindre au démarrage. Voici comment trouver la des­ti­na­tion 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 uti­li­sa­teur graphique :

$ sudo systemctl set-default graphical.target

Lister les cibles dis­po­nibles

Pour lister toutes les cibles dis­po­nibles 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 si­mul­ta­né­ment toutes les autres unités qui ne lui sont pas liées.

Supposons que vous tra­vail­lez dans un en­vi­ron­ne­ment où graphical.target est actif et que vous sou­hai­tiez passer à un mode purement multi-uti­li­sa­teurs sans interface graphique. Dans ce cas, vous pouvez dé­sac­ti­ver 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 gra­phiques sont arrêtés lors du chan­ge­ment.

Toutefois, avant d’isoler une cible, il convient de vérifier les dé­pen­dances qui lui sont associées. Vous éviterez ainsi l’arrêt in­vo­lon­taire de processus im­por­tants.

$ 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 rac­cour­cis pour les évé­ne­ments im­por­tants

Il existe des cibles spé­ci­fiques pour les opé­ra­tions es­sen­tielles telles que l’arrêt ou le re­dé­mar­rage du système. Cependant, sous Linux, systemctl propose également des rac­cour­cis pratiques qui four­nis­sent des fonctions sup­plé­men­taires. Par exemple, pour mettre le système en mode de sauvetage (mode mono-uti­li­sa­teur), vous pouvez sim­ple­ment 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é­clen­cher un arrêt complet avec poweroff :

$ sudo systemctl poweroff

Avec reboot, en revanche, vous lancez un re­dé­mar­rage :

$ sudo systemctl reboot

Ces commandes informent les uti­li­sa­teurs connectés des évé­ne­ments à venir, ce qui n’est pas obtenu en exécutant sim­ple­ment ou en isolant la cible. Il est important de noter que de nombreux or­di­na­teurs associent les commandes les plus courtes pour ces actions à systemd afin de garantir une exécution correcte.

Pour un re­dé­mar­rage du système, par exemple, la commande suivante est gé­né­ra­le­ment suf­fi­sante :

$ sudo reboot