Provided by: manpages-fr_4.26.0-1_all 
NOM
systemd, init – Gestionnaire de services et de système systemd
SYNOPSIS
/usr/lib/systemd/systemd [OPTIONS...]
init [OPTIONS...] {COMMANDE}
DESCRIPTION
systemd est un gestionnaire de services et de système pour les systèmes d'exploitation Linux. Lancé comme
premier processus (PID 1) lors de l'amorçage, il agit comme un système init qui met en place et
entretient les services de l'espace utilisateur. Des instances distinctes sont lancées pour les
utilisateurs connectés afin de démarrer leurs services.
systemd n'est généralement pas appelé directement par l'utilisateur, mais est installé comme lien
symbolique /sbin/init et démarré au tout début de l'amorçage du système. Les instances du gestionnaire
d'utilisateurs sont démarrées automatiquement avec le service user@.service(5).
Pour la compatibilité avec SysV, si le binaire est appelé comme init et n'est pas le premier processus de
la machine (son PID n'est pas 1), cela exécutera telinit et passera tous les arguments de la ligne de
commande sans modification. Cela signifie que init et telinit sont quasiment équivalents lorsqu'ils sont
appelés d'une session de connexion normale. Consulter telinit(8) pour davantage d'informations.
Lorsqu'il est exécuté en tant qu'instance du système, systemd interprète le fichier de configuration
system.conf et les fichiers des répertoires system.conf.d. Lorsqu’utilisé comme instance utilisateur,
systemd interprète le fichier de configuration user.conf et les fichiers dans les répertoires
user.conf.d. Consulter systemd-system.conf(5) pour plus d'informations.
systemd contient des implémentations natives de différentes tâches qui doivent être exécutées lors du
processus d'amorçage. Par exemple, il définit le nom d'hôte ou configure le périphérique loopback de
réseau. Il définit aussi et monte divers systèmes de fichier d'API, tels que /sys/ ou /proc/ et /dev/.
systemd réinitialisera aussi l'horloge système au tout début de l'amorçage si elle paraît être réglée de
façon incorrecte. Voir la section « Epoch de l'horloge système » ci-dessous.
Notez que certaines, mais pas toutes, interfaces fournies par systemd sont couvertes par la Portabilité
d'interface et promesse de stabilité[1].
L'API D-Bus de systemd est décrite dans org.freedesktop.systemd1(5) et org.freedesktop.LogControl1(5).
Les systèmes qui invoquent systemd dans un conteneur ou un environnement initrd devraient implémenter les
spécifications Interface conteneur[4] ou Interface initrd[5], respectivement.
UNITÉS
systemd offre un système de dépendances entre diverses entités appelées « unités » de onze types
différents. Les unités encapsulent divers objets utiles à l'amorçage du système et à son entretien. La
majorité des unités sont configurées dans des fichiers de configuration d'unité dont la syntaxe et
l'ensemble basique des options sont décrits dans systemd.unit(5), néanmoins d'autres sont créées
automatiquement à partir d'autres fichiers de configuration, dynamiquement depuis l'état du système ou de
manière programmable au moment de l'exécution. Les unités peuvent avoir différents états décrits dans la
table ci-dessous. Prenez en compte que les divers types d'unités peuvent avoir un certain nombre de
sous-états supplémentaires qui sont mappés dans les états généraux d'unités décrits ici.
Table 1. états d’ACTIVITÉ des unités
┌──────────────┬───────────────────────────────────────┐
│ État │ Description │
├──────────────┼───────────────────────────────────────┤
│ active │ Démarrée, liée, branchée,..., suivant │
│ │ le type d'unité. │
├──────────────┼───────────────────────────────────────┤
│ inactive │ Stoppée, non liée, débranchée,..., │
│ │ suivant le type d'unité. │
├──────────────┼───────────────────────────────────────┤
│ failed │ Similaire à inactive, mais l'unité a │
│ │ échoué quelque part (processus │
│ │ renvoyant un code d’erreur, plantage, │
│ │ opération expirée ou après trop de │
│ │ redémarrages). │
├──────────────┼───────────────────────────────────────┤
│ activating │ Modification d’inactive en active. │
├──────────────┼───────────────────────────────────────┤
│ deactivating │ Modification d’active en inactive. │
├──────────────┼───────────────────────────────────────┤
│ maintenance │ L'unité est inactive et une opération │
│ │ d’entretien est en cours. │
├──────────────┼───────────────────────────────────────┤
│ reloading │ L'unité est active et est en cours de │
│ │ recharge de configuration. │
├──────────────┼───────────────────────────────────────┤
│ refreshing │ L'unité est active et un nouveau │
│ │ montage a été activé dans son espace │
│ │ de noms.. │
└──────────────┴───────────────────────────────────────┘
Les types d'unité suivants sont disponibles :
1. Les unités service, qui démarrent et contrôlent les démons et les processus qui les composent. Pour
plus d'informations, consulter systemd.service(5).
2. Les unités socket, qui encapsulent les IPC (inter-process communication) locaux ou les sockets réseau
du système, pratiques pour l'activation basée socket. Pour d'avantage de détails sur les unités
socket, voir systemd.socket(5), pour des détails sur l'activation basée socket et d'autres formes
d'activation, voir daemon(7).
3. Les unités cible sont utiles pour les unités groupe ou pour fournir des points de synchronisation
bien connus durant l'amorçage, consulter systemd.target(5).
4. Les unités périphérique exposent les périphériques du noyau dans systemd et devraient être utilisées
pour implémenter l'activation basée périphérique. Pour plus de détails, consulter systemd.device(5).
5. Les unités montage contrôlent les points de montage dans le système de fichiers, pour les détails
voir systemd.mount(5).
6. Les unités automontage fournissent des capacités d'automontage, pour les montages à la demande de
systèmes de fichiers ainsi que pour l'amorçage en parallèle. Consulter systemd.automount(5).
7. Les unités timer sont utiles pour déclencher l'activation d'autres unités basées sur les
temporisateurs. Vous devriez trouver des détails dans systemd.timer(5).
8. Les unités swap sont semblables aux unités de montage et encapsulent les partitions ou les fichiers
de mémoire d'échange du système d'exploitation. Elles sont décrites dans systemd.swap(5).
9. Les unités path devraient être utilisées pour activer d'autres services lorsque les objets du système
de fichiers changent ou sont modifiés. Consulter systemd.path(5).
10. Les unités slice devraient être utilisées pour grouper les unités qui gèrent le fonctionnement du
système (comme les unités service et scope) dans un arbre hiérarchique pour des besoins de gestion de
ressources. Consulter systemd.slice(5).
11. Les unités scope sont identiques aux unités service, mais gèrent les processus extérieurs au lieu de
les démarrer également. Voir systemd.scope(5).
Les unités sont nommées en fonction de leurs fichiers de configuration. Quelques unités ont une
sémantique spéciale. Consulter systemd.special(7) pour une liste détaillée.
systemd reconnait différentes sortes de dépendances, incluant les dépendances positives ou négatives
d’exigence (c.à-d. Requires= et Conflicts=) tout comme les dépendances ordonnées (After= et Before=).
Remarquez que l'ordre et la requête de dépendances sont indépendants. Si seulement une demande de
dépendance existe entre deux unités (par exemple, truc.service demande machin.service), mais sans
dépendance ordonnée (truc.service après machin.service) et que les deux doivent démarrer, alors elles
seront démarrées en parallèle. C'est un modèle courant que des dépendances ordonnées et de requêtes
soient placées entre deux unités. Tenez compte aussi, que la majorité des dépendances sont implicitement
créées et entretenues par systemd. Dans la plupart des cas, il n'est pas nécessaire de déclarer de
dépendances supplémentaires manuellement, toutefois cela reste possible à faire.
Les programmes d'application et les unités (à travers les dépendances) peuvent nécessiter des changements
d'état d'unités. Dans systemd ces requêtes sont encapsulées comme « jobs », et entretenues dans une file
de tâches. Les tâches (jobs) peuvent réussir ou échouer, leur exécution est commandée selon
l'ordonnancement des dépendances des unités pour lesquelles elles ont été planifiées.
À l'amorçage systemd active l'unité target default.target dont la tâche est d'activer les services à
l'amorçage et autres unités à l'amorçage en les requérant à travers des dépendances. Habituellement, le
nom d'unité est juste un alias (lien symbolique) pour soit graphical.target (pour un amorçage des plus
complets dans l'interface utilisateur) ou multi-user.target (pour des amorçages uniquement en console,
pour une utilisation dans des environnements embarqués ou de serveurs, ou similaires ; un sous-ensemble
de graphical.target). Cependant, cela reste à la discrétion de l'administrateur de le configurer comme un
alias pour toute autre unité target. Voir systemd.special(7) pour plus de détails sur les unités target.
Lors du premier amorçage, systemd activera ou désactivera les unités selon une politique préétablie. Voir
systemd.preset(5) et « First Boot Semantics » dans machine-id(5).
systemd ne conserve qu'un ensemble minimal d'unités chargées en mémoire. Spécifiquement, les seules
unités chargées en mémoire sont celles pour lesquelles au moins l'une de ces conditions est vraie :
1. Elle est dans un état actif, activation, désactivation ou en échec (c'est-à-dire tout état d'unité
excepté « inactif »)
2. Elle possède une file de tâches pour ça
3. Elle est une dépendance pour au moins une autre unité chargée en mémoire
4. Elle dispose d'une certaine forme de ressource encore allouée (p.ex une unité service qui est
inactive mais pour laquelle un processus perdure qui a ignoré la demande d'arrêt).
5. Elle a été attachée en mémoire par programmation avec un appel à D-Bus
systemd chargera automatiquement et implicitement les unités du disque (si elles ne sont pas déjà
chargées) dès qu'elles seront demandées par les opérations en cours. Cependant, sous bien des aspects, le
fait qu'une unité soit chargée ou pas reste invisible aux clients. Utilisez systemctl list-units --all
pour lister de manière compréhensible toutes les unités actuellement chargées. Toute unité pour laquelle
aucune des conditions ci-dessus ne s'applique est dès que possible déchargée. Remarquez que lorsqu'une
unité est déchargée de la mémoire, ses données comptables sont vidées aussi. De toute manière, ces
données ne sont généralement pas perdues, vu qu'un enregistrement de journal est généré déclarant les
ressources consommées chaque fois qu'une unité s'éteint.
Les processus créés par systemd sont placés dans des groupes de contrôle Linux individuels nommés d'après
l'unité à laquelle ils appartiennent dans la hiérarchie privée de systemd.(voir Groupes de contrôle v2[1]
pour plus d'informations sur les groupes de contrôle ou « cgroups »). systemd utilise cela pour garder
une trace effective des processus. L'information du groupe de contrôle est entretenue dans le noyau, et
est accessible à l'aide de la hiérarchie du système de fichiers (sous /sys/fs/cgroup/), ou des outils
comme systemd-cgls(1) ou ps(1) (ps xawf -eo pid,user,cgroup,args est particulièrement utile pour lister
tous les processus et les unités systemd auxquelles ils appartiennent).
systemd est compatible avec le système init de SysV dans un large degré : les scripts init de SysV sont
pris en charge et simplement lus comme une alternative (avec des limites) au format des fichiers de
configuration. L'interface /dev/initctl de SysV est fournie et des implémentations compatibles des divers
outils client SysV sont disponibles. En plus de cela, différentes fonctionnalités Unix implantées comme
/etc/fstab ou la base de données utmp sont prises en charge.
systemd a un système de transactions minimal : si une unité a besoin de démarrer ou de s'éteindre, il
l'ajoutera ainsi que ses dépendances dans une transaction temporaire. Alors, il vérifiera la cohérence de
la transaction (c'est-à-dire si l'ordre de toutes les unités est sans cycle). Sinon, systemd essaiera de
la réparer, et supprimera les tâches non essentielles de la transaction qui pourraient supprimer la
boucle. Aussi, systemd essaie de supprimer les tâches dans la transaction qui pourraient stopper un
service en fonctionnement. Finalement, il vérifie si les tâches de la transaction rentrent en
contradiction avec d'autres tâches déjà dans la liste d'attente, et facultativement la transaction est
annulée. Si tout va bien et que la transaction est cohérente et minime dans son impact, elle est intégrée
aux autres tâches en attente et ajoutée à la liste d'exécution. Dans les faits, cela signifie qu'avant
d'exécuter une opération demandée systemd vérifiera que cela a du sens, la réparera si possible, et
n'échouera que si vraiment cela ne peut pas fonctionner.
Remarquez que les transactions sont générées indépendamment de l'état de l'unité au moment du
fonctionnement, ainsi, par exemple, si une tâche de démarrage est demandée sur une unité déjà démarrée,
elle générera toujours une transaction et réveillera toutes les dépendances inactives (et provoquera la
propagation d'autres tâches conformément aux relations définies). En effet, la tâche mise en file
d'attente est comparée, au moment de l'exécution, à l'état de l'unité cible et est considérée comme
réussie et terminée lorsque les deux exigences sont satisfaites. Toutefois, cette tâche attire également
d'autres dépendances en raison des relations définies et entraîne donc, dans notre exemple, des tâches de
démarrage pour n'importe laquelle de ces unités inactives alors aussi mises en file d'attente.
Les unités peuvent être générées dynamiquement au moment du démarrage et du rechargement du gestionnaire
de système, par exemple sur la base d'autres fichiers de configuration ou de paramètres transmis sur la
ligne de commande du noyau. Pour les détails, voir systemd.generator(7).
RÉPERTOIRES
Répertoires des unités système
Le gestionnaire de système systemd lit à partir de nombreux répertoires la configuration des unités.
Les paquets qui désirent installer des fichiers d'unité devraient les placer dans le répertoire
renvoyé par pkg-config systemd --variable=systemdsystemunitdir. Les autres répertoires vérifiés sont
/usr/local/lib/systemd/system et /usr/lib/systemd/system. La configuration de l'utilisateur a
toujours la préséance. pkg-config systemd --variable=systemdsystemconfdir renvoie le chemin du
répertoire de la configuration du système. Les paquets ne modifieront le contenu de ces répertoires
seulement avec les commandes enable et disable de l'outil systemctl(1). La liste de l'ensemble des
répertoires est fournie dans systemd.unit(5).
Répertoires de l'unité utilisateur
Des règles similaires s'appliquent aux répertoires utilisateur de l'unité. Là néanmoins, la
Spécification du répertoire de base XDG[6] est suivie pour trouver les unités. Les applications
devraient placer leurs fichiers d'unité dans le répertoire renvoyé par pkg-config systemd
--variable=systemduserunitdir. La configuration globale est faite dans le répertoire mentionné par
pkg-config systemd --variable=systemduserconfdir. Les commandes enable et disable de l'outil
systemctl(1) peuvent gérer l'activation ou la désactivation d'unités globalement (c'est-à-dire pour
tous les utilisateurs) ou en privé (pour un utilisateur). La liste complète des répertoires est
fournie dans systemd.unit(5).
Répertoire des scripts init de SysV
L'emplacement du répertoire de script init de SysV varie suivant les distributions. Si systemd ne
peut pas trouver de fichier d'unité natif pour un service demandé, il cherchera un script init de
SysV du même nom (avec le suffixe .service enlevé).
Répertoire de ferme de liens de niveau d'exécution de SysV
L'emplacement du répertoire de la ferme de liens de niveau d'exécution de SysV varie entre les
distributions. systemd prendra en compte cette ferme de liens pour savoir si un service doit être
activé. Notez qu'une unité service avec un fichier de configuration natif ne peut pas être démarrée
en l'activant dans la ferme de lien de niveau d'exécution de SysV.
SIGNAUX
Le service écoute divers signaux de processus UNIX qui peuvent être utilisés pour demander différentes
actions de manière asynchrone. La gestion du signal est activée très tôt lors du démarrage, avant que
tout autre processus ne soit invoqué. Néanmoins, un gestionnaire de supervision de conteneur ou similaire
qui veut demander ces opérations à travers ce mécanisme doit prendre en compte que cette fonctionnalité
n'est pas disponible lors de la phase première d'initialisation. Un message de notification sd_notify()
portant le champ X_SYSTEMD_SIGNALS_LEVEL=2 n'est émis qu'une fois les gestionnaires de signaux activés ;
voir ci-dessous. Cela est utilisé pour planifier correctement la soumission de ces signaux.
SIGTERM
À la réception de ce signal, le gestionnaire de système systemd sérialise son état, s'exécute à
nouveau et désérialise à nouveau l'état sauvegardé. Cela est quasiment équivalent à systemctl
daemon-reexec.
Les gestionnaires d'utilisateur de systemd démarreront l'unité exit.target quand le signal est reçu.
Cela est quasiment équivalent à systemctl --user start exit.target --job-mode=replace-irreversibly.
SIGINT
À la réception de ce signal, le gestionnaire de système systemd démarre l'unité ctrl-alt-del.target.
Cela est quasiment l'équivalent de
systemctl start ctrl-alt-del.target --job-mode=replace=irreversibly. Si ce signal est reçu plus de
sept fois en deux secondes, un réamorçage (reboot) immédiat est déclenché. Remarquez que presser
Ctrl+Alt+Suppr sur la console déclenchera ce signal. Par conséquent, si un réamorçage est suspendu,
presser Ctrl+Alt+Suppr plus de sept fois en deux secondes est une manière relativement sûre pour
déclencher un réamorçage immédiat.
Les gestionnaires d'utilisateur de systemd traitent ce signal de la même manière que SIGTERM.
SIGWINCH
Lorsque ce signal est reçu, le gestionnaire de système systemd démarrera l'unité kbrequest.target.
Cela est quasiment équivalent à systemctl start kbrequest.target.
Ce signal est ignoré par les gestionnaires d'utilisateur de systemd.
SIGPWR
Lorsque ce signal est reçu, le gestionnaire systemd démarrera l'unité sigpwr.target. C'est quasiment
équivalent à systemctl start sigpwr.target.
SIGUSR1
Le gestionnaire systemd essaiera de se reconnecter au bus D-Bus à la réception de ce message.
SIGUSR2
Lorsque ce signal est reçu, le gestionnaire systemd journalisera son état complet sous une forme
humainement lisible. Les données journalisées sont les mêmes que celles affichées par
systemd-analyze dump.
SIGHUP
Rechargement de la configuration complète du démon. Cela est quasiment équivalent à systemctl
daemon-reload.
SIGRTMIN+0
Entrer en mode par défaut, démarrer l'unité default.target. Cela est quasiment équivalent à systemctl
isolate default.target.
SIGRTMIN+1
Entrer en mode de secours (rescue), démarrer l'unité rescue.target. Cela est quasiment équivalent à
systemctl isolate rescue.target.
SIGRTMIN+2
Entrer en mode urgence, démarrer l'unité emergency.service. Cela est quasiment équivalent à systemctl
isolate emergency.service.
SIGRTMIN+3
Arrêter la machine, démarrer l'unité halt.target. Cela est quasiment équivalent à systemctl start
halt.target --job-mode=replace-irreversibly.
SIGRTMIN+4
Éteindre la machine, démarrer l'unité poweroff.target. Cela est quasiment équivalent à systemctl
start poweroff.target --job-mode=replace-irreversibly.
SIGRTMIN+5
Réamorcer la machine, démarrer le réamorçage des unités reboot.target. Cela est quasiment équivalent
à systemctl start reboot.target --job-mode=replace-irreversibly.
SIGRTMIN+6
Réamorcer la machine à l'aide de kexec, démarrer les unités kexec.target. Cela est quasiment
équivalent à systemctl start kexec.target --job-mode=replace-irreversibly.
SIGRTMIN+7
Réamorcer l'espace utilisateur, démarrer le réamorçage de l'unité soft-reboot.target . Cela est
quasiment équivalent à systemctl start soft-reboot.target --job-mode=replace-irreversibly.
Ajouté dans la version 254.
SIGRTMIN+13
Arrêter la machine immédiatement.
SIGRTMIN+14
Éteindre la machine immédiatement.
SIGRTMIN+15
Réamorcer immédiatement la machine.
SIGRTMIN+16
Réamorcer immédiatement la machine avec kexec.
SIGRTMIN+17
Réamorcer immédiatement l'espace utilisateur
Ajouté dans la version 254.
SIGRTMIN+20
Activer l'affichage des messages d'état sur la console, comme contrôlé à l'aide de
systemd.show_status=1 sur la ligne de commande du noyau.
Vous pouvez préférer utiliser SetShowStatus() au lieu de SIGRTMIN+20 pour prévenir les situations de
compétition. Voir org.freedesktop.systemd1(5).
SIGRTMIN+21
Désactiver l'affichage des messages d'état sur la console, comme contrôlé à l'aide de
systemd.show_status=0 sur la ligne de commande du noyau.
Vous pouvez préférer utiliser SetShowStatus() au lieu de SIGRTMIN+21 pour prévenir les situations de
compétition. Voir org.freedesktop.systemd1(5).
SIGRTMIN+22
Définir le niveau de journal du gestionnaire de services à « debug », d'une manière équivalente à
systemd.log_level=debug sur la ligne de commande du noyau.
SIGRTMIN+23
Restaurer le niveau de journalisation à sa valeur configurée. La valeur configurée est dérivée de –
dans l'ordre de priorité – la valeur spécifiée avec systemd.log-level= sur la ligne de commande du
noyau, ou la valeur spécifiée avec LogLevel= dans le fichier de configuration ou celle interne par
défaut de « info ».
Ajouté dans la version 239.
SIGRTMIN+24
Sortie immédiate du gestionnaire (disponible seulement pour --user instances).
Ajouté dans la version 195.
SIGRTMIN+25
Dès réception de ce message le gestionnaire systemd s'exécutera à nouveau de lui-même. C'est
quasiment équivalent à systemctl daemon-reexec sauf que cela sera fait de manière asynchrone.
Le gestionnaire systemd traite ce signal de la même façon que SIGTERM.
Ajouté dans la version 250.
SIGRTMIN+26
Restaurer la cible journal à sa valeur configurée. La valeur configurée est dérivée de – dans l'ordre
de priorité – la valeur spécifiée avec systemd.log.target= sur la ligne de commande du noyau, ou est
la valeur spécifiée avec LogTarget= dans le fichier de configuration ou celle interne par défaut.
Ajouté dans la version 239.
SIGRTMIN+27, SIGRTMIN+28
Définir la cible journal à « console » pour SIGRTMIN+27 (ou « kmsg » pour SIGRTMIN+28), d'une manière
équivalente à systemd.log_target=console (ou systemd.log_target=kmsg pour SIGRTMIN+28) sur la ligne
de commande du noyau.
Ajouté dans la version 239.
ENVIRONNEMENT
Le bloc d'environnement du gestionnaire de système est initialement défini par le noyau. (En particulier,
les assignations « clé=valeur » de la ligne de commande du noyau sont changées en variables
d'environnement pour le PID 1). Pour le gestionnaire d'utilisateurs, le gestionnaire système définit
l'environnement comme décrit dans la section « Environment Variables in Spawned Processes » (« Variables
d'environnement dans les processus créés ») de systemd.exec(5). Le réglage DefaultEnvironment= du
gestionnaire du système s'applique à tous les services, incluant user@.service. Des entrées
supplémentaires peuvent être configurées (comme pour tout autre service) avec les réglages Environment=
et EnvironmentFile= pour user@.service (voir systemd.exec(5)). De même, des variables d'environnement
peuvent être définies avec le réglage de ManagerEnvironment= dans systemd-system.conf(5) et
systemd-user.conf(5).
Quelques variables interprétables par systemd :
$SYSTEMD_LOG_LEVEL
Le niveau maximal de journalisation de messages émis (messages avec un niveau de journalisation
supérieur, c'est-à-dire les moins importants seront supprimés). Cette variable prend une liste de
valeurs séparées par des virgules. Une valeur peut être (par ordre d'importance décroissante) emerg,
alert, crit, err, warning, notice, info, debug ou un entier dans l’intervalle 0...7. Consultez
syslog(3) pour davantage d'informations. Chaque valeur peut être optionnellement préfixée avec
console, syslog, kmsg ou journal suivi d'un deux-points (:) pour définir le niveau de journalisation
maximal pour la cible spécifique de journal (par exemple SYSTEMD_LOG_LEVEL=debug,console:info indique
de journaliser au niveau debug excepté pour la journalisation vers la console qui doit s'effectuer au
niveau info). Notez que le niveau maximal de journalisation globale est prioritaire sur tout niveau
maximal de journalisation par cible.
Cela peut-être écrasé par -log-level=.
$SYSTEMD_LOG_COLOR
Un booléen. Si la valeur est vrai, les messages écrits sur le terminal seront colorés selon la
priorité.
Cela peut être écrasé avec -log-color=.
$SYSTEMD_LOG_TIME
Un booléen. Si la valeur est vrai, les messages du journal de la console seront préfixés d'un
horodatage.
Cela peut être écrasé avec -log-time=.
Ajouté dans la version 246.
$SYSTEMD_LOG_LOCATION
Un booléen. Si la valeur est vrai, les messages seront préfixés par un nom de fichier et du numéro de
ligne du code source d'où vient le message.
Cela peut être écrasé avec -log-location=.
$SYSTEMD_LOG_TID
Un booléen. Si la valeur est vrai, les messages seront préfixés par l'identifiant numérique du thread
actuel (TID).
Ajouté dans la version 247.
$SYSTEMD_LOG_TARGET
Destination pour journaliser les messages. Une des destinations parmi console (journaliser dans le
terminal attaché), console-prefixed (journaliser dans le terminal attaché, mais avec des préfixes qui
codent le niveau et le « service » de journalisation, consultez syslog(3)), kmsg (journaliser dans le
tampon de journalisation circulaire du noyau), journal (journaliser dans le journal), journal-or-kmsg
(journaliser dans le journal s'il est disponible et sinon dans kmsg), auto (déterminer
automatiquement la cible appropriée de journalisation, c'est la destination par défaut), null
(désactive la sortie de journalisation).
Cela peut être écrasé avec -log-target=.
$SYSTEMD_LOG_RATELIMIT_KMSG
Que ce soit pour le taux de requête kmsg ou pas. Prend un booléen. Par défaut « true ». Si désactivé,
systemd ne limitera pas le taux des messages écrits à kmsg.
Ajouté dans la version 254.
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
Le gestionnaire utilisateur de systemd utilise ces variables en accord avec la XDG Base Directory
specification[6] pour sa configuration.
$SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH, $SYSTEMD_ENVIRONMENT_GENERATOR_PATH
Pour contrôler où systemd cherche les fichiers d'unité et les générateurs.
Ces variables peuvent contenir une liste de chemins, séparés par des deux-points (:). Lorsque
définie, si la liste se termine avec un composant vide (« ...: »), cette liste est préfixée avec la
l’ensemble habituel des chemins. Sinon, la liste indiquée remplace l’ensemble habituel des chemins.
$SYSTEMD_PAGER
Afficheur à utiliser lorsque --no-pager n'est pas précisé ; outrepasse $PAGER. Si ni $SYSTEMD_PAGER,
ni $PAGER n'ont de valeur, un ensemble d’afficheurs bien connus sont essayés à tour de rôle, incluant
less(1) et more(1), jusqu'à ce qu'il y en ait un qui soit trouvé. Si aucun afficheur n'est trouvé,
aucun afficheur n'est appelé. Définir cette variable d'environnement à une chaîne vide ou à « cat »
est équivalent à l'utilisation de --no-pager.
Remarque : si $SYSTEMD_PAGERSECURE n'est pas défini, $SYSTEMD_PAGER (tout comme $PAGER) sera ignoré
silencieusement.
$SYSTEMD_LESS
Outrepasser les options passées à less (par défaut « FRSXMK »).
Les utilisateurs voudront peut-être changer deux options en particulier :
K
Cette option ordonne à l’afficheur de quitter immédiatement lorsque Ctrl+C est entré. Pour
permettre à less de gérer Ctrl+C lui-même le retour à l'invite de commande de l’afficheur, ne pas
fournir cette option.
Si la valeur de $SYSTEMD_LESS n'inclut pas « K » et si l’afficheur appelé est less, Ctrl+C sera
ignoré par l'exécutable et doit être géré par l’afficheur.
X
Cette option ordonne à l’afficheur de ne pas envoyer les chaînes d'initialisation et de
désinitialisation de termcap au terminal. C'est le choix par défaut afin de permettre aux sorties
des commandes de rester visibles dans le terminal même après que l’afficheur soit fermé.
Toutefois, cela empêche quelques fonctionnalités de l’afficheur de fonctionner, en particulier,
il n'est pas possible de faire défiler les sorties affichées avec la souris.
Notez que le réglage de la variable d'environnement $LESS normale n'a aucun effet sur les invocations
de less par les outils de systemd.
Voir less(1) pour plus de détails.
$SYSTEMD_LESSCHARSET
Outrepasser le jeu de caractères passé à less (par défaut « utf-8 », si le terminal invoqué est
compatible avec l'UTF-8).
Notez que le réglage de la variable d'environnement $LESSCHARSET normale n'a aucun effet sur les
invocations de less par les outils de systemd.
$SYSTEMD_PAGERSECURE
Prend un argument booléen. Quand c'est « vrai », le mode « secure » de l'afficheur est activé et
quand c'est « faux », il est désactivé. Si $SYSTEMD_PAGERSECURE n'est pas du tout défini, le mode
« secure » est activé si l'UID effectif n'est pas le même que celle du propriétaire de la session
connectée, consulter geteuid(2) et sd_pid_get_owner_uid(3). En mode « secure », LESSSECURE=1 sera
défini lors de l'invocation de l'afficheur, et l'afficheur désactivera les commandes qui ouvrent ou
créent de nouveaux fichiers ou lancent de nouveaux sous-processus. Quand $SYSTEMD_PAGERSECURE n'est
pas du tout défini, les afficheurs qui ne sont pas reconnus comme implémentant le mode « secure » ne
seront pas utilisés. (Actuellement seul less(1) implémente le mode « secure ».)
Note : quand des commandes sont invoquées avec des privilèges élevés, par exemple avec sudo(8) ou
pkexec(1), des précautions doivent être prises pour s'assurer que des fonctions interactives
indésirables ne sont pas activées. Le mode « Secure » de l'afficheur interactif peut être activé
automatiquement comme décrit plus haut. Définir SYSTEMD_PAGERSECURE=0 ou ne pas le supprimer de
l'environnement hérité autorise l'utilisateur à invoquer des commandes arbitraires. Notez que si les
variables $SYSTEMD_PAGER ou $PAGER doivent être respectées, $SYSTEMD_PAGERSECURE doit aussi être
défini. Il pourrait être raisonnable de désactiver complètement l'afficheur interactif en utilisant
plutôt --no-pager.
$SYSTEMD_COLORS
Prend un argument booléen. Quand c'est « vrai », systemd et les utilitaires liés utiliseront la
couleur pour leurs sorties, autrement, la sortie sera monochrome. En plus, la variable peut prendre
une des valeurs spéciales suivantes : 16 ou 256 pour limiter l'usage des couleurs aux couleurs ANSI
base 16 ou base 256 respectivement. Cela peut être précisé pour outrepasser la décision automatique
prise sur $TERM et quel que soit ce à quoi la console est connectée.
$SYSTEMD_URLIFY
La valeur doit être un booléen. Contrôle si les liens cliquables doivent être générés dans la sortie
pour des émulateurs de terminaux le prenant en charge. Cela peut être indiqué pour passer outre la
décision faite par systemd basée sur $TERM et d'autres conditions.
$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
Définition par systemd des processus supervisés lors de l'activation basée socket. Consulter
sd_listen_fds(3) pour plus d'informations.
$NOTIFY_SOCKET
Définie par le gestionnaire de services pour ses services pour les notifications d’état et de
disponibilité. Cette variable est également utilisée par le gestionnaire de services pour notifier
aux gestionnaires de supervision de conteneurs ou aux gestionnaires de services situés au-dessus de
la pile de sa propre progression. Voir sd_notify(3) et la section concernée ci-dessous pour plus
d'informations.
Pour les variables d'environnement supplémentaires comprises par systemd et ses divers composants,
consulter Variables d’environnement connues[7].
LIGNE DE COMMANDE DU NOYAU
Lorsque lancé comme instance système, systemd analyse un certain nombre d'options listées ci-dessous.
Elles peuvent être spécifiées comme arguments de ligne de commande du noyau qui sont analysés de diverses
sources en fonction de l'environnement dans lequel systemd est exécuté. Si lancé dans un conteneur Linux,
ces options sont analysées depuis les arguments de la ligne de commande passés à systemd lui-même, après
n'importe quelle option de ligne de commande listée dans la section OPTIONS ci-dessous. Si lancé hors
d'un conteneur Linux, ces arguments sont analysés depuis /proc/cmdline et sinon depuis la variable EFI
« SystemdOptions » (pour les systèmes EFI). Les options de /proc/cmdline ont une priorité plus haute.
Remarque : l'utilisation de « SystemdOptions » est obsolète.
Les variables suivantes sont comprises :
systemd.unit=, rd.systemd.unit=
Outrepasser l'unité à activer lors de l'amorçage. C'est par défaut default.target. Cela peut être
utilisé pour amorcer temporairement avec une unité d'amorçage différente, par exemple rescue.target
ou emergency.service. Voir systemd.special(7) pour des détails à propos de ces unités. L'option
préfixée avec « rd. » n'est honorée que dans l'initrd, tandis que celle qui n'est pas préfixée n'est
honorée que dans le système principal.
systemd.dump_core
Prend un argument booléen ou active l’option si spécifiée sans argument. Si activé, le gestionnaire
de systemd (PID 1) effectue un vidage du noyau lorsqu'il plante. Sinon, aucun vidage du noyau n'est
créé. La valeur par défaut est « enabled » (activée).
Ajouté dans la version 233.
systemd.crash_chvt
Prend un entier positif ou un argument booléen. Peut aussi être spécifié sans argument, avec le même
effet qu'avec un booléen positif. Si un entier positif (dans la plage 1–63) est indiqué, le
gestionnaire du système (PID 1) activera le terminal virtuel indiqué lorsqu'il plante. Par défaut
désactivé, ce qui signifie que de telles interruptions ne sont pas prévues. Si réglé à activé, le
terminal virtuel sur lequel les messages du noyau sont écrits est utilisé à la place.
Ajouté dans la version 233.
systemd.crash_shell
Prend un argument booléen ou active l'option si indiquée sans aucun argument. Si activé, le
gestionnaire système (PID 1) fait apparaître un interpréteur de commandes lorsqu'il plante.
Autrement, aucun interpréteur de commandes n'apparaît. Désactivé par défaut, pour raisons de
sécurité, car l'interpréteur de commandes n'est pas protégé par une authentification par mot de
passe.
Ajouté dans la version 233.
systemd.crash_action=
Prend un des arguments « freeze », « reboot » ou « poweroff ». Par défaut, c'est « freeze ». Si réglé
à « freeze », le système restera suspendu indéfiniment si le gestionnaire de services (PID 1) plante.
Si réglé sur « reboot », le gestionnaire du système (PID 1) réamorcera la machine automatiquement
lors d'un plantage, après un délai de dix secondes. Si réglé à « poweroff », le gestionnaire de
services (PID 1) éteindra la machine immédiatement après un plantage. Si combiné avec
systemd.crash_shell, l'action de plantage configurée est exécutée après que l'interpréteur de
commandes a quitté.
Ajouté dans la version 256.
systemd.confirm_spawn
Prend un argument booléen ou un chemin vers la console virtuelle où les messages de confirmation
devraient être envoyés. Peut aussi être spécifié sans aucun argument, avec le même effet qu'avec un
booléen positif. Si activé, le gestionnaire du système (PID 1) demande confirmation pour faire
apparaître les processus utilisant /dev/console. Si un chemin ou un nom de console (tel que
« ttyS0 ») est fourni, la console virtuelle pointée par ce chemin ou celui décrit par le nom donné
sera utilisée à la place. Désactivé par défaut.
Ajouté dans la version 233.
systemd.service_watchdogs=
Prend un argument booléen. Si désactivé, tous les chiens de garde d’exécution de service
(WatchdogSet=) et les actions d'urgence (p. ex. OnFailure= ou StartLimitAction=) sont ignorés par le
gestionnaire du système (PID 1) ; consulter systemd.service(5). Activé par défaut, c'est-a-dire les
chiens de garde et les actions d’échec sont exécutés normalement. Le chien de garde matériel n'est
pas affecté par cette option.
Ajouté dans la version 237.
systemd.show_status
Prend un argument booléen ou les constantes error et auto. Peut aussi être spécifié sans argument,
auquel cas, c'est équivalent à l'effet d'un booléen positif. Si activé, le gestionnaire du système
(PID 1) affiche des mises à jour laconiques de l'état des services sur la console pendant le
démarrage. Avec error, seuls les messages d'échec sont affichés, mais sinon l'amorçage est
silencieux. auto se comporte comme false jusqu'à ce qu'il y ait un délai significatif dans
l'amorçage. Activé par défaut, à moins que quiet soit passé comme option sur la ligne de commandes du
noyau, dans lequel cas c'est error par défaut. Si spécifié, cela écrase l'option du fichier de
configuration ShowStatus= du gestionnaire de système, consulter systemd-system.conf(5).
Ajouté dans la version 233.
systemd.status_unit_format=
Prend name, description ou combined comme valeur. Si name, alors le gestionnaire de système utilisera
les noms d'unité dans les messages d'état. Si combined, le gestionnaire de système utilisera les noms
et description d’unité dans les messages d’état. Lorsque spécifié, écrase l'option StatusUnitFormat=
de la configuration du gestionnaire du système, voir systemd-system.conf(5).
Ajouté dans la version 243.
systemd.log_color, systemd.log_level=, systemd.log_location, systemd.log_target=, systemd.log_time,
systemd.log_tid, systemd.log_ratelimit_kmsg
Contrôle la sortie des journaux, avec le même effet que les variables d'environnement
$SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_LOCATION, $SYSTEMD_LOG_TARGET,
$SYSTEMD_LOG_TIME, $SYSTEMD_LOG_TID et $SYSTEMD_LOG_RATELIMIT_KMSG décrites ci-dessus.
systemd.log_color, systemd.log_location, systemd.log_time, systemd.log_tid et
systemd.log_ratelimit_kmsg peuvent être indiquées sans argument, ayant le même effet qu'un booléen
positif.
systemd.default_standard_output=, systemd.default_standard_error=
Contrôle la sortie standard par défaut et les sorties d'erreur pour les services et les sockets.
C’est-à-dire, contrôle la sortie par défaut de StandardOutput= et StandError= (consulter
systemd.exec(5) pour les détails). Prend l'un de inherit, null, tty, journal, journal+console, kmsg,
kmsg+console. Si l'argument est omis, systemd.default-standard-output= sera par défaut journal et
systemd.default-standard-error= inherit.
systemd.setenv=
Prendre un argument chaîne de la forme VARIABLE=VALEUR. Cela peut être utilisé pour définir des
variables d'environnement par défaut à ajouter pour fourcher vers des processus enfant. Peut être
utilisé plus d'une fois pour définir plusieurs variables.
systemd.machine_id=
Prend une valeur hexadécimale de 32 caractères à utiliser pour définir l'ID de la machine. Destiné
principalement au démarrage en réseau, lorsque le même identifiant de machine est souhaité pour
chaque démarrage.
Ajouté dans la version 229.
systemd.set_credential=, systemd.set_credential_binary=
Définit un justificatif d'identité du système, qui peut alors être propagé aux services du système en
utilisant le réglage ImportCredential= ou LoadCredential=, consulter systemd.exec(5) pour plus de
détails. Prend une paire de justificatifs de nom et valeur, séparés par un deux-points (:). Prenez en
compte que la ligne de commande du noyau est habituellement accessible par les programmes non
privilégiés dans /proc/cmdline. Cela étant, un tel mécanisme n'est pas apte à transférer des données
sensibles. À n'utiliser qu'avec des données non sensibles telles que clés publiques ou certificats,
pas avec les clés privées, ni dans un environnement de test ou de débogage.
Pour plus d'informations, consulter la documentation m[blue]Identifiants du système et des
services[8].
Ajouté dans la version 251.
systemd.import_credentials=
Prend un argument booléen. Si faux, désactive l'importation d'informations d'identification à partir
de la ligne de commande du noyau, de la table des chaînes OEM DMI/SMBIOS, du sous-système qemu_fw_cfg
ou de la partie EFI du noyau.
Ajouté dans la version 251.
quiet
Désactiver la sortie d'état à l'amorçage, comme ferait systemd&.show_status=no. Remarque, cette
option est aussi lue par le noyau lui-même et désactive la sortie journal du noyau. Passer cette
option désactive donc les sorties habituelles du gestionnaire de système et du noyau.
Ajouté dans la version 186.
debug
Désactiver la sortie d'état à l'amorçage, comme ferait systemd&.show_status=no. Remarque, cette
option est aussi lue par le noyau lui-même et désactive la sortie journal du noyau. Passer cette
option désactive donc les sorties habituelles du gestionnaire de système et du noyau.
Ajouté dans la version 205.
emergency, rd.emergency, -b
Démarrer en mode urgence. C'est l'équivalent de systemd.unit=emergency.target ou
rd.systemd.unit=emergency.target respectivement, et est fourni pour des besoins de compatibilité et
pour être plus simples à taper.
Ajouté dans la version 186.
rescue, rd.rescue, single, s, S, 1
Démarrer en mode sauvetage (rescue). C'est l'équivalent de systemd.unit=rescue.target ou
rd.systemd.unit=rescue.target respectivement, et est fourni pour des raisons de compatibilité et être
plus simple à saisir.
Ajouté dans la version 186.
2, 3, 4, 5
Amorcer en niveau d’exécution patrimonial (legacy) spécifié de SysV. Cela est équivalent à
systemd.unit=runlevel2.target, systemd.unit=runlevel3.target, systemd.unit=runlevel4.target et
systemd.unit=runlevel5.target respectivement, et est fourni pour raison de compatibilité et de
simplification de saisie.
Ajouté dans la version 186.
locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=,
locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=,
locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=, locale.LC_IDENTIFICATION=
Définir les paramètre régionaux du système à utiliser. Cela écrase les réglages dans
/etc/locale.conf. Pour plus d'informations, consultez locale.conf(5) et locale(7).
Ajouté dans la version 186.
Pour les autres paramètres de la ligne de commande du noyau compris par les composants du cœur du système
d'exploitation, veuillez vous référer à kernel-command-line(7).
INFORMATIONS D'IDENTIFICATION DU SYSTÈME
Durant l'initialisation, le gestionnaire de services importera des justificatifs depuis diverses sources
dans les informations d'identification du système, qui alors pourront être propagés dans les services et
consommés par les générateurs :
• Lorsque le gestionnaire de services s'initialisera, il lira les informations d'identification depuis
les chaînes du vendeur Type 11 SMBIOS io.systemd.credential:nom=valeur, et
io.systemd.credential.binary:nom=valeur.
• Au même moment, il importera les informations d'identification depuis QEMU « fw_cfg ». (À noter que
le mécanisme SMBIOS est habituellement préféré, car il est plus rapide et générique.)
• Les informations d'identification doivent être passées au noyau à l'aide de la ligne de commande en
utilisant le paramètre systemd.set-credential=, voir ci-dessus.
• Les informations d'identification doivent être passées de l'environnement UEFI avec systemd-stub(7).
• Lorsque le gestionnaire de services est invoqué durant l'initrd lors de la transition de l'hôte, tous
les fichiers dans /run/credentials/@initrd/ seront importés comme informations d'identification du
système.
Invoquer systemd-creds(1) comme il suit pour visualiser la liste d'informations d'identification passées
au système :
# systemd-creds --system list
Pour plus d'informations, consulter la documentation m[blue]Identifiants du système et des services[8].
Le gestionnaire de services consomme les informations d'identification suivantes du système lorsque lancé
en tant que PID 1 :
vmm.notify_socket
Contient une adresse AF_VSOCK ou AF_UNIX où envoyer un message de notification READY=1 lorsque le
système a complètement démarré. Voir sd_notify(3) et la section suivante pour plus d'informations. À
noter que dans le cas où l'hyperviseur ne gère pas SOCK_DGRAM pour AF_VSOCK, SOCK_SEQPACKET sera
essayé à la place. La charge utile de l'information d'identification pour AF_VSOCK doit être une
chaîne de la forme « vsock:CID:PORT ». « vstock-stream », « vstock-dgram » et « vsock-seqpacket »
peuvent être utilisés à la place de « vstock » pour forcer l'utilisation du type de socket
correspondant.
Cette fonctionnalité est utile pour les gestionnaires de machine ou d’autres processus de l'hôte pour
recevoir une notification à travers VSOCK lorsqu'une machine virtuelle a fini son démarrage.
Ajouté dans la version 254.
system.machine_id
Prend une ID hexadécimale de 128 octets pour y initialiser /etc/machine-id, si le fichier n'est pas
encore prêt. Voir machine-id(5) pour les détails.
Ajouté dans la version 254.
Pour une liste des identifiants du système que divers autres composants de systemd utilisent, voir
systemd.system-credentials(7).
PROTOCOLE DE DISPONIBILITÉ
Le gestionnaire de services implémente un protocole de notification de disponibilité entre le
gestionnaire et ses services (c'est-à-dire en bas de la pile) et entre le gestionnaire et un éventuel
superviseur plus en haut de la pile (ce denier pouvant être une machine ou un gestionnaire de conteneur,
ou, dans le cas d'un gestionnaire de services par utilisateur, l'instance du gestionnaire de services du
système). Le protocole élémentaire, et l'API suggérée pour le faire, sont décrits dans sd_notify(3).
Le socket de notification que le gestionnaire de services (incluant PID 1) utilise pour annoncer la
disponibilité à son propre superviseur est défini à travers la variable d'environnement habituelle
$NOTIFY_SOCKET (voir ci-dessus). Cela n'étant directement définissable que pour les gestionnaires de
conteneur et pour l'instance par utilisateur du gestionnaire de services, un mécanisme supplémentaire
pour le configurer est disponible, destiné particulièrement à une utilisation dans un environnement de
machine virtuelle : l'identifiant du système vmm.notify_socket (voir ci-dessus) peut être réglé à un
socket adapté (généralement un de AF_VSOCK) à l’aide de chaînes SMBIOS Type 11 de fournisseur. Pour les
détails voir ci-dessus.
Le protocole de notification du gestionnaire de services au sommet de la pile pour un superviseur prend
en charge un certain nombre de champs d'extension qui permettent au superviseur de connaître les
propriétés spécifiques du système et de suivre la progression de son démarrage. En particulier, les
champs suivants sont envoyés :
• Un message X_SYSTEMD_HOSTNAME=... sera envoyé une fois que le nom d'hôte initial pour le système aura
été déterminé. Notez que dans les derniers instants de l’exécution, le nom d'hôte peut être changé de
manière programmatique, et (actuellement) aucune notification supplémentaire n'est envoyée dans ce
cas.
Ajouté dans la version 256.
• Un message X_SYSTEMD_MACHINE_ID=... sera envoyé une fois que l'identifiant machine du système aura
été déterminé. Voir machine-id(5) pour les détails.
Ajouté dans la version 256.
• Un message X_SYSTEMD_SIGNALS_LEVEL=... sera envoyé lorsque le gestionnaire de services aura installé
les divers gestionnaires de signaux des processus UNIX décrits ci-dessus. La valeur du champ est un
entier non signé formaté en chaîne décimale, et indique le niveau de fonctionnalité pris en charge
des signaux de processus UNIX du gestionnaire de services. Actuellement, un seul niveau de
caractéristique est défini :
• X_SYSTEMD_SIGNALS_LEVEL=2 couvre les divers signaux de processus UNIX documentés ci-dessus qui
sont un sur-ensemble de ceux pris en charge par le système historique init de SysV.
Les signaux envoyés au PID 1 avant que ce message ne soit envoyé peuvent ne pas avoir été
correctement gérés pour le moment. Un consommateur de ces messages devra analyser la valeur comme une
indication d'entier non signé du niveau de prise en charge. Actuellement, seul le niveau 2 mentionné
est défini, mais prochainement d'autres niveaux devraient être définis avec des entiers supérieurs,
ce qui implémentera un sur-ensemble du comportement actuellement défini.
Ajouté dans la version 256.
• Des messages X_SYSTEMD_UNIT_ACTIVE=... et X_SYSTEMD_UNIT_INACTIVE=... seront envoyés pour chaque
unité cible qui devient active ou cesse d'être active. Cela est utile pour suivre la progression du
démarrage et la fonctionnalité. Par exemple, dès que l'unité ssh-access.target est déclarée démarrée,
un accès SSH est typiquement disponible, voir systemd.special(7) pour les détails.
Ajouté dans la version 256.
• Un message X_SYSTEMD_SHUTDOWN=... sera envoyé juste avant que le système ne s'éteigne. La valeur est
l'une des chaînes « reboot », « halt », « poweroff », « kexec », et indique quelle sorte d’extinction
est exécutée.
Ajouté dans la version 256.
• Un message X_SYSTEMD_REBOOT_PARAMETER=... sera aussi envoyé juste avant que le système ne s'éteigne.
Sa valeur est l'argument de redémarrage comme configuré avec systemctl --reboot-argument=....
Ajouté dans la version 256.
Notez que ces champs d'extension sont envoyés en plus des notifications habituelles « READY=1 » et
« RELOADING=1 ».
OPTIONS
systemd n'est que rarement appelé directement, étant donné qu'il est lancé tôt et qu'il est déjà en cours
d'exécution au moment où les utilisateurs peuvent interagir avec lui. Normalement, des outils tels que
systemctl(1) sont utilisés pour passer les commandes au gestionnaire. Comme systemd n'est généralement
pas appelé directement, les options listées ci-dessous sont surtout utiles à des fins de débogage ou pour
des buts spécifiques.
Options d'introspection et de débogage
Ces options sont utilisées pour les tests et l'introspection, et systemd peut être invoqué avec elles à
tout moment :
--dump-configuration-items
Vider les éléments gérés de configuration de l'unité. Il en résulte une liste laconique mais complète
des éléments de configuration gérés dans les fichiers de définition des unités.
--dump-bus-properties
Vidage des propriétés exposées du bus. Cela produit une liste laconique mais complète des propriétés
exposées sur le D-Bus.
Ajouté dans la version 239.
--test
Déterminer la transaction initiale de démarrage (c’est-à-dire la liste des tâches mises en file
d'attente lors du démarrage), la vider et terminer — sans exécuter réellement aucun des tâches
déterminées. Cette option n'est utile que pour le débogage. Notez que durant le démarrage usuel du
gestionnaire de service, des unités additionnelles, non visibles avec cette opération, peuvent être
démarrées parce qu’un matériel, un socket, un bus ou un autre types d'activation pourraient ajoutées
de nouvelles tâches lors de l'exécution de la transaction. Utilisez --system pour demander la
transaction initiale du gestionnaire de service système (c'est aussi la valeur implicite par défaut),
combinez avec --user pour demander la transaction initiale du gestionnaire de service par utilisateur
à la place.
--system, --user
Lorsqu'utilisé avec --test, sélectionne s'il faut calculer la transaction initiale pour l'instance du
système ou pour une instance par utilisateur. Ces options sont sans effet si elles sont appelées sans
--test, comme durant d'usuels appels (c’est-à-dire sans --test) le gestionnaire de services détectera
automatiquement s'il doit agir dans le mode système ou celui utilisateur, en vérifiant si le PID du
processus lancé est 1 ou pas. Notez qu'il n'est pas pris en charge l'amorçage et la maintenance d'un
système avec le gestionnaire de services lancé en mode --system mais avec un PID autre que 1.
-h, --help
Afficher un aide-mémoire succinct et quitter.
--version
Afficher une information de version courte et quitter.
Options pour dupliquer en ligne de commande les réglages du noyau
Ces options correspondent exactement aux options listées ci-dessus dans « Ligne de commande du noyau ».
Les deux formes peuvent être utilisées de manière équivalente pour le gestionnaire du système, mais il
est recommandé d'utiliser les formes citées ci-dessus dans ce contexte, car elles sont proprement placées
dans le bon espace de noms. Lorsqu'une option est indiquée à la fois sur la ligne de commande du noyau et
comme argument de la ligne de commande, la dernière a la précédence.
Lorsque systemd est utilisé comme gestionnaire utilisateur, la ligne de commandes du noyau est ignorée et
seules les options décrites ci-dessous sont gérées. Néanmoins, systemd est généralement démarré dans ce
mode, à travers le service user@service(5), qui est partagé entre tous les utilisateurs. Il est plus aisé
d'utiliser les fichiers de configuration pour modifier les réglages (voir systemd-user.conf(5)) ou les
variables d'environnement. Consulter la section « Environnement » ci-dessus pour des explications sur
comment est défini le bloc environnement.
--unit=
Définir une unité par défaut à activer au démarrage. Si cela n'est pas indiqué, c'est par défaut
default.target. Voir systemd.unit= ci-dessus.
--dump-core
Activer le vidage du cœur en cas de plantage. Cela n'a aucun effet lorsqu'utilisé sous une instance
utilisateur. Pareil à systemd.dump_core= ci-dessus.
--crash-vt=VT
Basculer dans une console virtuelle (VT) définie en cas de plantage. Ce changement n'a aucun effet
lorsque lancé depuis une instance utilisateur. Comme systemd.crash_chvt= ci-dessus (mais pas
l’orthographe différente !).
Ajouté dans la version 227.
--crash-shell
Lancer un interpréteur de commandes lors d'un plantage. Cela n'a aucun effet si lancé depuis une
instance utilisateur. Voir systemd.crash_shell= ci-dessus.
--crash-action=
Indiquer quoi faire en cas de plantage du gestionnaire du système (PID 1). Cela n'a aucun effet si
systemd est lancé comme instance utilisateur. Voir systemd.crash_action= ci-dessus.
Ajouté dans la version 256.
--confirm-spawn
Demander confirmation lors de la création de processus. Cela n'a aucun effet lancé en instance
utilisateur. Voir systemd.confirm_spawn ci-dessus.
--show-status
Afficher des informations laconiques sur l'état de l'unité sur la console lors du démarrage et de
l'arrêt de l'unité. Voir systemd.show_status ci-dessus.
Ajouté dans la version 244.
--log-color
Mettre en surbrillance les messages journal importants. Voir systemd.log_color ci-dessus.
Ajouté dans la version 244.
--log-level=
Définir le niveau de journalisation. Voir systemd.log_level ci-dessus.
--log-location
Inclure l'emplacement du code dans les messages journal. Voir systemd.log_location ci-dessus.
Ajouté dans la version 244.
--log-target=
Définir la cible du journal. Voir systemd.log_target ci-dessus.
--log-time=
Préfixer les messages de la console avec un horodatage. Voir systemd.log_time ci-dessus.
Ajouté dans la version 246.
--machine-id=
Écraser l'identifiant de la machine défini sur le disque dur. Voir systemd.machine_id= ci-dessus.
Ajouté dans la version 229.
--service-watchdogs
Activer ou désactiver de façon globale toutes les actions urgentes ou minutées du service chien de
garde. Voir systemd.service_watchdogs ci-dessus.
Ajouté dans la version 237.
--default-standard-output=, --default-standard-error=
Définition de la sortie par défaut ou la sortie d'erreur pour tous les services et les sockets
respectivement. Voir systemd.default_standard_output= et systemd.default_standard_error= ci-dessus.
EPOCH DE L'HORLOGE SYSTÈME
Lorsque systemd est démarré ou redémarré, il se peut qu’il règle l'horloge système à l'« epoch ». Ce
mécanisme est utilisé pour s'assurer que l'horloge système reste raisonnablement initialisée et de façon
à peu près monotone lors des divers démarrages, dans le cas où aucune horloge en temps réel (RTC) locale
avec batterie de secours n’est disponible ou si elle ne fonctionne pas correctement.
L'epoch est la date la plus ancienne à partir de laquelle le système est présumé être correctement réglé.
Lors de l'initialisation, l'horloge locale est avancée vers l'epoch si elle était réglée à une valeur
trop ancienne. Un cas particulier : si l'horloge locale est suffisamment éloignée dans le futur (par
défaut 15 ans, mais cela peut être configuré lors de la construction), l'horloge matérielle est présumée
cassée et l'horloge système est ramenée à l'epoch.
L'epoch est réglée à la valeur la plus récente des dates suivantes : le moment de construction de
systemd, la date de modification (« mtime ») de /usr/lib/clock-epoch ou la date de modification de
/var/lib/systemd/timesync/clock.
FICHIERS
/run/systemd/notify
Socket de notification de l'état du démon. C'est un socket datagramme AF_UNIX qui est utilisé pour
implémenter la logique de notification du démon comme implémenté par sd_notify(3).
/run/systemd/private
Utilisé en interne comme canal de communication entre systemctl(1) et le processus systemd. C'est un
socket flux AF_UNIX. Cette interface est personnelle à systemd et ne devrait pas être utilisée pour
des projets extérieurs.
/dev/initctl
Prise en charge limitée de l'interface cliente SysV, comme implémentée par l'unité
systemd-initctl.service. C'est un tube nommé (pipe) dans le système de fichiers. Cette interface est
obsolète et ne doit pas être utilisée pour de nouvelles applications.
/usr/lib/clock-epoch
La date de modification (« mtime ») de ce fichier est utilisée pour l'heure de l'epoch, voir la
section précédente.
Ajouté dans la version 247.
/var/lib/systemd/timesync/clock
La date de modification (« mtime ») de ce fichier est mise à jour par systemd-timesyncd.service(8).
Si présente, la date de modification du fichier est utilisée pour l'epoch, voir la section
précédente.
Ajouté dans la version 257.
HISTORIQUE
systemd 252
Les arguments de la ligne de commandes du noyau systemd.unified_cgroup_hierarchy et
systemd.legacy_systemd_cgroup_controller sont considérés obsolètes. Veuillez changer pour une
hiérarchie cgroups unifiée.
Ajouté dans la version 252.
VOIR AUSSI
La page d’accueil de systemd[8], systemd-system.conf(5), locale.conf(5), systemctl(1), journalctl(1),
systemd-notify(1), daemon(7), sd-daemon(3), org.freedesktop.systemd1(5), systemd.unit(5),
systemd.special(7), pkg-config(1), kernel-command-line(7), bootup(7), systemd.directives(7),
org.freedesktop.systemd1(5)
Pour davantage d'informations sur les concepts et idées derrière systemd, veuillez consulter le Document
de conception originel[2].
NOTES
1. Portabilité d'interface et promesse de stabilité
https://systemd.io/PORTABILITY_AND_STABILITY/
2. Interface conteneur
https://systemd.io/CONTAINER_INTERFACE
3. Interface initrd
https://systemd.io/INITRD_INTERFACE/
4. Groupes de contrôle version 2
https://docs.kernel.org/admin-guide/cgroup-v2.html
5. Spécification du répertoire de base XDG
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
6. Variables d'environnement connues
https://systemd.io/ENVIRONMENT
7. Identifiants du système et des services
https://systemd.io/CREDENTIALS
8. Page d’accueil de systemd
https://systemd.io/
9. Document de conception originel
https://0pointer.de/blog/projects/systemd.html
TRADUCTION
La traduction française de cette page de manuel a été créée par bubu <bubub@no-log.org>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License
version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à
debian-l10n-french@lists.debian.org.
systemd 257.3 SYSTEMD(1)