systemd (Français)

From ArchWiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Related articles

État de la traduction: Cet article est la version francophone de systemd. Date de la dernière traduction: 2021-12-21. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

Comme indiqué sur la page web du projet :

systemd est une suite de blocs basiques pour construire un système Linux. Il fournit un gestionnaire de services et du système qui s'exécute en tant que PID 1 et démarre le reste du système. systemd fournit des capacités de parallélisation intensives, utilise l'activation par sockets et D-Bus pour démarrer les services, offre un démarrage à la demande des daemons, garde la trace des processus en utilisant les groupes de contrôle de Linux, gère les points de montage et d'automontage, et implémente une logique élaborée de contrôle des services basée sur les dépendances transactionnelles. systemd prend en charge les scripts d'initialisation SysV et LSB et fonctionne comme un remplacement de sysvinit. Les autres parties comprennent un daemon de journalisation, des utilitaires pour contrôler la configuration de base du système comme le nom d'hôte, la date, la locale, maintenir une liste des utilisateurs connectés ainsi que des conteneurs et machines virtuelles en cours d'exécution, les comptes système, les répertoires et paramètres d'exécution, et des daemons pour gérer la configuration simple du réseau, la synchronisation de l'heure du réseau, la transmission des journaux et la résolution des noms.
Note: Pour une explication détaillée des motifs pour lesquels Arch est passé à systemd, consultez ce message du forum.

Utilisation basique de systemctl

La commande principale utilisée pour surveiller et contrôler systemd est systemctl. Certaines de ses utilisations sont l'examen de l'état du système et la gestion du système et des services. Consultez systemctl(1) pour plus de détails.

Astuce:
  • Vous pouvez utiliser toutes les commandes systemctl suivantes avec le commutateur -H user@host pour contrôler une instance de systemd sur une machine distante. Ceci utilisera SSH pour se connecter à l'instance systemd distante.
  • Les utilisateurs de Plasma peuvent installer systemd-kcmAUR comme interface graphique pour systemctl. Après l'installation, le module sera ajouté dans System administration.

Utilisation des unités

Les unités comprennent généralement, mais sans s'y limiter, les services (.service), les points de montage (.mount), les périphériques (.device) et les sockets (.socket).

Lorsque vous utilisez systemctl, vous devez généralement spécifier le nom complet du fichier d'unité, y compris son suffixe, par exemple sshd.socket. Il existe cependant quelques formes courtes pour spécifier l'unité dans les commandes systemctl suivantes :

  • Si vous ne spécifiez pas le suffixe, systemctl supposera .service. Par exemple, netctl et netctl.service sont équivalents.
  • Les points de montage seront automatiquement traduits dans l'unité .mount appropriée. Par exemple, spécifier /home est équivalent à home.mount.
  • De la même manière que pour les points de montage, les périphériques sont automatiquement traduits dans l'unité .device appropriée, donc spécifier /dev/sda2 est équivalent à dev-sda2.device.

Consultez systemd.unit(5) pour plus de détails.

Note: Certains noms d'unités contiennent un signe @ (par exemple, name@string.service) : cela signifie qu'il s'agit d'une instance d'une unité template, dont le nom de fichier réel ne contient pas la partie string (par exemple, name@.service). string est appelé identifiant d'instance et est similaire à un argument qui est passé à l'unité template lorsqu'elle est appelée avec la commande systemctl : dans le fichier de l'unité, il remplacera le spécificateur %i. Pour être plus précis, avant d'essayer d'instancier l'unité modèle name@.suffixe, systemd cherchera en fait une unité avec le nom de fichier exact name@string.suffixe, bien que par convention un tel "clash" se produise rarement, c'est-à-dire que la plupart des fichiers unités contenant un signe @ sont censés être des modèles. De plus, si une unité modèle est appelée sans identifiant d'instance, elle échouera généralement (sauf avec certaines commandes systemctl, comme cat).

Les commandes du tableau ci-dessous opèrent sur des unités système puisque --system est le défaut implicite de systemctl. Pour opérer sur les unités utilisateur (pour l'utilisateur appelant), utilisez systemctl --user sans les privilèges «root». Consultez également systemd (Français)/User (Français) pour activer/désactiver les unités utilisateur pour tous les utilisateurs.

Astuce:
  • La plupart des commandes fonctionnent également si plusieurs unités sont spécifiées, consultez systemctl(1) pour plus d'informations.
  • Le commutateur --now peut être utilisé conjointement avec enable, disable et mask pour respectivement démarrer, arrêter ou masquer l'unité immédiatement plutôt qu'après le redémarrage.
  • Un paquet peut proposer des unités pour différents usages. Si vous venez d'installer un paquet, pacman -Qql paquet | grep -Fe .service -e .socket peut être utilisé pour les vérifier et les trouver.
Action Commande Note
Analyser l'état du système
Montrer l'état du système systemctl status
Lister les units en cours d'exécution systemctl ou
systemctl list-units
Lister les units en échec systemctl --failed
Lister les fichiers d'units installés1 systemctl list-unit-files
Afficher l'état du processus pour un PID systemctl status pid cgroup slice, mémoire et parent
Vérifier l'état de l'unité
Afficher une page de manuel associée à une unité systemctl help unit tel que pris en charge par l'unité
État d'une unité systemctl status unit y compris si elle est en cours d'exécution ou non
Vérifier si une unité est activée systemctl is-enabled unit
Démarrer, redémarrer, recharger d'une unité
Démarrer une unité immédiatement systemctl start unit en root
Arrêter une unité immédiatement systemctl stop unit en root
Redémarrer une unité systemctl restart unit en root
Recharger une unité et sa configuration systemctl reload unit e, root
Recharger la configuration du gestionnaire systemd2 systemctl daemon-reload en root rechercher les unités nouvelles ou modifiées
Activer une unité
Activer une unité pour s'exécuter automatiquement au démarrage systemctl enable unit en root
Activer une unité pour s'exécuter automatiquement au démarrage et la Démarrer immédiatement systemctl enable --now unit en root
Désactiver une unité pour ne plus s'exécuter automatiquement au démarrage systemctl disable unit en root
Réactiver une unité3 systemctl reenable unit en root c'est-à-dire désactiver et réactiver
Masquer une unité
Masquer une unité pour rendre impossible son exécution4 systemctl mask unit en root
Démasquer une unité systemctl unmask unit en root
  1. Consultez systemd.unit(5) § UNIT FILE LOAD PATH pour connaître les répertoires où se trouvent les fichiers d'unités disponibles.
  2. Ceci ne demande pas aux unités modifiées de recharger leurs propres configurations (consultez l'action Recharger).
  3. Par exemple, si sa section [Install] a été modifiée depuis sa dernière activation.
  4. A la fois manuellement et en tant que dépendance, ce qui rend le masquage dangereux. Vérifiez si des unités masquées existent avec : 
    # systemctl list-unit-files --state=masked

Gestion de l'énergie

Polkit est nécessaire pour la gestion de l'alimentation en tant qu'utilisateur non privilégié. Si vous êtes dans une session locale d'utilisateur systemd-logind et qu'aucune autre session n'est active, les commandes suivantes fonctionneront sans les privilèges de root. Dans le cas contraire (par exemple, parce qu'un autre utilisateur est connecté à un tty), systemd vous demandera automatiquement le mot de passe root.

Action Commande
Arrêter et redémarrer le système systemctl reboot
{ic|systemctl poweroff}}.
Suspendre le système | systemctl suspend.
Mettre le système en hibernation | systemctl hibernate
Mettre le système en état de sommeil hybride (ou suspendre à la fois) systemctl hybrid-sleep

Écrire des unités

La syntaxe des fichiers «unités» de systemd (systemd.unit(5)) s'inspire des spécifications des fichiers .desktop XDG, qui sont à leur tour inspirés de fichiers .ini de Microsoft Windows. Les fichiers «unités» sont chargés à partir de plusieurs emplacements (pour consulter la liste complète, exécutez systemctl show --property=UnitPath), mais les principaux sont (classés de la plus basse à la plus haute priorité) :

  • /usr/lib/systemd/system/ : unités fournies par les paquets installés
  • /etc/systemd/system/ : unités installées par l'administrateur système
Note:
  • Les chemins de chargement sont complètement différents lorsque vous exécutez systemd en mode utilisateur.
  • Les noms des unités systemd ne peuvent contenir que des caractères alphanumériques ASCII, des traits de soulignement et des points. Tous les autres caractères doivent être remplacés par des échappements de type C "\x2d", ou utiliser leur sémantique prédéfinie ('@', '-'). Consultez systemd.unit(5) et systemd-escape(1) pour plus d'informations.

Consultez les unités installées par vos paquets pour des exemples, ainsi que systemd.service(5) § EXAMPLES.

Astuce: Les commentaires précédés de # peuvent également être utilisés dans les fichiers d'unités, mais uniquement dans les nouvelles lignes. N'utilisez pas de commentaires de fin de ligne après les paramètres systemd, sinon l'unité ne sera pas activée.

Gérer les dépendances

Avec systemd, les dépendances peuvent être résolues en concevant correctement les fichiers d'unité. Le cas le plus typique est que l'unité A nécessite que l'unité B fonctionne avant que A ne soit lancée. Dans ce cas, ajoutez Requires=B et After=B à la section [Unit] de A. Si la dépendance est facultative, ajoutez Wants=B et After=B à la place. Notez que Wants= et Requires= n'impliquent pas After=, ce qui signifie que si After= n'est pas spécifié, les deux unités seront démarrées en parallèle.

Les dépendances sont généralement placées sur les services et non sur les #Cibles. Par exemple, network.target est tirée par le service qui configure vos interfaces réseau, donc commander votre unité personnalisée après lui est suffisant puisque network.target est démarrée de toute façon.

Types de service

Il existe plusieurs types de démarrage différents à considérer lors de l'écriture d'un fichier de service personnalisé. Ceci est défini avec le paramètre Type= dans la section [Service] :

  • Type=simple (par défaut) : systemd considère que le service doit être démarré immédiatement. Le processus ne doit pas forker. N'utilisez pas ce type si d'autres services doivent être commandés sur ce service, à moins qu'il ne soit activé par socket.
  • Type=forking : systemd considère que le service est démarré une fois que le processus a forké et que le parent est sorti. Pour les daemons classiques, utilisez ce type sauf si vous savez que ce n'est pas nécessaire. Vous devez également spécifier PIDFile= pour que systemd puisse garder la trace du processus principal.
  • Type=oneshot : cette option est utile pour les scripts qui effectuent une seule tâche puis se terminent. Vous pouvez également définir RemainAfterExit=yes pour que systemd considère toujours le service comme actif après la sortie du processus.
  • Type=notify : identique à Type=simple, mais avec la stipulation que le daemon enverra un signal à systemd quand il sera prêt. L'implémentation de référence pour cette notification est fournie par libsystemd-daemon.so.
  • Type=dbus : le service est considéré comme prêt lorsque le BusName spécifié apparaît sur le bus système de DBus.
  • Type=idle : systemd retardera l'exécution du binaire du service jusqu'à ce que tous les travaux soient distribués. A part cela, le comportement est très similaire à Type=simple.

Consultez la page de manuel systemd.service(5) § OPTIONS pour une explication plus détaillée des valeurs Type

Modifier les unités fournies

Pour éviter les conflits avec pacman, les fichiers d'unités fournis par les paquets ne doivent pas être modifiés directement. Il existe deux façons sûres de modifier une unité sans toucher au fichier d'origine : créer un nouveau fichier d'unité qui remplace l'unité d'origine ou créer des #Fichiers de substitution qui sont appliqués par-dessus l'unité d'origine. Pour les deux méthodes, vous devez recharger l'unité après coup pour appliquer vos modifications. Vous pouvez le faire en éditant l'unité avec systemctl edit. (qui recharge l'unité automatiquement) ou en rechargeant toutes les unités avec : 

# systemctl daemon-reload
Astuce:
  • Vous pouvez utiliser systemd-delta pour consulter les fichiers de l'unité qui ont été remplacés ou étendus et ce qui a été modifié exactement.
  • Utilisez systemctl cat unit pour voir le contenu d'un fichier unité et tous les snippets drop-in associés.

Remplacer des fichiers «unités»

Pour remplacer le fichier d'unité /usr/lib/systemd/system/unit, créez le fichier /etc/systemd/system/unit et réactivez l'unité pour mettre à jour les liens symboliques.

Alternativement, exécutez : 

# systemctl edit --full unit (unité)

Ceci ouvre /etc/systemd/system/unit dans votre éditeur (en copiant la version installée si elle n'existe pas encore) et la recharge automatiquement lorsque vous terminez l'édition.

Note: Les unités de remplacement continueront à être utilisées même si Pacman met à jour les unités originales dans le futur. Cette méthode rend la maintenance du système plus difficile et c'est pourquoi l'approche suivante est préférée.

Fichiers de substitution

Pour créer des fichiers de substitution pour le fichier d'unités /usr/lib/systemd/system/unit, créez le répertoire /etc/systemd/system/unit'.d/ et placez-y des fichiers .conf pour substituer ou ajouter de nouvelles options. systemd analysera et appliquera ces fichiers par dessus l'unité originale.

La manière la plus simple de faire est de lancer : 

# systemctl edit unit.

Cela ouvre le fichier /etc/systemd/system/unit.d/override.conf dans votre éditeur de texte (en le créant si nécessaire) et recharge automatiquement l'unité lorsque vous avez terminé l'édition.

Note: Toutes les clés ne peuvent pas être remplacées par des fichiers drop-in. Par exemple, pour modifier Conflicts= un fichier de remplacement est nécessaire.

Retour à la version d'origine

Pour rétablir les modifications apportées à une unité à l'aide de systemctl edit, faites : 

# systemctl revert unit (unité)

Exemples

Par exemple, si vous souhaitez simplement ajouter une dépendance supplémentaire à une unité, vous pouvez créer le fichier suivant : 

/etc/systemd/system/unit.d/customdependency.conf
[Unité]
Requires=new dependency (nouvelle dépendance)
After=new dependency (après la nouvelle dépendance)

Autre exemple, afin de remplacer la directive ExecStart pour une unité qui n'est pas de type oneshot, créez le fichier suivant : 

/etc/systemd/system/unit.d/customexec.conf
[Service]
ExecStart=
ExecStart= nouvelle commande.

Notez comment ExecStart doit être effacé avant d'être réassigné [1]. Il en va de même pour tous les éléments qui peuvent être spécifiés plusieurs fois, par exemple OnCalendar pour les minuteries.

Encore un exemple pour redémarrer automatiquement un service : 

/etc/systemd/system/unit.d/restart.conf
[Service]
Restart=toujours
RestartSec=30

Cibles

systemd utilise des cibles pour regrouper des unités via des dépendances et comme points de synchronisation standardisés. Elles ont un but similaire à celui de runlevels mais agissent un peu différemment. Chaque cible est nommée au lieu d'être numérotée et est destinée à servir un objectif spécifique avec la possibilité d'en avoir plusieurs actives en même temps. Certaines cibles sont implémentées en héritant de tous les services d'une autre cible et en lui ajoutant des services supplémentaires. Il existe des cibles systemd qui imitent les niveaux d'exécution courants de SystemVinit, vous pouvez donc toujours changer de cible en utilisant la commande familière telinit RUNLEVEL.

Obtenir les cibles actuelles

La commande suivante doit être utilisée sous systemd au lieu d'exécuter runlevel : 

$ systemctl list-units --type=target

Créer une cible personnalisée

Les runlevels qui avaient une signification définie sous sysvinit (c'est-à-dire 0, 1, 3, 5 et 6) ont une correspondance 1:1 avec une cible spécifique de systemd. Malheureusement, il n'y a pas de bon moyen de faire la même chose pour les niveaux d'exécution définis par l'utilisateur comme 2 et 4. Si vous les utilisez, il est suggéré de créer une nouvelle cible systemd nommée /etc/systemd/system/votre cible qui prend l'un des niveaux d'exécution existants comme base (vous pouvez regarder /usr/lib/systemd/system/graphical. target comme exemple), crée un répertoire /etc/systemd/system/votre cible.wants, puis établit un lien symbolique avec les services supplémentaires de /usr/lib/systemd/system/ que vous souhaitez activer.

Correspondance entre les niveaux d'exécution de SysV et les cibles systemd

Niveau d'exécution SysV ! ! cible systemd ! ! Notes
0 runlevel0.target, poweroff.target Arrêter le système.
1, s, single runlevel1.target, rescue.target Mode utilisateur unique.
2, 4 runlevel2.target, runlevel4.target, multi-user.target Niveaux d'exécution définis par l'utilisateur/par site. Par défaut, identique à 3.
3 runlevel3.target, multi-user.target Multi-utilisateur, non-graphique. Les utilisateurs peuvent généralement se connecter via plusieurs consoles ou via le réseau.
5 runlevel5.target, graphical.target Multi-utilisateur, graphique. Offre généralement tous les services du runlevel 3 plus une connexion graphique.
6 runlevel6.target, reboot.target Redémarrage.
emergency emergency.target Shell d'urgence

Changer la cible actuelle

Dans systemd, les cibles sont exposées via les target units. Vous pouvez les changer comme suit : 

# systemctl isolate graphical.target

Cela ne changera que la cible actuelle, et n'aura aucun effet sur le prochain démarrage. Ceci est équivalent à des commandes telles que telinit 3 ou telinit 5 dans Sysvinit.

Changement de la cible par défaut pour le démarrage

La cible standard est default.target, qui est un lien symbolique vers graphical.target. Cela correspond à peu près à l'ancien niveau d'exécution 5.

Pour vérifier la cible actuelle avec systemctl : 

$ systemctl get-default

Pour changer la cible par défaut sur laquelle démarrer, modifiez le lien symbolique default.target. Avec systemctl : 

# systemctl set-default multi-user.target
Suppression de /etc/systemd/system/default.target.
Créé un lien symbolique /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

Vous pouvez également ajouter l'un des paramètres du noyau suivants à votre chargeur d'amorçage :

  • systemd.unit=multi-user.target (ce qui correspond à peu près à l'ancien niveau d'exécution 3),
  • systemd.unit=rescue.target (qui correspond en gros à l'ancien niveau d'exécution 3) (ce qui correspond à peu près à l'ancien niveau d'exécution 1).

Ordre des cibles par défaut

systemd choisit la default.target selon l'ordre suivant :

  1. Paramètre du noyau indiqué ci-dessus
  2. Symlink de /etc/systemd/system/default.target
  3. Lien symbolique de /usr/lib/systemd/system/default.target

Composants de systemd

Quelques composants (non exhaustifs) de systemd sont :

systemd.mount - montage

systemd est chargé de monter les partitions et les systèmes de fichiers spécifiés dans /etc/fstab. Le systemd-fstab-generator(8) traduit toutes les entrées de /etc/fstab en unités systemd ; ceci est effectué au démarrage et chaque fois que la configuration du gestionnaire de système est rechargée.

systemd étend les capacités habituelles de fstab et offre des options de montage supplémentaires. Celles-ci affectent les dépendances de l'unité de montage. Elles peuvent, par exemple, garantir qu'un montage ne sera effectué qu'une fois que le réseau sera en place ou qu'une autre partition sera montée. La liste complète des options de montage spécifiques à systemd, généralement préfixées par x-systemd., est détaillée dans systemd.mount(5) § FSTAB.

Un exemple de ces options de montage est le montage automatique, qui signifie monter seulement lorsque la ressource est requise plutôt qu'automatiquement au démarrage. Ceci est fourni dans Fstab (Français)#Montage automatique avec systemd.

Montage automatique d'une partition GPT

Sur les systèmes amorcés par UEFI, si des conditions spécifiques sont réunies, systemd-gpt-auto-generator(8) montera automatiquement les partitions GPT conformément à la Specification de Partitions Découvrables et elles peuvent donc être omises de fstab.

Les conditions préalables sont :

  • Le chargeur d'amorçage doit définir la variable EFI LoaderDevicePartUUID, afin que la partition système EFI utilisée puisse être identifiée. Ceci est pris en charge par systemd-boot, systemd-stub(7) et rEFInd (non activé par défaut). Cela peut être vérifié en exécutant bootctl et en vérifiant l'état de Boot loader sets ESP information.
  • La partition racine doit se trouver sur le même disque physique que la partition système EFI utilisée. Les autres partitions qui seront montées automatiquement doivent se trouver sur le même disque physique que la partition racine. Cela signifie essentiellement que toutes les partitions montées automatiquement doivent partager le même disque physique avec l'ESP.
Tip: L'automontage d'une partition peut être désactivé en modifiant le type GUID de la partition ou en définissant le bit d'attribut de la partition 63 "do not automount", consultez gdisk#Prevent GPT partition automounting.
/var

Pour que le montage automatique de /var fonctionne, le PARTUUID doit correspondre au hachage SHA256 HMAC de l'UUID du type de partition (4d21b016-b534-45c2-a9fb-5c16e091fd2d) avec l'ID de la machine comme clé. Le PARTUUID requis peut être obtenu en utilisant : 

$ systemd-id128 -u --app-specific=4d21b016-b534-45c2-a9fb-5c16e091fd2d machine-id
Note: systemd-id128(1) lit l'ID de la machine à partir de /etc/machine-id, ce qui rend impossible la connaissance du PARTUUID nécessaire avant l'installation du système.

systemd-sysvcompat

Le rôle principal de systemd-sysvcompat (requis par base) est de fournir le traditionnel binaire linux init. Pour les systèmes contrôlés par systemd, init est juste un lien symbolique vers son exécutable systemd.

En outre, il fournit quatre raccourcis pratiques auxquels les utilisateurs de SysVinit peuvent être habitués. Ces raccourcis sont halt(8), poweroff(8), reboot(8) et shutdown(8). Chacune de ces quatre commandes est un lien symbolique vers systemctl, et est régie par le comportement de systemd. Par conséquent, la discussion à #Gestion de l'énergie s'applique.

Les systèmes basés sur systemd peuvent abandonner ces méthodes de compatibilité System V en ajoutant init= aux paramètre de démarrage (consultez, par exemple, /bin/init est dans systemd-sysvcompat ?) et les arguments de la commande systemctl native de systemd.

systemd-tmpfiles - fichiers temporaires

systemd-tmpfiles crée, supprime et nettoie les fichiers et répertoires volatiles et temporaires. Il lit les fichiers de configuration dans /etc/tmpfiles.d/ et /usr/lib/tmpfiles.d/ pour découvrir les actions à effectuer. Les fichiers de configuration du premier répertoire sont prioritaires sur ceux du second.

Les fichiers de configuration sont généralement fournis avec les fichiers de service, et ils sont nommés dans le style de /usr/lib/tmpfiles.d/'program.conf. Par exemple, le daemon Samba s'attend à ce que le répertoire /run/samba existe et ait les bonnes permissions. Par conséquent, le paquet samba est livré avec cette configuration : 

/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root

Les fichiers de configuration peuvent également être utilisés pour écrire des valeurs dans certains fichiers au démarrage. Par exemple, si vous avez utilisé /etc/rc.local pour désactiver le réveil à partir de périphériques USB avec echo USBE > /proc/acpi/wakeup, vous pouvez utiliser le fichier tmp suivant à la place : 

/etc/tmpfiles.d/disable-usb-wake.conf
# Chemin Mode UID GID Age Argument
w /proc/acpi/wakeup - - - - USBE

Consultez les pages de manuel systemd-tmpfiles(8) et tmpfiles.d(5) pour plus de détails.

Note: Cette méthode peut ne pas fonctionner pour définir des options dans /sys car le service systemd-tmpfiles-setup peut s'exécuter avant que les modules de périphériques appropriés ne soient chargés. Dans ce cas, vous pouvez vérifier si le module possède un paramètre pour l'option que vous voulez définir avec modinfo module et définir cette option avec un fichier de configuration dans /etc/modprobe.d. Sinon, vous devrez écrire une règle udev pour définir l'attribut approprié dès que le périphérique apparaît.

Trucs et astuces

Outils de configuration de l'interface graphique

  • systemadm — Explorateur graphique pour les unités de systemd. Il peut afficher la liste des unités, éventuellement filtrée par type.
https://cgit.freedesktop.org/systemd/systemd-ui/ || systemd-ui
  • SystemdGenie — Utilitaire de gestion de systemd basé sur les technologies KDE.
https://invent.kde.org/system/systemdgenie || {Pkg}}

Exécution des services après le démarrage du réseau

Pour retarder un service jusqu'à ce que le réseau soit en place, incluez les dépendances suivantes dans le fichier .service : 

/etc/systemd/system/foo.service
[Unité]
...
Wants=network-online.target
Après=network-online.target
...

Le service d'attente réseau de l'application particulière qui gère le réseau doit également être activé pour que network-online.target reflète correctement l'état du réseau.

  • Si vous utilisez NetworkManager, NetworkManager-wait-online.service est activé en même temps que NetworkManager.service. Vérifiez si c'est le cas avec systemctl is-enabled NetworkManager-wait-online.service S'il n'est pas activé, alors réactivez NetworkManager.service.
  • Dans le cas de netctl, activez netctl-wait-online.service.
  • Si vous utilisez systemd-networkd, systemd-networkd-wait-online.service est activé en même temps que systemd-networkd.service. Vérifiez si c'est le cas avec systemctl is-enabled systemd-networkd-wait-online.service. S'il n'est pas activé, alors réactivez systemd-networkd.service.

Pour des explications plus détaillées, consultez exécuter un service après que le réseau soit connecté dans le wiki systemd de freedesktop.org.

Si un service doit effectuer des requêtes DNS, il doit en outre être ordonnancé après nss-lookup.target : 

/etc/systemd/system/foo.service
[Unit]
...
Wants=network-online.target
After=network-online.target nss-lookup.target
...

Consultez systemd.special(7) § Special Passive System Units.

Pour que nss-lookup.target ait un quelconque effet, il faut un service qui l'attire via Wants=nss-lookup.target et qui se place avant lui avec Before=nss-lookup.target. Cette opération est généralement effectuée par des résolveurs DNSs locaux.

Vérifiez quel service actif, s'il y en a un, tire dans nss-lookup.target avec : 

$ systemctl list-dependencies --reverse nss-lookup.target

Activer les unités installées par défaut

Arch Linux est livré avec /usr/lib/systemd/system-preset/99-default.preset contenant disable *. Ceci amène systemctl preset à désactiver toutes les unités par défaut, de sorte que lorsqu'un nouveau paquet est installé, l'utilisateur doit activer manuellement l'unité.

Si ce comportement n'est pas souhaité, créez simplement un lien symbolique de /etc/systemd/system-preset/99-default.preset vers /dev/null afin de remplacer le fichier de configuration. Ainsi, systemctl preset activera toutes les unités installées, quel que soit le type d'unité, à moins que cela ne soit spécifié dans un autre fichier dans l'un des répertoires de configuration de systemctl preset. Les unités utilisateur ne sont pas affectées. Consultez systemd.preset(5) pour plus d'informations.

Note: L'activation de toutes les unités par défaut peut causer des problèmes avec les paquets qui contiennent deux ou plusieurs unités mutuellement exclusives. systemctl preset est conçu pour être utilisé par les distributions et les spins ou les administrateurs système. Dans le cas où deux unités conflictuelles seraient activées, vous devriez explicitement spécifier laquelle doit être désactivée dans un fichier de configuration de preset comme spécifié dans la page de manuel systemd.preset(5).

Mise en «sandbox» (bac à sable) des environnements d'application

Un fichier d'unité peut être créé comme un bac à sable pour isoler les applications et leurs processus dans un environnement virtuel durci. systemd utilise namespaces, une liste de capacités autorisées/refusées, et les groupes de contrôle pour conteneuriser les processus à travers une configuration étendue de l'environnement d'exécution-systemd.exec(5).

L'amélioration d'un fichier d'unité systemd existant avec le sandboxing des applications nécessite généralement des essais et des erreurs accompagnés d'une utilisation généreuse de strace, stderr et journalctl(1). Vous pouvez d'abord rechercher dans la documentation en amont des tests déjà effectués sur lesquels baser vos essais. Pour obtenir un point de départ pour les options de durcissement possibles, exécutez 

$ systemd-analyze security unit (unité)

Quelques exemples de la façon dont le sandboxing avec systemd peut être déployé :

Notification de l'échec d'un service

Afin de notifier les échecs de service, une directive OnFailure= doit être ajoutée au fichier de service correspondant, par exemple en utilisant un #Fichiers de substitution. L'ajout de cette directive à chaque unité de service peut être réalisé à l'aide d'un fichier de configuration drop-in de haut niveau. Pour plus de détails sur les fichiers de dépôt de haut niveau, consultez systemd.unit(5).

Créez un fichier de dépôt de premier niveau pour les services : 

/etc/systemd/system/service.d/toplevel-override.conf
[Unit]
OnFailure=failure-notification@%n

Ceci ajoute OnFailure=failure-notification@%n à chaque fichier de service. Si une unité_service échoue, failure-notification@une_unité_service sera lancée pour gérer la livraison de la notification (ou toute autre tâche pour laquelle elle est configurée).

Créez l'unité de modèle failure-notification@ : 

/etc/systemd/system/failure-notification@.service
[Unit]
Description=Send a notification about a failed systemd unit
After=network.target

[Service]
Type=simple
ExecStart=/path/to/failure-notification.sh %i

Vous pouvez créer le script failure-notification.sh et définir ce qu'il faut faire ou comment notifier (mail, gotify, xmpp, etc.). Le %i sera le nom de l'unité de service défaillante et sera passé comme argument au script.

Afin d'éviter une régression pour les instances de failure-notification@.service, créez un fichier de configuration de dépôt vide avec le même nom que le dépôt de niveau supérieur (le fichier de configuration de dépôt de niveau service vide est prioritaire sur le dépôt de niveau supérieur et remplace ce dernier) : 

# mkdir -p /etc/systemd/system/failure-notification@.service.d
# touch /etc/systemd/system/failure-notification@.service.d/toplevel-override.conf

Dépannage

Recherche des services ayant échoué

Pour trouver les services systemd qui n'ont pas réussi à démarrer : 

$ systemctl --state=failed

Pour savoir pourquoi ils ont échoué, examinez leur sortie de journal. Consultez systemd/Journal#Filtering output pour plus de détails.

Diagnostic des problèmes de démarrage

systemd a plusieurs options pour diagnostiquer les problèmes avec le processus de démarrage. Consultez General troubleshooting (Français)#Problèmes de démarrage pour des instructions plus générales et des options pour capturer les messages de démarrage avant que systemd ne prenne en charge le processus de démarrage. Consultez également la documentation sur le débogage de systemd de freedesktop.org [2].

Diagnostic d'un service

Si un service systemd se comporte mal ou si vous souhaitez obtenir plus d'informations sur ce qui se passe, définissez la SYSTEMD_LOG_LEVEL {[variable d'environnement]] à SYSTEMD_LOG_LEVEL. [à debug. Par exemple, pour exécuter le daemon systemd-networkd en mode débogage :

Ajoutez un #Fichiers de substitution pour le service en ajoutant les deux lignes : 

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

Ou comme équivalent, définissez la variable d'environnement manuellement : 

# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

puis redémarrer systemd-networkd et regarder le journal du service avec l'option -f/--follow.

L'arrêt/le redémarrage prend très longtemps

Si le processus d'arrêt prend beaucoup de temps (ou semble se figer), il est probable qu'un service qui ne se termine pas est à blâmer. systemd attend un certain temps que chaque service se termine avant d'essayer de le tuer. Pour savoir si vous êtes concerné, consultez l’extinction finit par se terminer dans le wiki systemd.

Un problème courant est un processus d'arrêt ou de suspension bloqué. Pour vérifier si c'est le cas, vous pouvez exécuter l'une ou l'autre de ces commandes et vérifier les sorties 

# systemctl poweroff
Failed to power off system via logind: There's already a shutdown or sleep operation in progress
# systemctl list-jobs
JOB UNIT                    TYPE  STATE  
...
21593 systemd-suspend.service start running
21592 suspend.target          start waiting
..

La solution à ce problème serait d'annuler ces tâches en exécutant 

# systemctl cancel
# systemctl stop systemd-suspend.service

puis de réessayer l'arrêt ou le redémarrage.

Les processus à courte durée de vie ne semblent pas alimenter le journal

Si l'exécution de journalctl -u foounit en tant que root ne montre aucune sortie pour un service de courte durée, regardez plutôt le PID. Par exemple, si systemd-modules-load.service échoue et que systemctl status systemd-modules-load indique qu'il a été exécuté sous le PID 123, vous pouvez consulter la sortie dans le journal pour ce PID, c'est-à-dire en exécutant journalctl -b _PID=123 en tant que root. Les champs de métadonnées du journal tels que _SYSTEMD_UNIT et _COMM sont collectés de manière asynchrone et dépendent du répertoire /proc du processus existant. Pour résoudre ce problème, il faut corriger le noyau pour qu'il fournisse ces données via une connexion socket, comme pour SCM_CREDENTIALS. En bref, il s'agit d'un bug. Gardez à l'esprit que les services qui échouent immédiatement peuvent ne rien imprimer dans le journal, conformément à la conception de systemd.

Le temps de démarrage augmente avec le temps

Après avoir utilisé systemd-analyze, un certain nombre d'utilisateurs ont remarqué que leur temps de démarrage avait considérablement augmenté par rapport à ce qu'il était auparavant. Après avoir utilisé systemd-analyze blame NetworkManager (Français) est signalé comme prenant un temps anormalement long pour démarrer.

Pour certains utilisateurs, le problème est dû au fait que /var/log/journal devient trop volumineux. Ceci peut avoir d'autres impacts sur les performances, comme pour systemctl status ou journalctl. En tant que telle, la solution est de supprimer tous les fichiers du dossier (idéalement en faisant une sauvegarde quelque part, au moins temporairement) et ensuite de définir une taille limite pour les fichiers du journal comme décrit dans Systemd/Journal#Journal size limit.

systemd-tmpfiles-setup.service ne démarre pas au démarrage

À partir de systemd 219, /usr/lib/tmpfiles.d/systemd.conf spécifie les attributs ACL pour les répertoires sous /var/log/journal et, par conséquent, exige que la prise en charge des ACL soit activé pour le système de fichiers sur lequel le journal réside.

Consultez Access Control Lists#Enable ACL pour savoir comment activer ACL sur le système de fichiers qui abrite /var/log/journal.

Désactiver le mode d'urgence sur la machine distante

Vous pouvez souhaiter désactiver le mode d'urgence sur une machine distante, par exemple, une machine virtuelle hébergée sur Azure ou Google Cloud. En effet, si le mode d'urgence est déclenché, la machine sera bloquée pour se connecter au réseau.

Pour le désactiver, masquez emergency.service et emergency.target.

Voir aussi