.\" -*- coding: UTF-8 -*-
'\" t
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH SYSTEMD 1 "" "systemd 260.2" systemd
.ie  \n(.g .ds Aq \(aq
.el       .ds Aq '
.\" -----------------------------------------------------------------
.\" * Define some portability stuff
.\" -----------------------------------------------------------------
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" http://bugs.debian.org/507673
.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html
.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.\" -----------------------------------------------------------------
.\" * set default formatting
.\" -----------------------------------------------------------------
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
.ad l
.\" -----------------------------------------------------------------
.\" * MAIN CONTENT STARTS HERE *
.\" -----------------------------------------------------------------
.SH NOM
systemd, init – Gestionnaire de services et de système systemd
.SH SYNOPSIS
.HP \w'\fB/usr/lib/systemd/systemd\fR\ 'u
\fB/usr/lib/systemd/systemd\fP [OPTIONS...]
.HP \w'\fBinit\fR\ 'u
\fBinit\fP [OPTIONS...]
.SH DESCRIPTION
.PP
\fBsystemd\fP 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\&.
.PP
\fBsystemd\fP 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 \fBuser@.service\fP(5)\&.
.PP
Lorsqu'il est exécuté en tant qu'instance du système, \fBsystemd\fP interprète
le fichier de configuration \fIsystem.conf\fP et les fichiers des répertoires
\fIsystem.conf.d\fP. Lorsqu’utilisé comme instance utilisateur, \fBsystemd\fP
interprète le fichier de configuration \fIuser.conf\fP et les fichiers dans les
répertoires \fIuser.conf.d\fP. Consulter \fBsystemd\-system.conf\fP(5) pour plus
d'informations\&.
.PP
\fBsystemd\fP 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 \fI/sys/\fP
ou \fI/proc/\fP et \fI/dev/\fP\&.
.PP
\fBsystemd\fP 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\&.
.PP
Notez que certaines, mais pas toutes, interfaces fournies par \fBsystemd\fP
sont couvertes par la \m[blue]\fBPortabilité d'interface et promesse de stabilité\fP\m[]\&\s-2\u[1]\d\s+2\&.
.PP
L'API D\-Bus de \fBsystemd\fP est décrite dans \fBorg.freedesktop.systemd1\fP(5)
et \fBorg.freedesktop.LogControl1\fP(5)\&.
.PP
Les systèmes qui invoquent \fBsystemd\fP dans un conteneur ou un environnement
initrd devraient implémenter les spécifications \m[blue]\fBInterface conteneur\fP\m[]\&\s-2\u[4]\d\s+2 ou \m[blue]\fBInterface initrd\fP\m[]\&\s-2\u[5]\d\s+2, respectivement\&.
.SH UNITÉS
.PP
\fBsystemd\fP 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 \fBsystemd.unit\fP(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\&.
.sp
.it 1 an-trap
.nr an-no-space-flag 1
.nr an-break-flag 1
.br
\fBTable\ \&1.\ \&états d'ACTIVITÉ des unités\fP
.TS
allbox tab(:);
lB lB.
T{
État
T}:T{
Description
T}
.T&
l l
l l
l l
l l
l l
l l
l l
l l.
T{
\fIactive\fP
T}:T{
Démarrée, liée, branchée,\&..., suivant le type d'unité\&.
T}
T{
\fIinactive\fP
T}:T{
Stoppée, non liée, débranchée,\&..., suivant le type d'unité\&.
T}
T{
\fIfailed\fP
T}:T{
Similaire à \fBinactive\fP, 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)\&.
T}
T{
\fIactivating\fP
T}:T{
Modification d'\fBinactive\fP en \fBactive\fP\&.
T}
T{
\fIdeactivating\fP
T}:T{
Modification d'\fBactive\fP en \fBinactive\fP\&.
T}
T{
\fImaintenance\fP
T}:T{
L'unité est \fBinactive\fP et une opération d'entretien est en cours\&.
T}
T{
\fIreloading\fP
T}:T{
L'unité est \fBactive\fP et est en cours de recharge de configuration\&.
T}
T{
\fIrefreshing\fP
T}:T{
L'unité est \fBactive\fP et un nouveau montage a été activé dans son espace de noms\&.
T}
.TE
.sp 1
.PP
Les types d'unité suivants sont disponibles :
.sp
.RS 4
.ie  n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
Les unités service, qui démarrent et contrôlent les démons et les processus
qui les composent\&. Pour plus d'informations, consulter
\fBsystemd.service\fP(5)\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  2." 4.2
.\}
Les unités socket, qui encapsulent les \fBIPC\fP (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
\fBsystemd.socket\fP(5), pour des détails sur l'activation basée socket et
d'autres formes d'activation, voir \fBdaemon\fP(7)\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  3." 4.2
.\}
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
\fBsystemd.target\fP(5)\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 4.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  4." 4.2
.\}
Les unités périphérique exposent les périphériques du noyau dans \fBsystemd\fP
et devraient être utilisées pour implémenter l'activation basée
périphérique\&. Pour plus de détails, consulter \fBsystemd.device\fP(5)\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 5.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  5." 4.2
.\}
Les unités montage contrôlent les points de montage dans le système de
fichiers, pour les détails voir \fBsystemd.mount\fP(5)\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 6.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  6." 4.2
.\}
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 \fBsystemd.automount\fP(5)\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 7.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  7." 4.2
.\}
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
\fBsystemd.timer\fP(5)\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 8.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  8." 4.2
.\}
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 \fBsystemd.swap\fP(5)\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 9.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  9." 4.2
.\}
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 \fBsystemd.path\fP(5)\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'10.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "10." 4.2
.\}
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
\fBsystemd.slice\fP(5)\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'11.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "11." 4.2
.\}
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
\fBsystemd.scope\fP(5)\&.
.RE
.PP
Les unités sont nommées en fonction de leurs fichiers de
configuration\&. Quelques unités ont une sémantique spéciale\&. Consulter
\fBsystemd.special\fP(7) pour une liste détaillée\&.
.PP
\fBsystemd\fP reconnait différentes sortes de dépendances, incluant les
dépendances positives ou négatives d’exigence (c.à\-d.\& \fIRequires=\fP et
\fIConflicts=\fP) tout comme les dépendances ordonnées (\fIAfter=\fP et
\fIBefore=\fP)\&. 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 \fBsystemd\fP\&. 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\&.
.PP
Les programmes d'application et les unités (à travers les dépendances)
peuvent nécessiter des changements d'état d'unités\&. Dans \fBsystemd\fP 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\&.
.PP
À l'amorçage \fBsystemd\fP 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 \fBsystemd.special\fP(7) pour plus de
détails sur les unités target\&.
.PP
Lors du premier amorçage, \fBsystemd\fP activera ou désactivera les unités
selon une politique préétablie\&. Voir \fBsystemd.preset\fP(5) et « First Boot
Semantics » dans \fBmachine\-id\fP(5)\&.
.PP
\fBsystemd\fP 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 :
.sp
.RS 4
.ie  n \{\
\h'-04' 1.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  1." 4.2
.\}
Elle est dans un état actif, activation, désactivation ou en échec
(c'est\-à\-dire tout état d'unité excepté « inactif »)
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 2.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  2." 4.2
.\}
Elle possède une file de tâches pour ça
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 3.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  3." 4.2
.\}
Elle est une dépendance pour au moins une autre unité chargée en mémoire
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 4.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  4." 4.2
.\}
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).
.RE
.sp
.RS 4
.ie  n \{\
\h'-04' 5.\h'+01'\c
.\}
.el \{\
.sp -1
.IP "  5." 4.2
.\}
Elle a été attachée en mémoire par programmation avec un appel à D\-Bus
.RE
.PP
\fBsystemd\fP 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
\fBsystemctl list\-units \-\-all\fP 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\&.
.PP
Les processus créés par \fBsystemd\fP 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 \fBsystemd\fP\&.(voir \m[blue]\fBGroupes de contrôle v2\fP\m[]\&\s-2\u[1]\d\s+2 pour plus d'informations sur les groupes de
contrôle ou « cgroups »)\&. \fBsystemd\fP 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 \fI/sys/fs/cgroup/\fP), ou des outils comme
\fBsystemd\-cgls\fP(1) ou \fBps\fP(1) (\fBps xawf \-eo pid,user,cgroup,args\fP est
particulièrement utile pour lister tous les processus et les unités systemd
auxquelles ils appartiennent\&)\&.
.PP
systemd is compatible with various established Unix functionality such as
/etc/fstab or the utmp database\&.
.PP
\fBsystemd\fP 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,
\fBsystemd\fP essaiera de la réparer, et supprimera les tâches non essentielles
de la transaction qui pourraient supprimer la boucle\&. Aussi, \fBsystemd\fP
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 \fBsystemd\fP vérifiera que cela a du sens, la réparera si
possible, et n'échouera que si vraiment cela ne peut pas fonctionner\&.
.PP
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\&.
.PP
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 \fBsystemd.generator\fP(7)\&.
.SH RÉPERTOIRES
.PP
Répertoires des unités système
.RS 4
Le gestionnaire de système \fBsystemd\fP 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
\fBpkg\-config systemd \-\-variable=systemdsystemunitdir\fP\&. Les autres
répertoires vérifiés sont \fI/usr/local/lib/systemd/system\fP et
\fI/usr/lib/systemd/system\fP\&. La configuration de l'utilisateur a toujours
la préséance\&. \fBpkg\-config systemd \-\-variable=systemdsystemconfdir\fP
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 \fBenable\fP et \fBdisable\fP de l'outil \fBsystemctl\fP(1)\&. La liste de
l'ensemble des répertoires est fournie dans \fBsystemd.unit\fP(5)\&.
.RE
.PP
Répertoires de l'unité utilisateur
.RS 4
Des règles similaires s'appliquent aux répertoires utilisateur de
l'unité\&. Là néanmoins, la \m[blue]\fBSpécification du répertoire de base XDG\fP\m[]\&\s-2\u[6]\d\s+2 est suivie pour trouver les unités\&. Les
applications devraient placer leurs fichiers d'unité dans le répertoire
renvoyé par \fBpkg\-config systemd \-\-variable=systemduserunitdir\fP\&. La
configuration globale est faite dans le répertoire mentionné par
\fBpkg\-config systemd \-\-variable=systemduserconfdir\fP\&. Les commandes
\fBenable\fP et \fBdisable\fP de l'outil \fBsystemctl\fP(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 \fBsystemd.unit\fP(5)\&.
.RE
.SH SIGNAUX
.PP
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 \fBsd_notify()\fP portant le champ \fIX_SYSTEMD_SIGNALS_LEVEL=2\fP
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\&.
.PP
\fBSIGTERM\fP
.RS 4
À la réception de ce signal, le gestionnaire de système \fBsystemd\fP sérialise
son état, s'exécute à nouveau et désérialise à nouveau l'état
sauvegardé\&. Cela est quasiment équivalent à \fBsystemctl daemon\-reexec\fP\&.
.sp
Les gestionnaires d'utilisateur de \fBsystemd\fP démarreront l'unité
exit\&.target quand le signal est reçu\&. Cela est quasiment équivalent à
\fBsystemctl \-\-user start exit\&.target \-\-job\-mode=replace\-irreversibly\fP\&.
.RE
.PP
\fBSIGINT\fP
.RS 4
À la réception de ce signal, le gestionnaire de système \fBsystemd\fP démarre
l'unité ctrl\-alt\-del\&.target\&. Cela est quasiment l'équivalent de
\fBsystemctl start ctrl\-alt\-del\&.target \-\-job\-mode=replace=irreversibly\fP\&.
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\&.
.sp
Les gestionnaires d'utilisateur de \fBsystemd\fP traitent ce signal de la même
manière que \fBSIGTERM\fP\&.
.RE
.PP
\fBSIGWINCH\fP
.RS 4
Lorsque ce signal est reçu, le gestionnaire de système \fBsystemd\fP démarrera
l'unité kbrequest\&.target\&. Cela est quasiment équivalent à \fBsystemctl start kbrequest\&.target\fP\&.
.sp
Ce signal est ignoré par les gestionnaires d'utilisateur de \fBsystemd\fP\&.
.RE
.PP
\fBSIGPWR\fP
.RS 4
Lorsque ce signal est reçu, le gestionnaire systemd démarrera l'unité
sigpwr\&.target\&. C'est quasiment équivalent à \fBsystemctl start sigpwr\&.target\fP\&.
.RE
.PP
\fBSIGUSR1\fP
.RS 4
Le gestionnaire systemd essaiera de se reconnecter au bus D\-Bus à la
réception de ce message\&.
.RE
.PP
\fBSIGUSR2\fP
.RS 4
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 \fBsystemd\-analyze dump\fP\&.
.RE
.PP
\fBSIGHUP\fP
.RS 4
Rechargement de la configuration complète du démon\&. Cela est quasiment
équivalent à \fBsystemctl daemon\-reload\fP\&.
.RE
.PP
\fBSIGRTMIN+0\fP
.RS 4
Entrer en mode par défaut, démarrer l'unité default\&.target. Cela est
quasiment équivalent à \fBsystemctl isolate default\&.target\fP\&.
.RE
.PP
\fBSIGRTMIN+1\fP
.RS 4
Entrer en mode de secours (rescue), démarrer l'unité rescue\&.target\&. Cela
est quasiment équivalent à \fBsystemctl isolate rescue\&.target\fP\&.
.RE
.PP
\fBSIGRTMIN+2\fP
.RS 4
Entrer en mode urgence, démarrer l'unité emergency\&.service\&. Cela est
quasiment équivalent à \fBsystemctl isolate emergency\&.service\fP\&.
.RE
.PP
\fBSIGRTMIN+3\fP
.RS 4
Arrêter la machine, démarrer l'unité halt\&.target\&. Cela est quasiment
équivalent à \fBsystemctl start halt\&.target \-\-job\-mode=replace\-irreversibly\fP\&.
.RE
.PP
\fBSIGRTMIN+4\fP
.RS 4
Éteindre la machine, démarrer l'unité poweroff\&.target\&. Cela est
quasiment équivalent à \fBsystemctl start poweroff\&.target \-\-job\-mode=replace\-irreversibly\fP\&.
.RE
.PP
\fBSIGRTMIN+5\fP
.RS 4
Réamorcer la machine, démarrer le réamorçage des unités
reboot\&.target\&. Cela est quasiment équivalent à \fBsystemctl start reboot\&.target \-\-job\-mode=replace\-irreversibly\fP\&.
.RE
.PP
\fBSIGRTMIN+6\fP
.RS 4
Réamorcer la machine à l'aide de kexec, démarrer les unités
kexec\&.target\&. Cela est quasiment équivalent à \fBsystemctl start kexec\&.target \-\-job\-mode=replace\-irreversibly\fP\&.
.RE
.PP
\fBSIGRTMIN+7\fP
.RS 4
Réamorcer l'espace utilisateur, démarrer le réamorçage de l'unité
soft\-reboot\&.target \&. Cela est quasiment équivalent à \fBsystemctl start soft\-reboot\&.target \-\-job\-mode=replace\-irreversibly\fP\&.
.sp
Ajouté dans la version 254\&.
.RE
.PP
\fBSIGRTMIN+13\fP
.RS 4
Arrêter la machine immédiatement\&.
.RE
.PP
\fBSIGRTMIN+14\fP
.RS 4
Éteindre la machine immédiatement\&.
.RE
.PP
\fBSIGRTMIN+15\fP
.RS 4
Réamorcer immédiatement la machine\&.
.RE
.PP
\fBSIGRTMIN+16\fP
.RS 4
Réamorcer immédiatement la machine avec kexec\&.
.RE
.PP
\fBSIGRTMIN+17\fP
.RS 4
Réamorcer immédiatement l'espace utilisateur\&
.sp
Ajouté dans la version 254\&.
.RE
.PP
\fBSIGRTMIN+20\fP
.RS 4
Activer l'affichage des messages d'état sur la console, comme contrôlé à
l'aide de \fIsystemd\&.show_status=1\fP sur la ligne de commande du noyau\&.
.sp
Vous pouvez préférer utiliser \fBSetShowStatus()\fP au lieu de \fBSIGRTMIN+20\fP
pour prévenir les situations de compétition\&. Voir
\fBorg.freedesktop.systemd1\fP(5)\&.
.RE
.PP
\fBSIGRTMIN+21\fP
.RS 4
Désactiver l'affichage des messages d'état sur la console, comme contrôlé à
l'aide de \fIsystemd\&.show_status=0\fP sur la ligne de commande du noyau\&.
.sp
Vous pouvez préférer utiliser \fBSetShowStatus()\fP au lieu de \fBSIGRTMIN+21\fP
pour prévenir les situations de compétition\&. Voir
\fBorg.freedesktop.systemd1\fP(5)\&.
.RE
.PP
\fBSIGRTMIN+22\fP
.RS 4
Définir le niveau de journal du gestionnaire de services à « debug », d'une
manière équivalente à \fIsystemd\&.log_level=debug\fP sur la ligne de commande
du noyau\&.
.RE
.PP
\fBSIGRTMIN+23\fP
.RS 4
Restaurer le niveau de journalisation à sa valeur configurée\&. La valeur
configurée est dérivée de \(en dans l'ordre de priorité \(en la valeur
spécifiée avec \fIsystemd\&.log\-level=\fP sur la ligne de commande du noyau, ou
la valeur spécifiée avec \fBLogLevel=\fP dans le fichier de configuration ou
celle interne par défaut de « info »\&.
.sp
Ajouté dans la version 239\&.
.RE
.PP
\fBSIGRTMIN+24\fP
.RS 4
Sortie immédiate du gestionnaire (disponible seulement pour \-\-user
instances)\&.
.sp
Ajouté dans la version 195\&.
.RE
.PP
\fBSIGRTMIN+25\fP
.RS 4
Dès réception de ce message le gestionnaire \fBsystemd\fP s'exécutera à nouveau
de lui\-même\&. C'est quasiment équivalent à \fBsystemctl daemon\-reexec\fP sauf
que cela sera fait de manière asynchrone\&.
.sp
Le gestionnaire systemd traite ce signal de la même façon que \fBSIGTERM\fP\&.
.sp
Ajouté dans la version 250\&.
.RE
.PP
\fBSIGRTMIN+26\fP
.RS 4
Restaurer la cible journal à sa valeur configurée\&. La valeur configurée
est dérivée de \(en dans l'ordre de priorité \(en la valeur spécifiée avec
\fIsystemd\&.log.target=\fP sur la ligne de commande du noyau, ou est la valeur
spécifiée avec \fBLogTarget=\fP dans le fichier de configuration ou celle
interne par défaut\&.
.sp
Ajouté dans la version 239\&.
.RE
.PP
\fBSIGRTMIN+27\fP, \fBSIGRTMIN+28\fP
.RS 4
Définir la cible journal à « console » pour \fBSIGRTMIN+27\fP (ou « kmsg » pour
\fBSIGRTMIN+28\fP), d'une manière équivalente à \fIsystemd\&.log_target=console\fP
(ou \fIsystemd\&.log_target=kmsg\fP pour \fBSIGRTMIN+28\fP) sur la ligne de
commande du noyau\&.
.sp
Ajouté dans la version 239\&.
.RE
.SH ENVIRONNEMENT
.PP
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 \fBsystemd.exec\fP(5)\&. Le réglage \fIDefaultEnvironment=\fP 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 \fIEnvironment=\fP et
\fIEnvironmentFile=\fP pour user@\&.service (voir \fBsystemd.exec\fP(5))\&. De
même, des variables d'environnement peuvent être définies avec le réglage de
\fIManagerEnvironment=\fP dans \fBsystemd\-system.conf\fP(5) et
\fBsystemd\-user.conf\fP(5)\&.
.PP
Quelques variables interprétables par \fBsystemd\fP :
.PP
\fI$SYSTEMD_LOG_LEVEL\fP
.RS 4
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)
\fBemerg\fP, \fBalert\fP, \fBcrit\fP, \fBerr\fP, \fBwarning\fP, \fBnotice\fP, \fBinfo\fP,
\fBdebug\fP ou un entier dans l’intervalle 0\&...7\&. Consultez \fBsyslog\fP(3)
pour davantage d'informations\&. Chaque valeur peut être optionnellement
préfixée avec \fBconsole\fP, \fBsyslog\fP, \fBkmsg\fP ou \fBjournal\fP suivi d'un
deux\-points (\fB:\fP) pour définir le niveau de journalisation maximal pour la
cible spécifique de journal (par exemple
\fBSYSTEMD_LOG_LEVEL=debug,console:info\fP indique de journaliser au niveau
\fBdebug\fP excepté pour la journalisation vers la console qui doit s'effectuer
au niveau \fBinfo\fP)\&. Notez que le niveau maximal de journalisation globale
est prioritaire sur tout niveau maximal de journalisation par cible\&.
.sp
Cela peut\-être écrasé par \fB\-log\-level=\fP\&.
.RE
.PP
\fI$SYSTEMD_LOG_COLOR\fP
.RS 4
Un booléen\&. Si la valeur est vrai, les messages écrits sur le terminal
seront colorés selon la priorité\&.
.sp
Cela peut être écrasé avec \fB\-log\-color=\fP\&.
.RE
.PP
\fI$SYSTEMD_LOG_TIME\fP
.RS 4
Un booléen\&. Si la valeur est vrai, les messages du journal de la console
seront préfixés d'un horodatage\&.
.sp
Cela peut être écrasé avec \fB\-log\-time=\fP\&.
.sp
Ajouté dans la version 246\&.
.RE
.PP
\fI$SYSTEMD_LOG_LOCATION\fP
.RS 4
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\.
.sp
Cela peut être écrasé avec \fB\-log\-location=\fP\&.
.RE
.PP
\fI$SYSTEMD_LOG_TID\fP
.RS 4
Un booléen\&. Si la valeur est vrai, les messages seront préfixés par
l'identifiant numérique du thread actuel (TID)\&.
.sp
Ajouté dans la version 247\&.
.RE
.PP
\fI$SYSTEMD_LOG_TARGET\fP
.RS 4
Destination pour journaliser les messages\&. Une des destinations parmi
\fBconsole\fP (journaliser dans le terminal attaché), \fBconsole\-prefixed\fP
(journaliser dans le terminal attaché, mais avec des préfixes qui codent le
niveau et le « service » de journalisation, consultez \fBsyslog\fP(3)), \fBkmsg\fP
(journaliser dans le tampon de journalisation circulaire du noyau),
\fBjournal\fP (journaliser dans le journal), \fBjournal\-or\-kmsg\fP (journaliser
dans le journal s'il est disponible et sinon dans kmsg), \fBauto\fP (déterminer
automatiquement la cible appropriée de journalisation, c'est la destination
par défaut), \fBnull\fP (désactive la sortie de journalisation)\&.
.sp
Cela peut être écrasé avec \fB\-log\-target=\fP\&.
.RE
.PP
\fI$SYSTEMD_LOG_RATELIMIT_KMSG\fP
.RS 4
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\&.
.sp
Ajouté dans la version 254\&.
.RE
.PP
\fI$XDG_CONFIG_HOME\fP, \fI$XDG_CONFIG_DIRS\fP, \fI$XDG_DATA_HOME\fP,
\fI$XDG_DATA_DIRS\fP
.RS 4
Le gestionnaire utilisateur de systemd utilise ces variables en accord avec
la \m[blue]\fBXDG Base Directory specification\fP\m[]\&\s-2\u[6]\d\s+2 pour sa
configuration\&.
.RE
.PP
\fI$SYSTEMD_UNIT_PATH\fP, \fI$SYSTEMD_GENERATOR_PATH\fP,
\fI$SYSTEMD_ENVIRONMENT_GENERATOR_PATH\fP
.RS 4
Pour contrôler où systemd cherche les fichiers d'unité et les générateurs\&.
.sp
Ces variables peuvent contenir une liste de chemins, séparés par des
deux\-points (\fB:\fP)\&. 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\&.
.RE
.PP
\fI$SYSTEMD_PAGER\fP, \fI$PAGER\fP
.RS 4
Afficheur à utiliser lorsque \fB\-\-no\-pager\fP n'est pas
précisé. \fI$SYSTEMD_PAGER\fP est utilisé s'il est défini ; autrement,
\fI$PAGER\fPest utilisé\&. Si ni \fI$SYSTEMD_PAGER\fP, ni \fI$PAGER\fP n'ont de
valeur, un ensemble d’afficheurs bien connus sont essayés à tour de rôle,
incluant \fBless\fP(1) et \fBmore\fP(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 ces variables d'environnement à une chaîne vide ou à
« cat » est équivalent à l'utilisation de \fB\-\-no\-pager\fP\&.
.sp
Remarque : si \fI$SYSTEMD_PAGERSECURE\fP n'est pas défini, \fI$SYSTEMD_PAGER\fP et
\fI$PAGER\fP ne peuvent être utilisés que pour désactiver l'afficheur (avec
« cat » ou « "" ») et autrement seront ignorés\&.
.RE
.PP
\fI$SYSTEMD_LESS\fP
.RS 4
Outrepasser les options passées à \fBless\fP (par défaut « FRSXMK »)\&.
.sp
Les utilisateurs voudront peut\-être changer deux options en particulier :
.PP
\fBK\fP
.RS 4
Cette option ordonne à l’afficheur de quitter immédiatement lorsque Ctrl+C
est entré\&. Pour permettre à \fBless\fP de gérer Ctrl+C lui\-même le retour à
l'invite de commande de l’afficheur, ne pas fournir cette option\&.
.sp
Si la valeur de \fI$SYSTEMD_LESS\fP n'inclut pas « K » et si l’afficheur appelé
est \fBless\fP, Ctrl+C sera ignoré par l'exécutable et doit être géré par
l’afficheur\&.
.RE
.PP
\fBX\fP
.RS 4
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\&.
.RE
.sp
Notez que le réglage de la variable d'environnement \fI$LESS\fP normale n'a
aucun effet sur les invocations de \fBless\fP par les outils de systemd\&.
.sp
Voir \fBless\fP(1) pour plus de détails\&.
.RE
.PP
\fI$SYSTEMD_LESSCHARSET\fP
.RS 4
Outrepasser le jeu de caractères passé à \fBless\fP (par défaut « utf\-8 », si
le terminal invoqué est compatible avec l'UTF\-8)\&.
.sp
Notez que le réglage de la variable d'environnement \fI$LESSCHARSET\fP normale
n'a aucun effet sur les invocations de \fBless\fP par les outils de systemd\&.
.RE
.PP
\fI$SYSTEMD_PAGERSECURE\fP
.RS 4
Les commandes d'afficheur courantes comme \fBless\fP(1), en plus de
« l'affichage », c'est\-à\-dire le défilement de la sortie, prennent en charge
l'ouverture et l'écriture d'autres fichiers et l'exécution de commandes
d'interpréteur arbitraires\&. Quand les commandes sont invoquées avec des
privilèges élevés, par exemple sous \fBsudo\fP(8) ou \fBpkexec\fP(1), l'afficheur
devient une limite de sécurité. Il convient de veiller à ce que seuls des
programmes avec des fonctionnalités strictement limitées soient utilisés
comme afficheurs et que les fonctionnalités comme l'ouverture ou la création
de nouveaux fichiers ou le démarrage de sous\-processus ne soient pas
autorisées\&. Un « mode sécurisé » pour l'afficher peut être activé comme
décrit ci\-dessous, \fIsi l'afficheur le prend en charge\fP (la plupart des
afficheurs ne sont pas écrits de façon à prendre cela en
considération)\&. Il est recommandé soit d'activer explicitement le « mode
sécurisé » soit de désactiver complètement l'afficheur en utilisant
\fB\-\-no\-pager\fP ou \fIPAGER=cat\fP lorsque des utilisateurs non fiables sont
autorisés à exécuter des commandes avec des privilèges élevés\.
.sp
Cette option prend un argument booléen\&. Lorsqu'elle est définie à vrai, le
« mode sécurisé » de l'afficheur est activé\&. En « mode sécurisé »,
\fBLESSSECURE=1\fP est défini lors de l'invocation de l'afficheur, ce qui lui
indique de désactiver les commandes qui ouvrent ou créent des fichiers, ou
qui démarrent un nouveau sous\-processus\&. Actuellement, seul \fBless\fP(5) est
connu pour comprendre cette variable et implémenter le « mode sécurisé »\&.
.sp
Quand l'option est définie à faux, aucune limitation n'est imposée à
l'afficheur\&. Définir \fISYSTEMD_PAGERSECURE=0\fP ou ne pas le supprimer de
l'environnement hérité peut permettre à l'utilisateur d'invoquer des
commandes arbitraires\&.
.sp
Quand \fI$SYSTEMD_PAGERSECURE\fP n'est pas défini, les outils de systemd
tentent de déterminer automatiquement si le « mode sécurisé » doit être
activé et si l'afficheur le prend en charge\&. Le « mode sécurisé » est
activé si l'UID effectif est différent de celui du propriétaire de la
session de connexion (voir \fBgeteuid\fP(2)) et \fBsd_pid_get_owner_uid\fP(3)) ou
lors de l'exécution sous \fBsudo\fP(8) ou des outils similaires (\fI$SUDO_UID\fP
est défini à \&\s-2\u[6]\d\s+2)\&. Dans ces cas, \fISYSTEMD_PAGERSECURE=1\fP
sera défini et les afficheurs qui ne sont pas connus pour implémenter le
« mode sécurisé » ne seront pas du tout utilisés. Notez que cette détection
automatique ne couvre que les mécanismes les plus courants d'élévation des
privilèges et qu'elle est conçue pour faciliter la tâche\&. Il est
recommandé de définir explicitement \fI$SYSTEMD_PAGERSECURE\fP ou de désactiver
l'afficheur\&.
.sp
Notez que si les variables \fI$SYSTEMD_PAGER\fP ou \fI$PAGER\fP doivent être
respectées, sauf pour désactiver l'afficheur, \fI$SYSTEMD_PAGERSECURE\fP doit
aussi être défini\&.
.RE
.PP
\fI$SYSTEMD_COLORS\fP
.RS 4
Takes a boolean argument, or a special value\&. By default (unset),
\fBsystemd\fP and related utilities will use colors in their output if
possible\&. If \fI$COLORTERM\fP is set to "truecolor" or "24bit", 24\-bit colors
will be enabled, 256 colors otherwise, unless \fI$NO_COLOR\fP or \fI$TERM\fP
indicates colors are disabled\&.
.PP
\fBtrue\fP
.RS 4
Same as unset, except that \fI$NO_COLOR\fP is ignored\&.
.RE
.PP
\fBfalse\fP
.RS 4
The output will be monochrome\&.
.RE
.PP
"16", "256", "24bit"
.RS 4
Always use the base 16 ANSI colors, 256 colors, or 24 bit color,
respectively\&.
.RE
.PP
"auto\-16", "auto\-256", "auto\-24bit"
.RS 4
Use the given quantity of colours, subject to \fI$TERM\fP, and what the console
is connected to\&.
.RE
.RE
.PP
\fI$SYSTEMD_URLIFY\fP
.RS 4
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
\fBsystemd\fP basée sur \fI$TERM\fP et d'autres conditions\&.
.RE
.PP
\fI$LISTEN_PID\fP, \fI$LISTEN_PIDFDID\fP, \fI$LISTEN_FDS\fP, \fI$LISTEN_FDNAMES\fP
.RS 4
Définition par systemd des processus supervisés lors de l'activation basée
socket\&. Consulter \fBsd_listen_fds\fP(3) pour plus d'informations\&.
.RE
.PP
\fI$NOTIFY_SOCKET\fP
.RS 4
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 \fBsd_notify\fP(3) et la section
concernée ci\-dessous pour plus d'informations\&.
.RE
.PP
Pour les variables d'environnement supplémentaires comprises par systemd et
ses divers composants, consulter \m[blue]\fBVariables d’environnement connues\fP\m[]\&\s-2\u[7]\d\s+2\&.
.SH "LIGNE DE COMMANDE DU NOYAU"
.PP
When run as the system instance, systemd parses a number of options listed
below\&. They can be specified as kernel command line arguments which are
parsed from a number of sources depending on the environment in which
systemd is executed\&. If run inside a Linux container, these options are
parsed from the command line arguments passed to systemd itself, next to any
of the command line options listed in the Options section above\&. If run
outside of Linux containers, these arguments are parsed from /proc/cmdline
instead\&.
.PP
Les variables suivantes sont comprises :
.PP
\fIsystemd\&.unit=\fP, \fIrd\&.systemd\&.unit=\fP
.RS 4
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 \fBsystemd.special\fP(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\&.
.RE
.PP
\fIsystemd\&.dump_core\fP
.RS 4
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)\&.
.sp
Ajouté dans la version 233\&.
.RE
.PP
\fIsystemd\&.crash_chvt\fP
.RS 4
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\(en63) 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\&.
.sp
Ajouté dans la version 233\&.
.RE
.PP
\fIsystemd\&.crash_shell\fP
.RS 4
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\&.
.sp
Ajouté dans la version 233\&.
.RE
.PP
\fIsystemd\&.crash_action=\fP
.RS 4
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
\fIsystemd\&.crash_shell\fP, l'action de plantage configurée est exécutée après
que l'interpréteur de commandes a quitté\&.
.sp
Ajouté dans la version 256\&.
.RE
.PP
\fIsystemd\&.confirm_spawn\fP
.RS 4
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 \fB/dev/console\fP\&. 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\&.
.sp
Ajouté dans la version 233\&.
.RE
.PP
\fIsystemd\&.service_watchdogs=\fP
.RS 4
Prend un argument booléen\&. Si désactivé, tous les chiens de garde
d’exécution de service (\fBWatchdogSet=\fP) et les actions d'urgence
(p. ex. \fBOnFailure=\fP ou \fBStartLimitAction=\fP) sont ignorés par le
gestionnaire du système (PID 1) ; consulter \fBsystemd.service\fP(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\&.
.sp
Ajouté dans la version 237\&.
.RE
.PP
\fIsystemd\&.show_status\fP
.RS 4
Prend un argument booléen ou les constantes \fBerror\fP et \fBauto\fP\&. 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 \fBerror\fP, seuls les messages d'échec sont
affichés, mais sinon l'amorçage est silencieux\&. \fBauto\fP se comporte comme
\fBfalse\fP jusqu'à ce qu'il y ait un délai significatif dans
l'amorçage\&. Activé par défaut, à moins que \fBquiet\fP soit passé comme
option sur la ligne de commandes du noyau, dans lequel cas c'est \fBerror\fP
par défaut\&. Si spécifié, cela écrase l'option du fichier de configuration
\fBShowStatus=\fP du gestionnaire de système, consulter
\fBsystemd\-system.conf\fP(5)\&.
.sp
Ajouté dans la version 233\&.
.RE
.PP
\fIsystemd\&.status_unit_format=\fP
.RS 4
Prend \fBname\fP, \fBdescription\fP ou \fBcombined\fP comme valeur\&. Si \fBname\fP,
alors le gestionnaire de système utilisera les noms d'unité dans les
messages d'état\&. Si \fBcombined\fP, le gestionnaire de système utilisera les
noms et description d’unité dans les messages d’état\&. Lorsque spécifié,
écrase l'option \fBStatusUnitFormat=\fP de la configuration du gestionnaire du
système, voir \fBsystemd\-system.conf\fP(5)\&.
.sp
Ajouté dans la version 243\&.
.RE
.PP
\fIsystemd\&.log_color\fP, \fIsystemd\&.log_level=\fP, \fIsystemd\&.log_location\fP,
\fIsystemd\&.log_target=\fP, \fIsystemd\&.log_time\fP, \fIsystemd\&.log_tid\fP,
\fIsystemd\&.log_ratelimit_kmsg\fP
.RS 4
Contrôle la sortie des journaux, avec le même effet que les variables
d'environnement \fI$SYSTEMD_LOG_COLOR\fP, \fI$SYSTEMD_LOG_LEVEL\fP,
\fI$SYSTEMD_LOG_LOCATION\fP, \fI$SYSTEMD_LOG_TARGET\fP, \fI$SYSTEMD_LOG_TIME\fP,
\fI$SYSTEMD_LOG_TID\fP et \fI$SYSTEMD_LOG_RATELIMIT_KMSG\fP décrites
ci\-dessus\&. \fIsystemd\&.log_color\fP, \fIsystemd\&.log_location\fP,
\fIsystemd\&.log_time\fP, \fIsystemd\&.log_tid\fP et
\fIsystemd\&.log_ratelimit_kmsg\fP peuvent être indiquées sans argument, ayant
le même effet qu'un booléen positif\&.
.RE
.PP
\fIsystemd\&.default_standard_output=\fP, \fIsystemd\&.default_standard_error=\fP
.RS 4
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
\fBStandardOutput=\fP et \fBStandError=\fP (consulter \fBsystemd.exec\fP(5) pour les
détails)\&. Prend l'un de \fBinherit\fP, \fBnull\fP, \fBtty\fP, \fBjournal\fP,
\fBjournal+console\fP, \fBkmsg\fP, \fBkmsg+console\fP\&. Si l'argument est omis,
\fIsystemd\&.default\-standard\-output=\fP sera par défaut \fBjournal\fP et
\fIsystemd\&.default\-standard\-error=\fP \fBinherit\fP\&.
.RE
.PP
\fIsystemd\&.setenv=\fP
.RS 4
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\&.
.RE
.PP
\fIsystemd\&.machine_id=\fP
.RS 4
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\&.
.sp
Ajouté dans la version 229\&.
.RE
.PP
\fIsystemd\&.set_credential=\fP, \fIsystemd\&.set_credential_binary=\fP
.RS 4
Définit un justificatif d'identité du système, qui peut alors être propagé
aux services du système en utilisant le réglage \fIImportCredential=\fP ou
\fILoadCredential=\fP, consulter \fBsystemd.exec\fP(5) pour plus de
détails\&. Prend une paire de justificatifs de nom et valeur, séparés par un
deux\-points (\fB:\fP)\&. 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\&.
.sp
Pour plus d'informations, consulter la documentation \m[blue]\fBIdentifiants du système et des services\fP\m[]\&\s-2\u[8]\d\s+2\&.
.sp
Ajouté dans la version 251\&.
.RE
.PP
\fIsystemd\&.import_credentials=\fP
.RS 4
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\&.
.sp
Ajouté dans la version 251\&.
.RE
.PP
\fIquiet\fP
.RS 4
Désactiver la sortie d'état à l'amorçage, comme ferait
\fIsystemd&.show_status=no\fP\&. 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\&.
.sp
Ajouté dans la version 186\&.
.RE
.PP
\fIdebug\fP
.RS 4
Désactiver la sortie d'état à l'amorçage, comme ferait
\fIsystemd&.show_status=no\fP\&. 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\&.
.sp
Ajouté dans la version 205\&.
.RE
.PP
\fIemergency\fP, \fIrd\&.emergency\fP, \fI\-b\fP
.RS 4
Démarrer en mode urgence\&. C'est l'équivalent de
\fIsystemd\&.unit=emergency\&.target\fP ou
\fIrd\&.systemd\&.unit=emergency\&.target\fP respectivement, et est fourni pour
des besoins de compatibilité et pour être plus simples à taper\&.
.sp
Ajouté dans la version 186\&.
.RE
.PP
\fIrescue\fP, \fIrd\&.rescue\fP, \fIsingle\fP, \fIs\fP, \fIS\fP, \fI1\fP
.RS 4
Démarrer en mode sauvetage (rescue). C'est l'équivalent de
\fIsystemd\&.unit=rescue\&.target\fP ou \fIrd\&.systemd\&.unit=rescue\&.target\fP
respectivement, et est fourni pour des raisons de compatibilité et être plus
simple à saisir\&.
.sp
Ajouté dans la version 186\&.
.RE
.PP
\fI2\fP, \fI3\fP, \fI4\fP, \fI5\fP
.RS 4
Amorcer en niveau d’exécution patrimonial (legacy) spécifié de SysV\&. \fI2\fP,
\fI3\fP et \fI4\fP sont équivalents à \fIsystemd\&.unit=multi\-user\&.target\fP ; \fI5\fP
est équivalent à \fIsystemd\&.unit=graphical\&.target\fP et est fourni pour
raison de compatibilité et de simplification de saisie\&.
.sp
Ajouté dans la version 186\&.
.RE
.PP
\fIlocale\&.LANG=\fP, \fIlocale\&.LANGUAGE=\fP, \fIlocale\&.LC_CTYPE=\fP,
\fIlocale\&.LC_NUMERIC=\fP, \fIlocale\&.LC_TIME=\fP, \fIlocale\&.LC_COLLATE=\fP,
\fIlocale\&.LC_MONETARY=\fP, \fIlocale\&.LC_MESSAGES=\fP, \fIlocale\&.LC_PAPER=\fP,
\fIlocale\&.LC_NAME=\fP, \fIlocale\&.LC_ADDRESS=\fP, \fIlocale\&.LC_TELEPHONE=\fP,
\fIlocale\&.LC_MEASUREMENT=\fP, \fIlocale\&.LC_IDENTIFICATION=\fP
.RS 4
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
\fBlocale.conf\fP(5) et \fBlocale\fP(7)\&.
.sp
Ajouté dans la version 186\&.
.RE
.PP
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 à
\fBkernel\-command\-line\fP(7)\&.
.SH "INFORMATIONS D'IDENTIFICATION DU SYSTÈME"
.PP
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 :
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Lorsque le gestionnaire de services s'initialisera, il lira les informations
d'identification depuis les chaînes du vendeur Type 11 SMBIOS
\fIio\&.systemd\&.credential:\fP\fInom\fP\fI=\fP\fIvaleur\fP, et
\fIio\&.systemd\&.credential\&.binary:\fP\fInom\fP\fI=\fP\fIvaleur\fP\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
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\&.)
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Les informations d'identification doivent être passées au noyau à l'aide de
la ligne de commande en utilisant le paramètre \fIsystemd\&.set\-credential=\fP,
voir ci\-dessus\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Les informations d'identification doivent être passées de l'environnement
UEFI avec \fBsystemd\-stub\fP(7)\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
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\&.
.RE
.PP
Invoquer \fBsystemd\-creds\fP(1) comme il suit pour visualiser la liste
d'informations d'identification passées au système :
.sp
.if  n \{\
.RS 4
.\}
.nf
# systemd\-creds \-\-system list
.fi
.if  n \{\
.RE
.\}
.PP
Pour plus d'informations, consulter la documentation \m[blue]\fBIdentifiants du système et des services\fP\m[]\&\s-2\u[8]\d\s+2\&.
.PP
Le gestionnaire de services consomme les informations d'identification
suivantes du système lorsque lancé en tant que PID 1 :
.PP
\fIvmm\&.notify_socket\fP
.RS 4
Contient une adresse \fBAF_VSOCK\fP ou \fBAF_UNIX\fP où envoyer un message de
notification \fBREADY=1\fP lorsque le système a complètement démarré\&. Voir
\fBsd_notify\fP(3) et la section suivante pour plus d'informations\&. À noter
que dans le cas où l'hyperviseur ne gère pas \fBSOCK_DGRAM\fP pour \fBAF_VSOCK\fP,
\fBSOCK_SEQPACKET\fP sera essayé à la place\&. La charge utile de l'information
d'identification pour \fBAF_VSOCK\fP 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\&.
.sp
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\&.
.sp
Ajouté dans la version 254\&.
.RE
.PP
\fIsystem\&.machine_id\fP
.RS 4
Prend une ID hexadécimale de 128 octets pour y initialiser /etc/machine\-id,
si le fichier n'est pas encore prêt\&. Voir \fBmachine\-id\fP(5) pour les
détails\&.
.sp
Ajouté dans la version 254\&.
.RE
.PP
Pour une liste des identifiants du système que divers autres composants de
systemd utilisent, voir \fBsystemd.system\-credentials\fP(7)\&.
.SH "PROTOCOLE DE DISPONIBILITÉ"
.PP
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 \fBsd_notify\fP(3)\&.
.PP
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 \fI$NOTIFY_SOCKET\fP (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 \fIvmm\&.notify_socket\fP (voir
ci\-dessus) peut être réglé à un socket adapté (généralement un de
\fBAF_VSOCK\fP) à l’aide de chaînes SMBIOS Type 11 de fournisseur\&. Pour les
détails voir ci\-dessus\&.
.PP
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 :
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Un message \fIX_SYSTEMD_HOSTNAME=\&...\fP 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\&.
.sp
Ajouté dans la version 256\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Un message \fIX_SYSTEMD_MACHINE_ID=\&...\fP sera envoyé une fois que
l'identifiant machine du système aura été déterminé\&. Voir \fBmachine\-id\fP(5)
pour les détails\&.
.sp
Ajouté dans la version 256\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Un message \fIX_SYSTEMD_SIGNALS_LEVEL=\&...\fP 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 :
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
\fIX_SYSTEMD_SIGNALS_LEVEL=2\fP 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\&.
.RE
.sp
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\&.
.sp
Ajouté dans la version 256\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Des messages \fIX_SYSTEMD_UNIT_ACTIVE=\&...\fP et
\fIX_SYSTEMD_UNIT_INACTIVE=\&...\fP 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 \fBsystemd.special\fP(7) pour les détails\&.
.sp
Ajouté dans la version 256\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Un message \fIX_SYSTEMD_SHUTDOWN=\&...\fP 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\&.
.sp
Ajouté dans la version 256\&.
.RE
.sp
.RS 4
.ie  n \{\
\h'-04'\(bu\h'+03'\c
.\}
.el \{\
.sp -1
.IP \(bu 2.3
.\}
Un message \fIX_SYSTEMD_REBOOT_PARAMETER=\&...\fP sera aussi envoyé juste avant
que le système ne s'éteigne\&. Sa valeur est l'argument de redémarrage comme
configuré avec \fBsystemctl \-\-reboot\-argument=\&...\fP\&.
.sp
Ajouté dans la version 256\&.
.RE
.PP
Notez que ces champs d'extension sont envoyés en plus des notifications
habituelles « READY=1 » et « RELOADING=1 »\&.
.SH OPTIONS
.PP
\fBsystemd\fP 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
\fBsystemctl\fP(1) sont utilisés pour passer les commandes au
gestionnaire\&. Comme \fBsystemd\fP 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\&.
.SS "Options d'introspection et de débogage"
.PP
Ces options sont utilisées pour les tests et l'introspection, et \fBsystemd\fP
peut être invoqué avec elles à tout moment :
.PP
\fB\-\-dump\-configuration\-items\fP
.RS 4
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\&.
.RE
.PP
\fB\-\-dump\-bus\-properties\fP
.RS 4
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\&.
.sp
Ajouté dans la version 239\&.
.RE
.PP
\fB\-\-test\fP
.RS 4
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 \(em
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 \fB\-\-system\fP pour demander la
transaction initiale du gestionnaire de service système (c'est aussi la
valeur implicite par défaut), combinez avec \fB\-\-user\fP pour demander la
transaction initiale du gestionnaire de service par utilisateur à la
place\&.
.RE
.PP
\fB\-\-system\fP, \fB\-\-user\fP
.RS 4
Lorsqu'utilisé avec \fB\-\-test\fP, 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
\fB\-\-test\fP, comme durant d'usuels appels (c’est\-à\-dire sans \fB\-\-test\fP) 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 \fB1\fP 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
\fB\-\-system\fP mais avec un PID autre que \fB1\fP\&.
.RE
.PP
\fB\-h\fP, \fB\-\-help\fP
.RS 4
Afficher un aide\-mémoire succinct et quitter\&.
.RE
.PP
\fB\-\-version\fP
.RS 4
Afficher une information de version courte et quitter\&.
.RE
.SS "Options pour dupliquer en ligne de commande les réglages du noyau"
.PP
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\&.
.PP
Lorsque \fBsystemd\fP 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, \fBsystemd\fP est généralement démarré dans ce mode,
à travers le service \fBuser@service\fP(5), qui est partagé entre tous les
utilisateurs\&. Il est plus aisé d'utiliser les fichiers de configuration
pour modifier les réglages (voir \fBsystemd\-user.conf\fP(5)) ou les variables
d'environnement\&. Consulter la section « Environnement » ci\-dessus pour des
explications sur comment est défini le bloc environnement\&.
.PP
\fB\-\-unit=\fP
.RS 4
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 \fIsystemd\&.unit=\fP
ci\-dessus\&.
.RE
.PP
\fB\-\-dump\-core\fP
.RS 4
Activer le vidage du cœur en cas de plantage\&. Cela n'a aucun effet
lorsqu'utilisé sous une instance utilisateur\&. Pareil à
\fIsystemd\&.dump_core=\fP ci\-dessus\&.
.RE
.PP
\fB\-\-crash\-vt=\fP\fIVT\fP
.RS 4
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 \fIsystemd\&.crash_chvt=\fP ci\-dessus (mais pas
l’orthographe différente !)\&.
.sp
Ajouté dans la version 227\&.
.RE
.PP
\fB\-\-crash\-shell\fP
.RS 4
Lancer un interpréteur de commandes lors d'un plantage\&. Cela n'a aucun
effet si lancé depuis une instance utilisateur\&. Voir
\fIsystemd\&.crash_shell=\fP ci\-dessus\&.
.RE
.PP
\fB\-\-crash\-action=\fP
.RS 4
Indiquer quoi faire en cas de plantage du gestionnaire du système
(PID 1)\&. Cela n'a aucun effet si \fBsystemd\fP est lancé comme instance
utilisateur\&. Voir \fIsystemd\&.crash_action=\fP ci\-dessus\&.
.sp
Ajouté dans la version 256\&.
.RE
.PP
\fB\-\-confirm\-spawn\fP
.RS 4
Demander confirmation lors de la création de processus\&. Cela n'a aucun
effet lancé en instance utilisateur\&. Voir \fIsystemd\&.confirm_spawn\fP
ci\-dessus\&.
.RE
.PP
\fB\-\-show\-status\fP
.RS 4
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 \fIsystemd\&.show_status\fP
ci\-dessus\&.
.sp
Ajouté dans la version 244\&.
.RE
.PP
\fB\-\-log\-color\fP
.RS 4
Mettre en surbrillance les messages journal importants\&. Voir
\fIsystemd\&.log_color\fP ci\-dessus\&.
.sp
Ajouté dans la version 244\&.
.RE
.PP
\fB\-\-log\-level=\fP
.RS 4
Définir le niveau de journalisation\&. Voir \fIsystemd\&.log_level\fP
ci\-dessus\&.
.RE
.PP
\fB\-\-log\-location\fP
.RS 4
Inclure l'emplacement du code dans les messages journal\&. Voir
\fIsystemd\&.log_location\fP ci\-dessus\&.
.sp
Ajouté dans la version 244\&.
.RE
.PP
\fB\-\-log\-target=\fP
.RS 4
Définir la cible du journal\&. Voir \fIsystemd\&.log_target\fP ci\-dessus\&.
.RE
.PP
\fB\-\-log\-time=\fP
.RS 4
Préfixer les messages de la console avec un horodatage\&. Voir
\fIsystemd\&.log_time\fP ci\-dessus\&.
.sp
Ajouté dans la version 246\&.
.RE
.PP
\fB\-\-machine\-id=\fP
.RS 4
Écraser l'identifiant de la machine défini sur le disque dur\&. Voir
\fIsystemd\&.machine_id=\fP ci\-dessus\&.
.sp
Ajouté dans la version 229\&.
.RE
.PP
\fB\-\-service\-watchdogs\fP
.RS 4
Activer ou désactiver de façon globale toutes les actions urgentes ou
minutées du service chien de garde\&. Voir \fIsystemd\&.service_watchdogs\fP
ci\-dessus\&.
.sp
Ajouté dans la version 237\&.
.RE
.PP
\fB\-\-default\-standard\-output=\fP, \fB\-\-default\-standard\-error=\fP
.RS 4
Définition de la sortie par défaut ou la sortie d'erreur pour tous les
services et les sockets respectivement\&. Voir
\fIsystemd\&.default_standard_output=\fP et
\fIsystemd\&.default_standard_error=\fP ci\-dessus\&.
.RE
.SH "EPOCH DE L'HORLOGE SYSTÈME"
.PP
Lorsque \fBsystemd\fP 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\&.
.PP
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 \fIavancée\fP 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 \fIramenée\fP à l'epoch\&.
.PP
L'epoch est réglée à la valeur la plus récente des dates suivantes : le
moment de construction de \fBsystemd\fP, la date de modification (« mtime ») de
\fI/usr/lib/clock\-epoch\fP ou la date de modification de
\fI/var/lib/systemd/timesync/clock\fP\&.
.SH FICHIERS
.PP
/run/systemd/notify
.RS 4
Socket de notification de l'état du démon\&. C'est un socket datagramme
\fBAF_UNIX\fP qui est utilisé pour implémenter la logique de notification du
démon comme implémenté par \fBsd_notify\fP(3)\&.
.RE
.PP
/run/systemd/private
.RS 4
Utilisé en interne comme canal de communication entre \fBsystemctl\fP(1) et le
processus systemd\&. C'est un socket flux \fBAF_UNIX\fP\&. Cette interface est
personnelle à systemd et ne devrait pas être utilisée pour des projets
extérieurs\&.
.RE
.PP
/usr/lib/clock\-epoch
.RS 4
La date de modification (« mtime ») de ce fichier est utilisée pour l'heure
de l'epoch, voir la section précédente\&.
.sp
Ajouté dans la version 247\&.
.RE
.PP
/var/lib/systemd/timesync/clock
.RS 4
La date de modification (« mtime ») de ce fichier est mise à jour par
\fBsystemd\-timesyncd.service\fP(8)\&. Si présente, la date de modification du
fichier est utilisée pour l'epoch, voir la section précédente\&.
.sp
Ajouté dans la version 257\&.
.RE
.SH HISTORIQUE
.PP
systemd 252
.RS 4
Les arguments de la ligne de commandes du noyau
\fIsystemd\&.unified_cgroup_hierarchy\fP et
\fIsystemd\&.legacy_systemd_cgroup_controller\fP sont considérés
obsolètes\&. Veuillez changer pour une hiérarchie cgroups unifiée\&.
.RE
.SH "VOIR AUSSI"
.PP
La \m[blue]\fBpage d’accueil de systemd\fP\m[]\&\s-2\u[9]\d\s+2,
\fBsystemd\-system.conf\fP(5), \fBlocale.conf\fP(5), \fBsystemctl\fP(1),
\fBjournalctl\fP(1), \fBsystemd\-notify\fP(1), \fBdaemon\fP(7), \fBsd\-daemon\fP(3),
\fBorg.freedesktop.systemd1\fP(5), \fBsystemd.unit\fP(5), \fBsystemd.special\fP(7),
\fBpkg\-config\fP(1), \fBkernel\-command\-line\fP(7), \fBbootup\fP(7),
\fBsystemd.directives\fP(7), \fBorg.freedesktop.systemd1\fP(5)
.PP
Pour davantage d'informations sur les concepts et idées derrière \fBsystemd\fP,
veuillez consulter le \m[blue]\fBDocument de conception originel\fP\m[]\&\s-2\u[10]\d\s+2\&.
.SH NOTES
.IP " 1." 4
Portabilité d'interface et promesse de stabilité
.RS 4
\%https://systemd.io/PORTABILITY_AND_STABILITY/
.RE
.IP " 2." 4
Interface conteneur
.RS 4
\%https://systemd.io/CONTAINER_INTERFACE
.RE
.IP " 3." 4
Interface initrd
.RS 4
\%https://systemd.io/INITRD_INTERFACE/
.RE
.IP " 4." 4
Groupes de contrôle version 2
.RS 4
\%https://docs.kernel.org/admin\-guide/cgroup\-v2.html
.RE
.IP " 5." 4
Spécification du répertoire de base XDG
.RS 4
\%https://standards.freedesktop.org/basedir\-spec/basedir\-spec\-latest.html
.RE
.IP " 6." 4
Il est recommandé pour les autres outils de définir et vérifier \fI$SUDO_UID\fP
comme il convient, en le considérant comme une interface courante.
.IP " 7." 4
Variables d'environnement connues
.RS 4
\%https://systemd.io/ENVIRONMENT
.RE
.IP " 8." 4
Identifiants du système et des services
.RS 4
\%https://systemd.io/CREDENTIALS
.RE
.IP " 9." 4
Page d’accueil de systemd
.RS 4
\%https://systemd.io/
.RE
.IP 10. 4
Document de conception originel
.RS 4
\%https://0pointer.de/blog/projects/systemd.html
.RE
.PP
.SH TRADUCTION
La traduction française de cette page de manuel a été créée par
bubu <bubub@no-log.org>
.
.PP
Cette traduction est une documentation libre ; veuillez vous reporter à la
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License version 3
.UE
concernant les conditions de copie et 
de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
.PP
Si vous découvrez un bogue dans la traduction de cette page de manuel, 
veuillez envoyer un message à
.MT debian-l10n-french@lists.debian.org
.ME .