systemd (Français)

État de la traduction:
Cet article est la version francophone de
systemd
. Date de la dernière traduction: 2024-03-25. Vous pouvez aider à synchroniser la traduction s'il y a eu des
changements
dans la version anglaise.
Related articles
/User (Français)
/Timers (Français)
/Journal (Français)
systemd FAQ
init
udev (Français)
Improving performance (Français)/Boot process (Français)
Allow users to shutdown
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.
Historiquement, ce que systemd appelle un service était nommé
daemon
: tout processus qui tourne en
arrière-plan
(c'est-à-dire sans interface graphique ni sortie sur un terminal), pour gérer une boucle d'événements ou fournir certains services. Un bon exemple est le cas d'un serveur web qui scrute les requêtes afin de délivrer les pages ou d'un serveur ssh attendant que quelqu'un s'y connecte. Les daemons ne sont pas tous des applications complètes et certains fournissent un travail invisible. Ils sont ainsi utilisés pour des tâches comme l'écriture de messages dans un fichier-journal (par ex.
syslog
,
metalog
), ou pour la synchronisation de l'horloge du système (par exemple
Network Time Protocol
). Voir
daemon(7)
pour de plus amples informations.
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 paramètre
-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-kcm
AUR
[
broken link
: package not found]
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 paramètre
--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és
1
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
en root
Recharger
la configuration du
gestionnaire systemd
2
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écution
4
systemctl mask
unit
en root
Démasquer
une unité
systemctl unmask
unit
en root
Consultez
systemd.unit(5) § UNIT FILE LOAD PATH
pour connaître les répertoires où se trouvent les fichiers d'unités disponibles.
Ceci ne demande pas aux unités modifiées de recharger leurs propres configurations (consultez l'action
Recharger
).
Par exemple, si sa section
[Install]
a été modifiée depuis sa dernière activation.
À 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
Arrêter et mettre le système hors tension
systemctl poweroff
Suspendre le système
systemctl suspend
Mettre le système en hibernation (écrire la RAM sur le disque)
systemctl hibernate
Mettre le système en état de sommeil hybride (également appelé suspendre à la fois, il sauvegarde la RAM sur le disque et suspend ensuite))
systemctl hybrid-sleep
Suspendre d'abord le système, puis le réveiller après une durée configurée afin de le mettre en hibernation.
systemctl suspend-then-hibernate
Effectuer un redémarrage de l'espace utilisateur uniquement avec un
#Soft reboot
.
systemctl soft-reboot
Soft reboot
Le soft reboot, ou redémarrage à chaud, est un type particulier d'opération de redémarrage de l'espace utilisateur qui n'implique pas le noyau. Il est implémenté par
systemd-soft-reboot.service(8)
et peut être invoqué par
systemctl soft-reboot
. Comme avec
kexec
, il saute la réinitialisation du firmware, mais en plus le système ne passe pas par l'initialisation du noyau et
initramfs
, et les périphériques
dm-crypt
déverrouillés restent connectés.
Lorsque
/run/nextroot/
contient une structure de système de fichiers racine valide (par exemple, le montage racine d'une autre distribution ou d'un autre snapshot), le
soft-reboot
fait basculer la racine du système dans cette structure, ce qui permet de passer à une autre installation sans perdre les états gérés par le noyau, par exemple le
réseau
(en).
Tip
/run/nextroot/
n'est pas nécessairement un point de montage ou un périphérique physique. Par exemple, il peut résider dans le tmpfs
/run/
.
systemd
transformera automatiquement
/run/nextroot/
en point de montage lors d'un
soft reboot
.
Note
Vous ne devez pas utiliser
systemctl soft-reboot
après des mises à jour de paquets impliquant le noyau et initramfs.
É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 d'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
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 («drop-in files») 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
--drop-in=
drop_in_name
Cela ouvre le fichier
/etc/systemd/system/
unit
.d/
drop_in_name
.conf
dans votre éditeur de texte (en le créant si nécessaire) et recharge automatiquement l'unité lorsque vous avez terminé l'édition. En omettant l'option
--drop-in=
, systemd utilisera le nom de fichier par défaut
override.conf
.
Note
La clé doit toujours être placée dans la section appropriée du fichier de remplacement.
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
, 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.
Changer 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 :
Paramètre du noyau indiqué ci-dessus
Symlink de
/etc/systemd/system/default.target
Lien symbolique de
/usr/lib/systemd/system/default.target
Composants de systemd
Quelques composants (non exhaustifs) de
systemd
sont :
kernel-install
— a script used to automatically move
kernels
and their respective
initramfs
images to the boot partition;
systemd-boot
- simple
gestionnaire d'amorçage
UEFI ;
systemd-creds
— to securely store and retrieve credentials used by systemd units;
systemd-cryptenroll
— Enroll PKCS#11, FIDO2, TPM2 token/devices to LUKS2 encrypted volumes;
systemd-firstboot
- initialisation des paramètres de base du système avant le premier démarrage ;
systemd-homed
-
comptes utilisateurs
humains portables ;
systemd-logind(8)
-
gestion de session
;
systemd-networkd
- gestion de la
configuration réseau
;
systemd-nspawn
- conteneurs léger ;
systemd-resolved (Français)
-
résolution de nom de domaine
;
systemd-sysusers(8)
- crée les utilisateurs et les groupes du système et ajoute les utilisateurs aux groupes à l'installation du paquet ou au démarrage ;
systemd-timesyncd
- synchronisation du
temps système
à travers le réseau ;
systemd/Journal
- journalisation du système ;
systemd/Timers
- minuteries monotones ou en temps réel pour contrôler les fichiers
.service
ou les événements, alternative raisonnable à
Cron
.
systemd-stub(7)
- Un «stub» de démarrage UEFI utilisé pour créer des
images de noyau unifiées
.
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.
Le point de montage
/efi
doit être créé manuellement (si besoin), sinon
systemd-gpt-auto-generator
utilisera
/boot
.
Attention
Soyez très prudent lorsque vous créez
/efi
sur un système existant en utilisant le montage automatique GPT.
/efi
sera utilisé comme point de montage par défaut au prochain démarrage, ce qui pourrait laisser votre système dans un état incohérent avec un répertoire
/boot
vide. Vous devrez probablement réinstaller votre (vos) noyau(x) et/ou votre microcode, régénérer vos initramfs, etc...
Astuce
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
Il est possible d'écrire plusieurs lignes dans le même fichier, soit avec
\n
en argument, soit en utilisant le type
w+
sur plusieurs lignes (y compris la première) pour l'
appending
:
/etc/tmpfiles.d/disable-usb-wake.conf
#    Chemin               Mode UID  GID  Age Argument
w+   /proc/acpi/wakeup     -    -    -    -   USBE
w+   /proc/acpi/wakeup     -    -    -    -   LID0
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
This article or section needs expansion.
Reason:
Nous devrions documenter explicitement quelque part les avantages de l'activation de socket par rapport au démarrage d'un service fictif. Ceci est mentionné brièvement au début de la page et dans des pages connexes comme
Avahi
(Discuss in
Talk:Systemd (Français)
)
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
||
systemdgenie
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
After=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
.(Sauf si vous utilisez
netctl-auto
; voir
FS#75836
).
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, voir la discussion dans
Network configuration synchronization points
.
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é :
CapabilityBoundingSet
définit une liste de
capabilities(7)
qui sont autorisées ou refusées pour une unité. Consultez
systemd.exec(5) § CAPABILITIES
.
La capacité
CAP_SYS_ADM
, par exemple, qui devrait être l'un des
objectifs d'un bac à sable sécurisé
:
CapabilityBoundingSet=~ CAP_SYS_ADM
.
Notification de l'échec d'un service
This article or section is a candidate for merging with
systemd/Timers#MAILTO
.
Notes:
Même sujet, solution différente. (Discuss in
Talk:Systemd (Français)
)
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 la récurrence du démarrage des instances de
failure-notification@.service
en cas d'échec du démarrage, créez un fichier de configuration de dépôt vide portant 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ésactiver automatiquement un disque dur externe à la mise hors tension
This article or section is a candidate for merging with
Udisks#Troubleshooting
.
Notes:
Ceci est principalement centré sur l'utilisation des
udisks
, il est probablement plus approprié pour ce contenu plutôt que de le mettre dans la page systemd. (Discuss in
Talk:Systemd (Français)
)
Si un disque dur externe n'est pas correctement mis hors tension lors de l'arrêt du système, il peut être souhaitable de résoudre le problème. La manière la plus pratique de le faire est d'utiliser
udisks
Activer
udisks2.service
.
Un service permettant de lancer notre script pourrait ressembler à ceci :
/etc/systemd/system/handle_external_hdds.service
[Unit]
Requires=udisks2.service
Requires=graphical.target
After=graphical.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStop=/usr/local/bin/handle_external_hdds.sh

[Installation]
WantedBy=graphical.target
Activer
handle_external_hdds.service
Faites un
daemon-reload
systemd pour appliquer le nouveau paramètre.
Redémarrez
graphical.target
pour vérifier si cela fonctionne.
Un exemple de script pour gérer un nombre arbitraire de partitions sur un seul disque ressemble à ceci :
/usr/local/bin/handle_external_hdds.sh
#!/bin/bash -u

declare -a uuids=(
uuid_list
)

# Ne procéder que si le lecteur est présent.

if [[ ! -L "/dev/disk/by-uuid/${uuids[0]}" ]]; then
  exit 0
fi
for uuid in "${uuids[@]}"; do
  if findmnt "/dev/disk/by-uuid/$uuid"; then
    umount "/dev/disk/by-uuid/$uuid"
  fi
done

# udisksctl éteint le lecteur approprié même si sa partition est alimentée

udisksctl power-off -b "/dev/disk/by-uuid/${uuids[0]}"
uuid_list
est une liste d'UUIDs délimités par des espaces correspondant aux partitions du périphérique à vérifier, par exemple
"
uuid_1
" "
uuid_2
"
.
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
Wikipedia:systemd
Site web officiel
optimisations de systemd
FAQ de systemd
Trucs et astuces de systemd
systemd(1)
Autres distributions
Gentoo:Systemd
Fedora:Systemd
Fedora:Comment déboguer les problèmes de Systemd
Fedora:SysVinit à Systemd Cheatsheet
Debian:systemd
L'histoire sur le blog de Lennart
,
mise à jour 1
,
mise à jour 2
,
mise à jour 3
,
Sommaire
Debugger les Services Systemd
systemd pour les administrateurs (PDF)
Comment utiliser Systemctl pour gérer les services et unités Systemd
Gestion des sessions avec systemd-logind
Coloration syntaxique pour les fichiers systemd avec Emacs
Deux
parties
d'un article d'introduction dans le magazine
The H Open
.