Accéder au contenuNavigation Accéder à la page : page précédente [raccourci clavier p] / page suivante [raccourci clavier n]
documentation.suse.com / Présentation des principes de base de systemd

Présentation des principes de base de systemd

Date de publication : 12 déc 2024
CONTENU

systemd permet de gérer les services et les paramètres système. systemd organise les tâches en composants appelés unités et les groupes d'unités en cibles.

MOTIF

Découvrez les bases de systemd, notamment les fonctionnalités essentielles telles que la gestion des services, le suivi des dépendances, la consignation, la gestion des ressources, l'activation des sockets et le contrôle du système.

EFFORT

La lecture de cet article vous prendra 20 minutes.

CONDITIONS REQUISES

  • Compréhension de base des commandes Linux

  • Connaissances de base des processus, daemons et groupes de contrôle Linux

1 Présentation de systemd

 

systemd est un gestionnaire de systèmes et de services pour les systèmes d'exploitation Linux. Il s'agit du système d'initialisation par défaut pour les principales distributions Linux. systemd n'est pas directement lancé par l'utilisateur, mais installé via /sbin/init et démarré lors de la première phase d'initialisation. systemd agit en tant que système d'initialisation qui active et gère les services d'espace utilisateur lorsqu'il est exécuté en tant que premier processus au démarrage (PID 1). Le PID 1 est appelé init et est le premier processus créé en mode utilisateur Linux. Il s'exécute jusqu'à l'arrêt du système.

systemd est propriétaire du PID 1 et est démarré directement par le kernel. Tous les autres processus sont démarrés directement par systemd ou l'un de ses processus enfants. systemd monte le système de fichiers de l'hôte et gère les fichiers temporaires. Il est compatible avec les scripts d'initialisation SysV. SysV est un système d'initialisation antérieur à systemd.

Dans systemd, une unité est une ressource que le système sait utiliser et gérer. Il s'agit de l'objet principal utilisé par les outils systemd. Ces ressources sont définies avec des fichiers de configuration appelés fichiers d'unité.

systemctl est l'outil de gestion central qui contrôle le système d'initialisation. Il permet d'examiner et de contrôler l'état du gestionnaire du système et des services systemd.

Dans systemd, les cibles sont des groupes d'unités associées qui agissent comme des points de synchronisation lors du démarrage du système. Les fichiers d'unité cibles ont une extension .target. Les unités cibles regroupent diverses unités systemd par le biais d'une chaîne de dépendances.

Pour le dépannage, vous pouvez utiliser journalctl qui permet d'interroger et d'afficher les messages à partir du journal systemd.

Pour plus d'informations sur systemd, consultez le site https://systemd.io et la page man 1 systemd.

2 À propos du processus de démarrage systemd

 

La première étape du processus de démarrage consiste à charger le kernel Linux, qui est le composant principal du système d'exploitation Linux. Une fois le kernel chargé, il initialise le matériel et démarre le processus systemd qui est le premier processus exécuté sur le système.

2.1 Processus de démarrage Linux

 

Le processus de démarrage Linux est la phase initiale du démarrage du système d'exploitation. Il s'agit du processus lors duquel le système d'exploitation charge la mémoire, initialise les composants et se prépare à exécuter des applications utilisateur.

Le processus de démarrage Linux est divisé en quatre phases principales :

Phase 1 : BIOS

Lorsque vous mettez votre ordinateur sous tension, votre ordinateur démarre le BIOS (Basic Input/Output System) et effectue un test d'autodiagnostic POST (Power On Self Test). Il s'agit d'une vérification d'intégrité qui examine la fonctionnalité matérielle des composants tels que les disques durs, les disques SSD, le clavier, la mémoire RAM, les ports USB et tout autre matériel. Si le matériel fonctionne comme prévu, le processus de démarrage passe à la phase suivante.

Phase 2 : le chargeur de démarrage

Une fois le test d'autodiagnostic POST terminé, le BIOS recherche et charge le programme du chargeur de démarrage stocké dans le MBR (Master Boot Record). Le MBR est un code de 512 octets qui se trouve généralement à l'emplacement /dev/sda ou /dev/hda en fonction de l'architecture de votre disque dur. Le MBR peut également être situé sur une installation USB ou DVD de Linux en direct. Le BIOS charge et exécute ce code MBR.

Il existe trois principaux chargeurs de démarrage sous Linux : LILO, GRUB et GRUB2. Le chargeur de démarrage GRUB2 (Grand Unified Bootloader) est le dernier chargeur de démarrage principal des distributions Linux modernes. Le fichier de configuration de GRUB2 est situé à l'emplacement /boot/grub2/grub2.cfg. Une fois que le BIOS a localisé le chargeur de démarrage GRUB2, il l'exécute et le charge dans la mémoire principale (RAM).

Phase 3 : initialisation du kernel Linux

Le kernel Linux est au coeur du système d'exploitation. Dans votre système Linux, le kernel s'interface avec le matériel, contrôle la gestion de la mémoire et gère les processus. Le chargeur de démarrage charge le kernel Linux sélectionné. Le kernel s'extrait automatiquement d'une version compressée et monte le système de fichiers racine. Il exécute ensuite le programme /sbin/init.

Phase 4 : systemd

Le kernel charge systemd, à savoir un gestionnaire de systèmes et de services pour les systèmes d'exploitation Linux. systemd exécute ensuite tous les autres processus d'initialisation.

2.2 Processus de démarrage avec systemd

 

Une fois que le kernel charge systemd, systemd prend le relais et démarre les autres services système requis pour que le système soit opérationnel. Cela inclut des services tels que le service de mise en réseau, le gestionnaire de connexion, etc.

Le processus de démarrage est parallélisé dans l'ordre d'exécution des unités cibles spécifiques. systemd utilise le fichier /etc/systemd/system/default.target pour déterminer la cible dans laquelle le système Linux doit démarrer. Ce fichier est un lien vers graphical.target lequel démarre le gestionnaire de connexion graphique. systemd active toutes les unités cibles qui sont des dépendances de default.target, ainsi que toutes les dépendances de ces dépendances. Une fois tous les services démarrés, votre système est prêt à être utilisé et le gestionnaire de connexion s'affiche. Vous pouvez maintenant vous connecter et commencer à utiliser le système.

2.3 Analyse des performances du processus de démarrage du système avec la commande systemd-analyze

 

La commande systemd-analyze permet d'analyser les performances du processus de démarrage du système. La commande peut également servir à récupérer d'autres informations d'état et de traçage à partir du gestionnaire du système et des services. Elle permet de vérifier que les fichiers d'unité sont corrects et d'accéder à des fonctions spéciales utiles pour le débogage avancé du gestionnaire système.

Voici quelques exemples :

Affichage du temps nécessaire au démarrage du système 
> systemd-analyze time
Startup finished in 3.404s (kernel) + 2.415s (initrd) + 13.125s (userspace) = 18.945s
graphical.target reached after 13.117s in userspace
Obtention d'une vue d'ensemble du processus de démarrage, qui comprend les services démarrés et le temps nécessaire au démarrage de chaque service 
> systemd-analyze critical-chain
  The time when unit became active or started is printed after the "@" character.
  The time the unit took to start is printed after the "+" character.

  graphical.target @13.117s
  └─multi-user.target @13.117s
    └─getty.target @13.117s
      └─getty@tty1.service @13.116s
        └─plymouth-quit-wait.service @10.775s +2.338s
          └─systemd-user-sessions.service @10.769s +3ms
            └─remote-fs.target @10.764s
              └─iscsi.service @10.747s +16ms
                └─network-online.target @10.744s
                  └─NetworkManager-wait-online.service @1.547s +9.197s
                    └─NetworkManager.service @1.507s +37ms
                      └─network-pre.target @1.504s
                        └─wpa_supplicant.service @2.341s +5ms
                          └─dbus.service @1.042s
                            └─basic.target @1.036s
                              └─sockets.target @1.036s
                                └─snapd.socket @1.035s +590us
                                  └─sysinit.target @1.030s
                                    └─systemd-update-utmp.service @1.025s +5ms
                                      └─auditd.service @976ms +47ms
                                        └─systemd-tmpfiles-setup.service @964ms +9ms
                                          └─local-fs.target @962ms
                                            └─snapd.mounts.target @961ms
                                              └─snap-core18-2796.mount @417ms +543ms
                                                └─dev-loop9.device @961ms +628us

Cette commande imprime une arborescence d'unités critiques pour chacune des unités spécifiées ou pour la cible par défaut. L'initialisation des services peut dépendre de l'activation du socket et de l'exécution des unités en parallèle. Semblable à la commande blame, elle affiche le temps nécessaire à une unité pour s'activer, qui n'est pas défini pour les unités telles que les unités de périphérique qui passent directement à l'état actif.

Affichage d'une liste de services lancés au cours du processus de démarrage et affichés en fonction du temps nécessaire à chaque service 
> systemd-analyze blame
  9.197s NetworkManager-wait-online.service
  4.002s fwupd.service
  2.338s plymouth-quit-wait.service
  1.282s dracut-pre-udev.service
  1.062s sys-devices-platform-serial8250-tty-ttyS0.device
  1.062s dev-ttyS0.device
  1.061s dev-ttyS1.device
  1.061s sys-devices-platform-serial8250-tty-ttyS1.device
  1.060s dev-ttyS11.device
  1.060s sys-devices-platform-serial8250-tty-ttyS11.device
  1.059s sys-devices-platform-serial8250-tty-ttyS13.device
  1.059s dev-ttyS13.device
  1.059s sys-devices-platform-serial8250-tty-ttyS10.device
  1.059s dev-ttyS10.device
  1.058s sys-devices-platform-serial8250-tty-ttyS14.device
  1.058s dev-ttyS14.device
  1.058s dev-ttyS12.device
  1.058s sys-devices-platform-serial8250-tty-ttyS12.device
  1.056s sys-devices-platform-serial8250-tty-ttyS17.device

L'initialisation d'un service peut prendre du temps, car il doit attendre qu'une autre initialisation se termine. La commande affiche le temps nécessaire à une unité pour s'activer, mais n'indique pas cette durée pour des unités telles que des périphériques qui passent directement à l'état actif. Cette commande n'affiche pas les résultats pour les services avec Type=simple, car systemdconsidère que ces services sont démarrés immédiatement, par conséquent les délais d'initialisation ne peuvent pas être analysés.

Génération d'un fichier graphique vectoriel qui affiche les événements qui se produisent pendant le processus de démarrage 
> systemd-analyze plot > /temp/sample.svg

Cette commande crée un fichier SVG dans le répertoire temp. Le fichier SVG est un fichier texte qui définit un ensemble de vecteurs graphiques que les applications telles que LibreOffice Draw utilisent pour générer un graphique.

3 Structure d'un fichier d'unité

 

Dans systemd, une unité fait référence à toute ressource que le système sait faire fonctionner et gérer. Il s'agit de l'objet principal utilisé par les outils systemd. Ces ressources sont définies à l'aide de fichiers de configuration appelés fichiers d'unité. Lorsque vous utilisez systemd, l'administration est simplifiée lorsque vous comprenez les fichiers d'unité. Les fichiers d'unité utilisent une syntaxe déclarative simple qui vous permet de voir facilement l'objectif et les effets d'une unité lors de son activation. Les fichiers d'unité présentent des sections avec des directives, par exemple : 

[Section]
        Directive1=value
        Directive2=value
        . . .

Les types de fichiers d'unité comprennent les sections suivantes :

[Unit]

La première section présente dans la plupart des fichiers d'unité est [Unit]. Cette section permet de définir les métadonnées du fichier d'unité et de configurer la relation entre le fichier d'unité et les autres fichiers d'unité. Elle est généralement placée en haut car elle fournit une vue d'ensemble du fichier d'unité.

[Automount] / [Mount] / [Path] / [Service] / [Slice] / [Socket] /[Swap] / [Timer]

Ces sections contiennent des directives spécifiques au type respectif. Reportez-vous à la Section 4, « Types de fichiers d'unité » pour obtenir la liste des types disponibles. Notez que les types device, target, snapshot et scope n'ont pas de section spécifique.

[Install]

Il s'agit souvent de la dernière section du fichier d'unité et est facultative. Elle permet de définir le comportement d'un fichier d'unité lorsqu'il est activé ou désactivé. Lorsque vous activez un fichier d'unité, il se lance automatiquement au démarrage. En fonction de l'unité spécifique, elle peut dépendre d'autres unités associées pour fonctionner correctement. Par exemple, chrony exige les directives After, Wants et Before qui sont toutes des dépendances avec lesquelles chrony doit travailler.

Exemple 1 : un fichier de service systemd
 
[Unit]
Description=usbguard 1

[Service]
ExecStart=/usr/sbin/usb-daemon 2

[Install]
WantedBy=multi-user.target 3

1

Brève description pertinente expliquant la fonction du fichier de service.

2

Spécifie le programme à exécuter au démarrage du service.

3

Démarre un système multi-utilisateur par une mise en réseau sans environnement graphique. Cette directive vous permet de spécifier une relation de dépendance.

4 Types de fichiers d'unité

 

Vous pouvez déterminer le type d'unité par son extension de fichier. systemd classe les unités en fonction du type de ressource qu'elles décrivent.

Types de fichiers d'unité disponibles pour systemd :

.service

Décrit comment gérer un service ou une application. Il s'agit notamment de la façon de démarrer ou d'arrêter le service, de recharger son fichier de configuration (le cas échéant), des conditions dans lesquelles le service démarre automatiquement et des informations de dépendance ou de hiérarchie pour les fichiers d'unité associés.

.scope

Ce fichier d'unité est créé automatiquement par systemd à partir des informations reçues de l'interface D-Bus et est utilisé pour gérer des ensembles de processus système créés en externe.

.path

Définit un chemin pour l'activation basée sur un chemin. Par défaut, un fichier d'unité .service portant le même nom de base est activé. inotify est une API de kernel utilisée par les programmes qui souhaitent être avertis des modifications apportées aux fichiers.

.snapshot

La commande systemctl snapshot crée automatiquement un fichier d'unité .snapshot. Cette commande crée des instantanés temporaires de l'état actuel du système. Vous pouvez modifier l'état actuel du système après avoir apporté des modifications. Les instantanés sont utilisés pour rétablir des états temporaires.

.timer

Définit un minuteur géré par systemd. Cette opération est similaire à une tâche cron pour une activation retardée ou planifiée. Un fichier d'unité portant le même nom, mais avec l'extension .service est lancé lorsque le minuteur est atteint.

.slice

Associe des noeuds de groupe de contrôle Linux, qui permettent d'attribuer ou de restreindre des ressources à tout processus associé à la tranche. Le nom indique la hiérarchie au sein de l'arborescence du groupe de contrôle. Les unités sont placées dans des tranches par défaut en fonction de leur type.

.target

Permet la synchronisation d'autres unités lors d'un démarrage ou d'un changement d'état, ou amène le système dans un nouvel état. D'autres unités spécifient leur relation avec les cibles afin d'assurer la synchronisation avec les opérations de ces dernières.

.socket

Décrit un réseau, un socket IPC ou un tampon FIFO utilisé par systemd pour l'activation basée sur un socket. Un fichier .service associé démarre lorsqu'une activité est détectée sur le socket défini par cette unité.

.device

Définit un périphérique qui a été désigné pour la gestion systemd par le système de fichiers udev ou sysfs. Les périphériques ne disposent pas tous du fichier .device. Ce fichier d'unité est requis lors de la commande ou du montage d'un périphérique, ou de l'accès à un périphérique.

.swap

Définit l'espace d'échange sur le système. Le nom du fichier d'unité doit refléter le chemin d'accès au périphérique ou au fichier de l'espace.

.mount

Définit un point de montage sur le système qui sera géré par systemd. Ce fichier porte le nom du chemin de montage, les barres obliques étant remplacées par des tirets. Les entrées dans /etc/fstab peuvent présenter des unités créées automatiquement.

.automount

Définit un point de montage monté automatiquement. Nommez le fichier d'après le point de montage auquel il fait référence. Un fichier d'unité .mount correspondant est requis pour définir les caractéristiques du montage.

5 Dépendances et ordre des unités

 

systemd a deux types de dépendances : les dépendances de condition et d'ordre. Les dépendances d'exigence spécifient quelles autres unités doivent être démarrées ou arrêtées lors de l'activation d'une unité. Les dépendances d'ordre spécifient l'ordre dans lequel les unités doivent être démarrées.

Dépendances des unités

Les fichiers d'unité intègrent la fonction de dépendances. Une unité peut souhaiter ou exiger une ou plusieurs autres unités avant de pouvoir s'exécuter. Ces dépendances sont définies dans des fichiers d'unité avec les directives Wants et Requires.

Wants

Par exemple, si l'unité A a Wants=unit B, lorsque l'unité A est exécutée, l'unité B s'exécute également. Toutefois, que l'unité B démarre correctement ou non, cela n'a pas d'influence sur l'exécution correcte de l'unité A.

Requires

Si l'unité A a Requires=unit B, les deux unités s'exécutent, mais si l'unité B ne s'exécute pas correctement, l'unité A est désactivée. Que les processus de l'unité A se soient exécutés correctement ou non n'a pas d'importance.

Ordre des unités

Sans instructions appropriées, systemd peut exécuter un groupe d'unités simultanément. Il est important de démarrer les services dans le bon ordre pour le bon fonctionnement du système Linux. Vous pouvez modifier l'ordre avec les instructions Before et After du de fichier d'unité.

Before

Par exemple, si l'unité A a Before=unit B, lorsque les deux unités sont exécutées, l'unité A est entièrement exécutée avant l'unité B.

After

Si l'unité A a After=unit B, lorsque les deux unités sont exécutées, l'unité B est entièrement exécutée avant l'unité A.

6 Consignation

 

Les fichiers journaux et les journaux sont importants pour l'administration du système. Ils fournissent des informations détaillées concernant un système et sont très importants pour le dépannage et l'audit. Les fichiers journaux peuvent contenir des événements et des messages générés par le kernel, des applications et des utilisateurs qui se connectent au système. Vous pouvez utiliser la commande journalctl pour interroger le journal. Cette commande affiche les journaux collectés par systemd. Le service systemd-journald gère la collecte de journaux de systemd. systemd-journald enregistre les événements et les messages au format binaire.

7 Cibles systemd

 

systemd utilise des unités et des cibles. Une unité systemd définit un service ou une opération sur le système, qui se compose d'un nom, d'un type et d'un fichier de configuration. Une cible systemd combine plusieurs unités et définit les services à démarrer pour atteindre la cible. Sur un serveur, par exemple, il s'agit d'un état dans lequel le réseau s'exécute et avec lequel plusieurs utilisateurs peuvent se connecter. Ces fichiers sont identifiés par le suffixe .target

Comme pour les fichiers d'unité, différentes cibles peuvent être imbriquées via des dépendances. Par exemple, multi-user.target requiert (entre autres) les cibles qui configurent les services de connexion et de session utilisateur.

Cibles systemd courantes :

default.target

Démarre par défaut. Le fichier default.target est un lien symbolique vers le véritable fichier cible, par exemple graphical.target pour un poste de travail de bureau. Pour un serveur, il s'agit généralement de graphical.target.

poweroff.target

Arrête et met le système hors tension.

rescue.target

Unité cible qui extrait le système de base et démarre une session shell de secours.

multi-user.target

Configure un système multi-utilisateur non graphique (console).

graphical.target

Utilise un système multi-utilisateur graphique avec des services réseau.

reboot.target

Arrête et redémarre le système.

Pour plus d'informations sur les cibles systemd, reportez-vous aux pages man 5 systemd.target et man 7 systemd.special.

8 Utilisation de systemd en tant qu'utilisateur ordinaire

 

Vous pouvez utiliser systemden tant qu'utilisateur ordinaire pour une meilleure sécurité ou lorsque vous ne disposez pas de privilèges d'utilisateur root. L'exécution d'un service sans privilèges peut être effectuée en créant un service user.

Lors de la création et de l'utilisation d'un service utilisateur, tenez compte des aspects suivants :

  • Les sessions de service utilisateur prennent fin à la fin de la session de l'utilisateur. Ce comportement peut être modifié à l'aide de la commande loginctl enable-linger USERNAME.

  • Les fichiers de service utilisateur se trouvent à l'emplacement /etc/systemd/user ou $HOME/.config/systemd/user/.

  • Vous pouvez contrôler les services utilisateur avec la commande systemctl --user.

9 Commandes systemctl

 

La commande systemctl permet d'examiner et de contrôler l'état de systemd et du gestionnaire de services.

Vous pouvez utiliser les commandes systemctl courantes suivantes et consulter la page man systemctl.

9.1 Affichage d'informations systemd

 

Pour afficher des informations relatives aux composants systemd, vous pouvez utiliser les commandes suivantes :

systemctl list-units

Répertorie les unités systemd. Vous pouvez utiliser les arguments facultatifs : ‑‑state=running pour afficher les unités actives et --type=service pour afficher les unités sorties et actives.

systemctl list-unit-files

Répertorie les unités systemd et leur état, par exemple statique, généré, désactivé, alias, masqué et activé.

systemctl list-dependencies

Répertorie l'arborescence de dépendances.

systemctl list-dependencies UNIT_FILE

Répertorie les dépendances d'un fichier d'unité.

9.2 Gestion des services systemd

 

La commande systemctl vous permet d'effectuer les tâches suivantes avec les services.

systemctl status SERVICE

Vérifie l'état du service spécifique.

systemctl show SERVICE

Affiche les informations de service.

systemctl start SERVICE

Au lieu de démarrer manuellement le service, utilisez la commande start. Lorsqu'une modification est apportée au fichier de configuration, le service associé doit être redémarré.

systemctl stop SERVICE

Arrête un service actif spécifique.

systemctl restart SERVICE

Au lieu de redémarrer manuellement le service, utilisez la commande restart. Lorsqu'une modification est apportée au fichier de configuration, le service associé doit être à nouveau redémarré.

systemctl enable SERVICE

Active le service au démarrage.

systemctl disable SERVICE

Désactive le service au démarrage.

systemctl reload-or-restart SERVICE

Recharge le service si cette fonctionnalité est prise en charge ; sinon, redémarre le service. Si le service n'est exécuté, il est redémarré.

systemctl mask SERVICE

Lorsqu'un service est masqué, cela signifie que le fichier d'unité est lié symboliquement à /dev/null. Un lien symbolique pour un service masqué est créé à partir de /etc/systemd/system pour pointer vers /dev/null. Cela rend le chargement du service impossible même si un autre service activé en a besoin. Il doit être arrêté manuellement, sinon il continue à s'exécuter en arrière-plan. Vous pouvez utiliser l'option --runtime pour uniquement masquer temporairement jusqu'au prochain redémarrage du système. 

Created symlink /etc/systemd/system/FOSSLinux.service → /dev/null.
systemctl unmask SERVICE

Retire le masque du service. Cette opération est effective lorsque le système est démarré ou redémarré manuellement.

9.3 Gestion des états du système

 

La commande systemctl vous permet d'exécuter des processus de gestion de l'alimentation de votre système, tels que le redémarrage, l'arrêt, etc., comme décrit ci-dessous.

systemctl reboot

Redémarre le système reboot.target.

systemctl poweroff

Met le système hors tension poweroff.target.

systemctl emergency

Passe en mode urgence emergency.target.

systemctl default

Revient à la cible par défaut multi-user.target.

10 Dépannage de systemd

 

Vous pouvez utiliser les conseils de dépannage suivants pour identifier et résoudre les problèmes liés aux services systemd et assurer le bon fonctionnement du système.

Vérifiez la syntaxe de votre fichier d'unité systemd avec la commande systemd-analyze verify SERVICE

Avant de démarrer ou d'activer un service systemd, vérifiez la syntaxe du fichier d'unité pour garantir l'absence d'erreur. Par exemple : 

> sudo systemd-analyze verify /etc/systemd/system/my-custom-service.service

La commande analyse le fichier d'unité et signale les erreurs de syntaxe, les fichiers manquants ou d'autres problèmes. Vous devez résoudre les problèmes signalés avant d'activer et de démarrer le service.

Vérifiez les journaux de votre service avec la commande journalctl -u SERVICE

Si vous rencontrez un problème avec un service systemd, consultez le journal du service. Par exemple : 

> sudo  journalctl -u my-custom-service.service

La commande affiche les journaux pour le service spécifié, y compris les messages d'erreur, les avertissements ou d'autres informations pertinentes. Vous pouvez utiliser ces journaux pour identifier et résoudre les problèmes liés au service.

Utilisez la commande systemd-analyze plot pour visualiser le processus de démarrage

Si des problèmes sont constatés pour un service au cours du processus de démarrage, vous pouvez utiliser systemd-analyze plot command pour visualiser le processus de démarrage et identifier ces problèmes. Par exemple : 

> sudo systemd-analyze plot > boot-plot.svg

La commande crée un fichier SVG nommé boot-plot.svg qui contient une représentation graphique du processus de démarrage et des problèmes potentiels. Ce fichier inclut l'heure de début et de fin de chaque service. Vous pouvez ouvrir ce fichier dans une visionneuse d'images ou un navigateur Web compatible SVG pour analyser les services qui posent problème au démarrage.

Dépannage des services ayant échoué

Pour identifier les services qui ont échoué et examiner la sortie du journal, exécutez : 

> sudo systemctl --state=failed
Vérifiez l'état d'exécution d'un service

Pour connaître l'état d'exécution actuel d'un service :

> sudo systemctl status SERVICE
L'arrêt ou le redémarrage prend du temps

Si l'arrêt ou le redémarrage prend du temps, il peut s'agir d'un service qui ne se ferme pas. systemd attend la fermeture de chaque service avant de tenter d'y mettre fin. Il arrive fréquemment qu'un service soit suspendu ou qu'un arrêt soit bloqué. Pour le savoir, utilisez la commande suivante : 

> sudo systemctl poweroff
  Failed to power off system via logind: There's already a shutdown or sleep operation in progress
> sudo systemctl list-jobs

Vous pouvez annuler les travaux en cours et en attente, puis arrêter ou redémarrer : 

> sudo systemctl cancel
> sudo systemctl stop systemd-suspend.service

11 Meilleures pratiques systemd

 

Vous pouvez suivre certaines des meilleures pratiques pour garantir des services systemd efficaces et capables de gérer différentes situations.

Vérifiez l'état d'exécution d'un service

Pour connaître l'état d'exécution actuel d'un service :

> sudo systemctl status SERVICE
Utilisez un chemin absolu dans votre fichier d'unité systemd

Utilisez un chemin absolu pour les fichiers exécutables et les fichiers obligatoires, tels que les fichiers ou les scripts de configuration dans votre fichier d'unité systemd. systemd ne se base pas sur les variables d'environnement de l'utilisateur comme $PATH pour localiser les fichiers.

Utilisez la directive ExecReload

Utilisez la directive ExecReload dans la section [SERVICE] pour définir une commande spécifique à exécuter lorsque vous rechargez un service avec la commande systemctl reload. Cette opération est utile pour les services qui peuvent recharger dynamiquement leur configuration sans redémarrage. 

[Service]
ExecStart=PATH_TO_EXECUTABLE
ExecReload=PATH_TO_RELOAD_SCRIPT
Utilisez la directive RestartSec

Utilisez la directive RestartSec dans la section [SERVICE] pour définir un délai (en secondes) avant le redémarrage du service après un échec. Cette opération est utile pour les services qui ont besoin d'un délai spécifié pour libérer des ressources ou empêcher les boucles de redémarrage rapides susceptibles d'entraîner une charge système élevée. 

[Service]
ExecStart=PATH_TO_EXECUTABLE
Restart=on-failure
RestartSec=5
Désactivez le mode d'urgence sur une machine distante

Vous pouvez désactiver le mode d'urgence sur une machine distante, par exemple, une machine virtuelle hébergée sur Google Cloud. Si ce mode est activé, la machine ne peut pas se connecter au réseau. Par exemple : 

> sudo systemctl mask emergency.service
> sudo systemctl mask emergency.target