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