Ubuntu Manpage: systemd, init – Gestionnaire de services et de système systemd

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.

CONCEPTS

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 être « actives » (c-à-d démarrées, liées,
branchées, ... selon le type d'unité, voir ci-dessous), ou « inactives » (c-à-d stoppées,
déliées, débranchées,...), ainsi que dans le processus d'être activées ou désactivées,
c-à-d entre les deux états (ces états sont nommés « activation » et « désactivation »). Un
état spécial nommé « échec » existe aussi, qui est très similaire à « inactif » et est
entré lorsque le service échoue en quelque manière (le processus renvoie un code d'erreur
à la sortie, ou plante, le délai d'une opération a expiré, ou après d'incessants
redémarrages). Si cet état est entré, la cause sera enregistrée dans un journal, pour une
référence ultérieure. 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 cinq états généraux
d'unités décrits ici.

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-à-d. 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-à-d 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.

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/.

Pour davantage d'informations sur les concepts et idées derrière systemd, veuillez
consulter le Document de conception originel[2].

Notez que certaines, mais pas toutes, interfaces fournies par systemd sont couvertes par
la Portabilité d'interface et promesse de stabilité[3].

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).

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.

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-à-d 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'endroit où est placé le 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'endroit 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

The service listens to various UNIX process signals that can be used to request various
actions asynchronously. The signal handling is enabled very early during boot, before any
further processes are invoked. However, a supervising container manager or similar that
intends to request these operations via this mechanism must take into consideration that
this functionality is not available during the earliest initialization phase. An
sd_notify() notification message carrying the X_SYSTEMD_SIGNALS_LEVEL=2 field is emitted
once the signal handlers are enabled, see below. This may be used to schedule submission
of these signals correctly.

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 très
similaire à systemctl daemon-reexec.

Les gestionnaires d'utilisateur de systemd démarreront l'unité exit.target quand le
signal est reçu. Cela est généralement l'équivalent de 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 généralement 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 généralement é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 généralement é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 généralement équivalent à
systemctl daemon-reload.

SIGRTMIN+0
Entrer en mode par défaut, démarrer l'unité default.target. Cela est généralement
équivalent à systemctl isolate default.target.

SIGRTMIN+1
Entrer en mode de secours (rescue), démarrer l'unité rescue.target. Cela est
généralement équivalent à systemctl isolate rescue.target.

SIGRTMIN+2
Entrer en mode urgence, démarrer l'unité emergency.service. Cela est généralement
équivalent à systemctl isolate emergency.service.

SIGRTMIN+3
Arrêter la machine, démarrer l'unité halt.target. Cela est généralement équivalent à
systemctl start halt.target --job-mode=replace-irreversibly.

SIGRTMIN+4
Éteindre la machine, démarrer l'unité poweroff.target. Cela est généralement
é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
généralement é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
généralement é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 généralement é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.

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.

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 généralement é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
The maximum log level of emitted messages (messages with a higher log level, i.e. less
important ones, will be suppressed). Takes a comma-separated list of values. A value
may be either one of (in order of decreasing importance) emerg, alert, crit, err,
warning, notice, info, debug, or an integer in the range 0...7. See syslog(3) for more
information. Each value may optionally be prefixed with one of console, syslog, kmsg
or journal followed by a colon to set the maximum log level for that specific log
target (e.g. SYSTEMD_LOG_LEVEL=debug,console:info specifies to log at debug level
except when logging to the console which should be at info level). Note that the
global maximum log level takes priority over any per target maximum log levels.

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
Set by service manager for its services for status and readiness notifications. Also
consumed by service manager for notifying supervising container managers or service
managers up the stack about its own progress. See sd_notify(3) and the relevant
section below for more information.

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, après un délai de dix secondes. 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 protégé par aucune authentification par mot de
passe.

Ajouté dans la version 233.

systemd.crash_action=
Takes one of "freeze", "reboot" or "poweroff". Defaults to "freeze". If set to
"freeze", the system will hang indefinitely when the system manager (PID 1) crashes.
If set to "reboot", the system manager (PID 1) will reboot the machine automatically
when it crashes, after a 10s delay. If set to "poweroff", the system manager (PID 1)
will power off the machine immediately when it crashes. If combined with
systemd.crash_shell, the configured crash action is executed after the shell exits.

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-a-d 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
Afficher la sortie du débogage. Cela est équivalent à systemd.log_level=debug. Notez
aussi que cette option est aussi lue par le noyau et active la sortie débogage du
noyau. Passer cette option démarre donc la sortie du débogage à la fois du
gestionnaire du 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
Contains a AF_VSOCK or AF_UNIX address where to send a READY=1 notification message
when the service manager has completed booting. See sd_notify(3) and the next section
for more information. Note that in case the hypervisor does not support SOCK_DGRAM
over AF_VSOCK, SOCK_SEQPACKET will be tried instead. The credential payload for
AF_VSOCK should be a string in the form "vsock:CID:PORT". "vsock-stream",
"vsock-dgram" and "vsock-seqpacket" can be used instead of "vsock" to force usage of
the corresponding socket type.

This feature is useful for machine managers or other processes on the host to receive
a notification via VSOCK when a virtual machine has finished booting.

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.

For a list of system credentials various other components of systemd consume, see
systemd.system-credentials(7).

READINESS PROTOCOL

The service manager implements a readiness notification protocol both between the manager
and its services (i.e. down the stack), and between the manager and a potential supervisor
further up the stack (the latter could be a machine or container manager, or in case of a
per-user service manager the system service manager instance). The basic protocol (and the
suggested API for it) is described in sd_notify(3).

The notification socket the service manager (including PID 1) uses for reporting readiness
to its own supervisor is set via the usual $NOTIFY_SOCKET environment variable (see
above). Since this is directly settable only for container managers and for the per-user
instance of the service manager, an additional mechanism to configure this is available,
in particular intended for use in VM environments: the vmm.notify_socket system credential
(see above) may be set to a suitable socket (typically an AF_VSOCK one) via SMBIOS Type 11
vendor strings. For details see above.

The notification protocol from the service manager up the stack towards a supervisor
supports a number of extension fields that allow a supervisor to learn about specific
properties of the system and track its boot progress. Specifically the following fields
are sent:

• An X_SYSTEMD_HOSTNAME=... message will be sent out once the initial hostname for the
system has been determined. Note that during later runtime the hostname might be
changed again programmatically, and (currently) no further notifications are sent out
in that case.

Ajouté dans la version 256.

• An X_SYSTEMD_MACHINE_ID=... message will be sent out once the machine ID of the system
has been determined. See machine-id(5) for details.

Ajouté dans la version 256.

• An X_SYSTEMD_SIGNALS_LEVEL=... message will be sent out once the service manager
installed the various UNIX process signal handlers described above. The field's value
is an unsigned integer formatted as decimal string, and indicates the supported UNIX
process signal feature level of the service manager. Currently, only a single feature
level is defined:

• X_SYSTEMD_SIGNALS_LEVEL=2 covers the various UNIX process signals documented above
– which are a superset of those supported by the historical SysV init system.

Signals sent to PID 1 before this message is sent might not be handled correctly yet.
A consumer of these messages should parse the value as an unsigned integer indication
the level of support. For now only the mentioned level 2 is defined, but later on
additional levels might be defined with higher integers, that will implement a
superset of the currently defined behaviour.

Ajouté dans la version 256.

• X_SYSTEMD_UNIT_ACTIVE=... and X_SYSTEMD_UNIT_INACTIVE=... messages will be sent out
for each target unit as it becomes active or stops being active. This is useful to
track boot progress and functionality. For example, once the ssh-access.target unit is
reported started SSH access is typically available, see systemd.special(7) for
details.

Ajouté dans la version 256.

• An X_SYSTEMD_SHUTDOWN=... message will be sent out very shortly before the system
shuts down. The value is one of the strings "reboot", "halt", "poweroff", "kexec" and
indicates which kind of shutdown is being executed.

Ajouté dans la version 256.

• An X_SYSTEMD_REBOOT_PARAMETER=... message will also be sent out very shortly before
the system shuts down. Its value is the reboot argument as configured with systemctl
--reboot-argument=....

Ajouté dans la version 256.

Note that these extension fields are sent in addition to the regular "READY=1" and
"RELOADING=1" notifications.

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=
Specify what to do when the system manager (PID 1) crashes. This switch has no effect
when systemd is running as user instance. See systemd.crash_action= above.

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.

SOCKETS ET FIFOS

       /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.

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[9], 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)

NOTES

        1. Groupes de contrôle version 2
           https://docs.kernel.org/admin-guide/cgroup-v2.html

        2. Document de conception originel
           https://0pointer.de/blog/projects/systemd.html

        3. Portabilité d'interface et promesse de stabilité
           https://systemd.io/PORTABILITY_AND_STABILITY/

        4. Interface conteneur
           https://systemd.io/CONTAINER_INTERFACE

        5. Interface initrd
           https://systemd.io/INITRD_INTERFACE/

        6. Spécification du répertoire de base XDG
           https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

        7. Variables d'environnement connues
           https://systemd.io/ENVIRONMENT

        8. Identifiants du système et des services
           https://systemd.io/CREDENTIALS

        9. Page d’accueil de systemd
           https://systemd.io/

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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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⟩.