systemd - En ligne dans le Cloud

PROGRAMME:

Nom

systemd, init - gestionnaire de système et de service systemd

SYNOPSIS

systemd [OPTIONS...]

init [OPTIONS...] {COMMANDER}

DESCRIPTION

systemd est un gestionnaire de systèmes et de services pour les systèmes d'exploitation Linux. Lorsqu'il est exécuté en premier
processus au démarrage (comme PID 1), il agit comme un système d'initialisation qui affiche et maintient l'espace utilisateur
prestations de service.

Pour la compatibilité avec SysV, si systemd est appelé en tant que init et un PID qui n'est pas 1, il sera
exécuter télinit et passez tous les arguments de ligne de commande sans modification. Cela signifie init et
télinit sont pour la plupart équivalents lorsqu'ils sont invoqués à partir de sessions de connexion normales. Voir télinit(8) pour
pour en savoir davantage.

Lorsqu'il est exécuté en tant qu'instance système, systemd interprète le fichier de configuration system.conf et
les fichiers dans les répertoires system.conf.d ; lorsqu'il est exécuté en tant qu'instance utilisateur, systemd interprète
le fichier de configuration user.conf et les fichiers dans les répertoires user.conf.d. Voir systèmed-
système.conf(5) pour plus d'informations.

OPTIONS

Les options suivantes sont comprises :

--test
Déterminez la séquence de démarrage, videz-la et quittez. Ceci est une option utile pour le débogage
seulement.

--dump-éléments-de-configuration
Videz les éléments de configuration de l'unité compris. Cela produit une liste laconique mais complète de
éléments de configuration compris dans les fichiers de définition d'unité.

--unité=
Définissez l'unité par défaut pour l'activer au démarrage. Si non spécifié, la valeur par défaut est default.target.

--système, --utilisateur
Pour --système, dites à systemd d'exécuter une instance système, même si l'ID de processus n'est pas 1,
c'est-à-dire que systemd n'est pas exécuté en tant que processus d'initialisation. --utilisateur fait le contraire, en exécutant un utilisateur
instance même si l'ID de processus est 1. Normalement, il ne devrait pas être nécessaire de passer
ces options, car systemd détecte automatiquement le mode dans lequel il est démarré. Ces
les options sont donc peu utiles, sauf pour le débogage. Notez qu'il n'est pas pris en charge
démarrer et maintenir un système complet avec systemd en cours d'exécution --système mode, mais PID
non 1. En pratique, passer --système n'est explicitement utile qu'en conjonction avec
--test.

--dump-core
Activer le vidage du noyau en cas de plantage. Ce commutateur n'a aucun effet lors de l'exécution en tant qu'instance utilisateur.
Ce paramètre peut également être activé lors du démarrage sur la ligne de commande du noyau via le
systemd.dump_core= option, voir ci-dessous.

--crash-vt=VT
Basculez vers une console virtuelle (VT) spécifique en cas de plantage. Prend un entier positif dans le
plage 1-63, ou un argument booléen. Si un entier est passé, sélectionne le VT à basculer
à. Si oui, les messages du noyau VT sont écrits est sélectionné. Si aucune, aucun commutateur VT n'est
tenté. Ce commutateur n'a aucun effet lors de l'exécution en tant qu'instance utilisateur. Ce paramètre peut
également être activé lors du démarrage, sur la ligne de commande du noyau via le systemd.crash_vt=
option, voir ci-dessous.

--crash-shell
Exécutez un shell en cas de plantage. Ce commutateur n'a aucun effet lors de l'exécution en tant qu'instance utilisateur. Cette
Le paramètre peut également être activé pendant le démarrage, sur la ligne de commande du noyau via le
systemd.crash_shell= option, voir ci-dessous.

--crash-redémarrage
Redémarrez automatiquement le système en cas de crash. Ce commutateur n'a aucun effet lorsqu'il est exécuté en tant que
instance d'utilisateur. Ce paramètre peut également être activé lors du démarrage, sur la commande du noyau
ligne via le systemd.crash_reboot= option, voir ci-dessous.

--confirm-spawn
Demandez une confirmation lors de la génération de processus. Ce commutateur n'a aucun effet lorsqu'il est exécuté en tant que
instance d'utilisateur.

--show-statut=
Afficher des informations succinctes sur l'état du service lors du démarrage. Ce commutateur n'a aucun effet lorsque
exécuter en tant qu'instance utilisateur. Prend un argument booléen qui peut être omis qui est
interprété comme oui.

--log-cible=
Définir la cible du journal. L'argument doit être l'un des console, Journal, kmsg, journal-ou-kmsg, nul.

--log-level=
Définir le niveau de journal. Comme argument, cela accepte un niveau de log numérique ou le bien connu
syslog(3) noms symboliques (minuscules) : émergents, alerter, Critique, se tromper, avertissement, avis, info,
déboguer.

--log-color=
Mettez en surbrillance les messages de journal importants. L'argument est une valeur booléenne. Si l'argument est
omis, il vaut par défaut oui.

--log-emplacement=
Inclure l'emplacement du code dans les messages du journal. Ceci est principalement pertinent à des fins de débogage.
L'argument est une valeur booléenne. Si l'argument est omis, la valeur par défaut est oui.

--default-standard-output=, --default-standard-erreur=
Définit la sortie par défaut ou la sortie d'erreur pour tous les services et sockets, respectivement.
C'est-à-dire qu'il contrôle la valeur par défaut pour Sortie Standard= et ErreurStandard= (voir
systemd.exec(5) pour les détails). Prend l'un des hériter, nul, tty, Journal,
revue+console, syslog, syslog+console, kmsg, kmsg+console. Si l'argument est
omis --default-standard-output= Par défaut Journal et --default-standard-erreur=
à hériter.

--id-machine=
Remplacez l'identifiant de la machine défini sur le disque dur, utile pour le démarrage réseau ou pour
conteneurs. Peut ne pas être réglé sur tous les zéros.

-h, --Aidez-moi
Imprimez un court texte d'aide et quittez.

--version
Imprime une chaîne de version courte et quitte.

NOTIONS

systemd fournit un système de dépendances entre différentes entités appelées "unités" de 12
différents types. Les unités encapsulent divers objets pertinents pour le démarrage du système
et entretien. La majorité des unités sont configurées dans des fichiers de configuration d'unités, dont
la syntaxe et l'ensemble d'options de base sont décrits dans systemd.unité(5), cependant certains sont créés
automatiquement à partir d'une autre configuration, dynamiquement à partir de l'état du système ou par programmation
à l'exécution. Les unités peuvent être « actives » (c'est-à-dire démarrées, liées, branchées, ..., selon
le type d'unité, voir ci-dessous), ou "inactif" (c'est-à-dire arrêté, délié, débranché, ...), comme
ainsi qu'en cours d'activation ou de désactivation, c'est-à-dire entre les deux états
(ces états sont appelés "activation", "désactivation"). Un état spécial "en échec" est
disponible également, ce qui est très similaire à "inactif" et est entré lorsque le service
a échoué d'une manière ou d'une autre (le processus a renvoyé un code d'erreur à la sortie, ou s'est écrasé, ou une opération a été chronométrée
dehors). Si cet état est entré, la cause sera enregistrée, pour référence ultérieure. Noter que
les différents types d'unités peuvent avoir un certain nombre de sous-états supplémentaires, qui sont mappés sur le
cinq états unitaires généralisés décrits ici.

Les types d'unités suivants sont disponibles :

1. Unités de service, qui démarrent et contrôlent les démons et les processus qui les composent. Pour
détails, voir systemd.service (5).

2. Unités de socket, qui encapsulent les sockets IPC ou réseau locaux dans le système, utiles pour
activation basée sur les sockets. Pour plus de détails sur les unités de socket, voir systemd.socket(5), pour
détails sur l'activation basée sur les sockets et d'autres formes d'activation, voir démon (7).

3. Les unités cibles sont utiles pour regrouper des unités ou fournir des points de synchronisation bien connus
pendant le démarrage, voir systemd.cible (5).

4. Les unités de périphérique exposent les périphériques du noyau dans systemd et peuvent être utilisées pour implémenter
activation basée sur l'appareil. Pour plus de détails, voir systemd.device (5).

5. Les unités de montage contrôlent les points de montage dans le système de fichiers, pour plus de détails voir systemd.mount (5).

6. Les unités de montage automatique offrent des capacités de montage automatique, pour le montage à la demande de systèmes de fichiers
ainsi que le démarrage parallélisé. Voir systemd.automount (5).

7. Les unités de minuterie sont utiles pour déclencher l'activation d'autres unités en fonction des minuteries. Tu
peut trouver des détails dans systemd.timer (5).

8. Les unités d'échange sont très similaires aux unités de montage et encapsulent les partitions d'échange de mémoire ou
fichiers du système d'exploitation. Ils sont décrits dans systemd.swap (5).

9. Les unités de chemin peuvent être utilisées pour activer d'autres services lorsque les objets du système de fichiers changent ou
sont modifiés. Voir systemd.chemin (5).

10. Les unités Slice peuvent être utilisées pour regrouper les unités qui gèrent les processus système (tels que le service
et unités de portée) dans une arborescence hiérarchique à des fins de gestion des ressources. Voir
systemd.tranche (5).

11. Les unités de portée sont similaires aux unités de service, mais gèrent des processus étrangers au lieu de
les démarrer aussi. Voir systemd.scope (5).

Les unités sont nommées comme leurs fichiers de configuration. Certaines unités ont une sémantique spéciale. UNE
la liste détaillée est disponible dans systemd.spécial (7).

systemd connaît différents types de dépendances, y compris les exigences positives et négatives
dépendances (c'est-à-dire Nécessite= et Conflits=) ainsi que les dépendances d'ordre (Après= et
Avant=). NB : les dépendances d'ordre et d'exigences sont orthogonales. Si seulement une exigence
une dépendance existe entre deux unités (par exemple, foo.service nécessite bar.service), mais aucune
dépendance de commande (par exemple foo.service après bar.service) et les deux sont invités à démarrer,
ils seront lancés en parallèle. C'est un modèle commun que l'exigence et
les dépendances de commande sont placées entre deux unités. Notez également que la majorité des
les dépendances sont implicitement créées et maintenues par systemd. Dans la plupart des cas, il doit être
inutile de déclarer des dépendances supplémentaires manuellement, cependant il est possible de le faire
ce.

Les programmes d'application et les unités (via les dépendances) peuvent demander des changements d'état des unités. Dans
systemd, ces requêtes sont encapsulées en tant que « tâches » et conservées dans une file d'attente de tâches. Les emplois peuvent
réussir ou échouer, leur exécution est ordonnée en fonction des dépendances d'ordre du
unités pour lesquelles ils ont été programmés.

Au démarrage, systemd active l'unité cible default.target dont le travail consiste à activer au démarrage
services et autres unités au démarrage en les tirant via des dépendances. Habituellement, l'unité
name est juste un alias (lien symbolique) pour l'un ou l'autre graphical.target (pour des démarrages complets dans
l'interface utilisateur) ou multi-user.target (pour les démarrages limités de la console uniquement pour une utilisation dans
environnements ou similaires ; un sous-ensemble de graphical.target). Cependant, c'est à la discrétion
de l'administrateur pour le configurer comme alias vers n'importe quelle autre unité cible. Voir
systemd.spécial(7) pour plus de détails sur ces unités cibles.

Les processus générés par systemd sont placés dans des groupes de contrôle Linux individuels nommés d'après le
unité à laquelle ils appartiennent dans la hiérarchie systemd privée. (voir cgroups.txt[1] pour en savoir plus
informations sur les groupes de contrôle, ou abrégés "cgroups"). systemd utilise cela pour efficacement
suivre les processus. Les informations du groupe de contrôle sont conservées dans le noyau et sont
accessible via la hiérarchie du système de fichiers (sous /sys/fs/cgroup/systemd/), ou dans les outils
tel que systèmed-cgls(1) ou ps(1) (ps xawf -eo pid, utilisateur, groupe de contrôle, arguments est particulièrement utile
pour lister tous les processus et les unités systemd auxquelles ils appartiennent.).

systemd est compatible dans une large mesure avec le système d'initialisation SysV : les scripts d'initialisation SysV sont
pris en charge et lu simplement comme un format de fichier de configuration alternatif (bien que limité).
L'interface SysV /dev/initctl est fournie, et les implémentations de compatibilité du
divers outils client SysV sont disponibles. En plus de cela, divers Unix établis
des fonctionnalités telles que / etc / fstab ou la base de données utmp sont pris en charge.

systemd a un système de transaction minimal : si une unité est invitée à démarrer ou à s'arrêter
il l'ajoutera ainsi que toutes ses dépendances à une transaction temporaire. Ensuite, il vérifiera
si la transaction est cohérente (c'est-à-dire si la commande de toutes les unités est sans cycle).
Si ce n'est pas le cas, systemd essaiera de le réparer et supprimera les tâches non essentielles du
transaction qui pourrait supprimer la boucle. De plus, systemd essaie de supprimer les travaux non essentiels
dans la transaction qui arrêterait un service en cours d'exécution. Enfin, il est vérifié si le
les travaux de la transaction contredisent les travaux qui ont déjà été mis en file d'attente, et éventuellement le
la transaction est alors abandonnée. Si tout s'est bien passé et que la transaction est cohérente et
minimisé dans son impact, il est fusionné avec tous les travaux déjà en cours et ajouté à la
exécuter la file d'attente. En fait, cela signifie qu'avant d'exécuter une opération demandée, systemd
vérifiera que cela a du sens, en le corrigeant si possible, et n'échouant que si cela est vraiment
ne peut pas fonctionner.

Systemd contient des implémentations natives de diverses tâches qui doivent être exécutées dans le cadre
du processus de démarrage. Par exemple, il définit le nom d'hôte ou configure le réseau de bouclage
dispositif. Il configure et monte également divers systèmes de fichiers API, tels que / sys ou /proc.

Pour plus d'informations sur les concepts et les idées derrière systemd, veuillez vous référer à la
ORIGINALE Design Documents[2].

Notez que certaines mais pas toutes les interfaces fournies par systemd sont couvertes par le Interface
Stabilité Promesse[3].

Les unités peuvent être générées dynamiquement au démarrage et au moment du rechargement du gestionnaire système, par exemple
basé sur d'autres fichiers de configuration ou paramètres transmis sur la ligne de commande du noyau. Pour
détails, voir systemd.générateur (7).

Les systèmes qui invoquent systemd dans un environnement conteneur ou initrd doivent implémenter le
Contenant Interface[4] ou initrd Interface[5] spécifications, respectivement.

RÉPERTOIRES

Répertoires des unités système
Le gestionnaire de système systemd lit la configuration de l'unité à partir de divers répertoires. Paquets
qui veulent installer des fichiers unitaires doivent les placer dans le répertoire renvoyé par
pkg-config systemd --variable=systemdsystemunitrép. Les autres répertoires vérifiés sont
/usr/local/lib/systemd/system et /lib/systemd/system. La configuration utilisateur prend toujours
priorité. pkg-config systemd --variable=systemdsystemconfdir renvoie le chemin de
le répertoire de configuration du système. Les colis doivent modifier le contenu de ces
répertoires uniquement avec le permettre et désactiver commandes de la systemctl(1) outil. Complet
la liste des répertoires est fournie dans systemd.unité (5).

Répertoires des unités utilisateur
Des règles similaires s'appliquent aux répertoires des unités utilisateur. Cependant, ici le XDG Base
Annuaire spécification[6] est suivi pour trouver les unités. Les candidatures doivent placer leur
fichiers unitaires dans le répertoire renvoyé par pkg-config systemd
--variable=rép_unitédusystème. La configuration globale se fait dans le répertoire signalé
by pkg-config systemd --variable=rép_conf_systemduserL’ permettre et désactiver commandes
du système systemctl(1) l'outil peut gérer à la fois global (c'est-à-dire pour tous les utilisateurs) et privé (pour
un utilisateur) activation/désactivation des unités. La liste complète des répertoires est fournie dans
systemd.unité (5).

Répertoire des scripts d'initialisation SysV
L'emplacement du répertoire du script d'initialisation SysV varie selon les distributions. Si
systemd ne peut pas trouver un fichier d'unité natif pour un service demandé, il recherchera un
Script d'initialisation SysV du même nom (avec le suffixe .service supprimé).

Répertoire de la batterie de serveurs de liens de niveau d'exécution SysV
L'emplacement du répertoire de la batterie de serveurs de liens de niveau d'exécution SysV varie selon les distributions.
systemd prendra en compte la ferme de liens pour déterminer si un service doit
être activé. Notez qu'une unité de service avec un fichier de configuration d'unité natif ne peut pas être
commencé par l'activer dans la ferme de liens de niveau d'exécution SysV.

SIGNAUX

SIGTERME
À la réception de ce signal, le gestionnaire de système systemd sérialise son état, réexécute
lui-même et désérialise à nouveau l'état enregistré. Cela équivaut en grande partie à systemctl
démon-reexec.

Les gestionnaires d'utilisateurs systemd démarreront l'unité exit.target lorsque ce signal sera reçu.
Cela équivaut en grande partie à systemctl --utilisateur Commencer exit.cible.

SIGINT
À la réception de ce signal, le gestionnaire de système systemd lancera le
unité ctrl-alt-del.target. Cela équivaut en grande partie à systemctl Commencer
ctl-alt-del.cible. Si ce signal est reçu plus de 7 fois toutes les 2s, une
le redémarrage est déclenché. Notez qu'appuyer sur Ctrl-Alt-Del sur la console déclenchera ce
signal. Par conséquent, si un redémarrage est suspendu, appuyez sur Ctrl-Alt-Suppr plus de 7 fois en 2s
est un moyen relativement sûr de déclencher un redémarrage immédiat.

les gestionnaires d'utilisateurs de systemd traitent ce signal de la même manière que SIGTERME.

SIGNALISATION
Lorsque ce signal est reçu, le gestionnaire de système systemd lancera le
unité kbrequest.target. Cela équivaut en grande partie à systemctl Commencer kbrequest.cible.

Ce signal est ignoré par les gestionnaires d'utilisateurs de systemd.

SIGPWR
Lorsque ce signal est reçu, le gestionnaire systemd démarre l'unité sigpwr.target.
Cela équivaut en grande partie à systemctl Commencer sigpwr.cible.

SIGUSR1
Lorsque ce signal est reçu, le gestionnaire systemd essaiera de se reconnecter au D-Bus
autobus.

SIGUSR2
Lorsque ce signal est reçu, le gestionnaire systemd enregistre son état complet dans
forme lisible par l'homme. Les données enregistrées sont les mêmes que celles imprimées par systemd-analyse déverser.

VUE D'ENSEMBLE
Recharge la configuration complète du démon. Cela équivaut en grande partie à systemctl
démon-recharger.

SIGRTMIN+0
Entre en mode par défaut, démarre l'unité default.target. Cela équivaut en grande partie à
systemctl Commencer cible par défaut..

SIGRTMIN+1
Entre en mode sauvetage, démarre l'unité rescue.target. Cela équivaut en grande partie à
systemctl isoler cible.de.sauvetage.

SIGRTMIN+2
Entre en mode d'urgence, démarre l'unité de service d'urgence. Cela équivaut en grande partie à
systemctl isoler service d'urgence.

SIGRTMIN+3
Arrête la machine, démarre l'unité halt.target. Cela équivaut en grande partie à systemctl
Commencer stop.cible.

SIGRTMIN+4
Met la machine hors tension, démarre l'unité poweroff.target. Cela équivaut en grande partie à
systemctl Commencer poweroff.cible.

SIGRTMIN+5
Redémarre la machine, démarre l'unité reboot.target. Cela équivaut en grande partie à
systemctl Commencer redémarrage cible.

SIGRTMIN+6
Redémarre la machine via kexec, démarre l'unité kexec.target. C'est presque équivalent
à systemctl Commencer kexec.cible.

SIGRTMIN+13
Arrête immédiatement la machine.

SIGRTMIN+14
Mettez immédiatement la machine hors tension.

SIGRTMIN+15
Redémarre immédiatement la machine.

SIGRTMIN+16
Redémarre immédiatement la machine avec kexec.

SIGRTMIN+20
Permet l'affichage des messages d'état sur la console, comme contrôlé via
systemd.show_status=1 sur la ligne de commande du noyau.

SIGRTMIN+21
Désactive l'affichage des messages d'état sur la console, comme contrôlé via
systemd.show_status=0 sur la ligne de commande du noyau.

SIGRTMIN+22, SIGRTMIN+23
Définit le niveau de journalisation sur "debug" (ou "info" sur SIGRTMIN+23), comme contrôlé via
systemd.log_level=déboguer (ou systemd.log_level=info on SIGRTMIN+23) sur le noyau
ligne de commande.

SIGRTMIN+24
Quitte immédiatement le gestionnaire (uniquement disponible pour les instances --user).

SIGRTMIN+26, SIGRTMIN+27, SIGRTMIN+28
Définit le niveau de journalisation sur "journal-or-kmsg" (ou "console" sur SIGRTMIN+27, "kmsg" sur
SIGRTMIN+28), comme contrôlé via systemd.log_target=journal-ou-kmsg (ou
systemd.log_target=console on SIGRTMIN+27 or systemd.log_target=kmsg on SIGRTMIN+28)
sur la ligne de commande du noyau.

ENVIRONNEMENT

$SYSTEMD_LOG_LEVEL
systemd lit le niveau de journalisation à partir de cette variable d'environnement. Cela peut être outrepassé
avec --log-level=.

$SYSTEMD_LOG_TARGET
systemd lit la cible du journal à partir de cette variable d'environnement. Cela peut être outrepassé
avec --log-cible=.

$SYSTEMD_LOG_COLOR
Contrôle si systemd met en évidence les messages de journal importants. Cela peut être outrepassé
avec --log-color=.

$SYSTEMD_LOG_LOCATION
Contrôle si systemd imprime l'emplacement du code avec les messages de journal. Cela peut être
remplacé par --log-emplacement=.

$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
Le gestionnaire d'utilisateurs systemd utilise ces variables conformément aux XDG Base Annuaire
spécification[6] pour trouver sa configuration.

$SYSTEMD_UNIT_PATH
Contrôle où systemd recherche les fichiers d'unité.

$SYSTEMD_SYSVINIT_PATH
Contrôle où systemd recherche les scripts d'initialisation SysV.

$SYSTEMD_SYSVRCND_PATH
Contrôle où systemd recherche les fermes de liens de niveau d'exécution de script d'initialisation SysV.

$SYSTEMD_COLORS
Contrôle si la sortie colorisée doit être générée.

$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
Défini par systemd pour les processus supervisés lors de l'activation basée sur les sockets. Voir
sd_listen_fds(3) pour plus d'informations.

$NOTIFY_SOCKET
Défini par systemd pour les processus supervisés pour l'état et l'achèvement du démarrage
notification. Voir sd_notifier(3) pour plus d'informations.

NOYAU COMMAND LINE

Lorsqu'il est exécuté en tant qu'instance système, systemd analyse un certain nombre d'arguments de ligne de commande du noyau[7] :

systemd.unité=, rd.systemd.unit=
Remplace l'unité pour l'activer au démarrage. La valeur par défaut est default.target. Cela peut être utilisé
pour démarrer temporairement dans une autre unité de démarrage, par exemple rescue.target ou
service d'urgence. Voir systemd.spécial(7) pour plus de détails sur ces unités. L'option
préfixé par "rd." n'est honoré que dans le disque RAM initial (initrd), tandis que celui
qui n'est pas préfixé uniquement dans le système principal.

systemd.dump_core=
Prend un argument booléen. Si oui, le gestionnaire systemd (PID 1) vide le cœur lorsqu'il
se bloque. Sinon, aucun vidage de mémoire n'est créé. Par défaut à oui.

systemd.crash_chvt=
Prend un entier positif ou un argument booléen. Si un entier positif (dans la plage
1–63) est spécifié, le gestionnaire de système (PID 1) activera le
terminal (VT) lorsqu'il plante. Par défaut à aucune, ce qui signifie qu'aucun interrupteur de ce type n'est
tenté. Si réglé sur oui, le VT sur lequel les messages du noyau sont écrits est sélectionné.

systemd.crash_shell=
Prend un argument booléen. Si oui, le gestionnaire de système (PID 1) génère un shell lorsqu'il
se bloque, après un délai de 10 s. Sinon, aucun shell n'est généré. Par défaut à aucune, Pour
des raisons de sécurité, car le shell n'est pas protégé par une authentification par mot de passe.

systemd.crash_reboot=
Prend un argument booléen. Si oui, le gestionnaire système (PID 1) redémarrera la machine
automatiquement lorsqu'il plante, après un délai de 10 secondes. Sinon, le système se bloquera
indéfiniment. Par défaut à aucune, afin d'éviter une boucle de redémarrage. Si combiné avec
systemd.crash_shell=, le système est redémarré après la fermeture du shell.

systemd.confirm_spawn=
Prend un argument booléen. Si oui, le gestionnaire du système (PID 1) demande confirmation
lors des processus de frai. Par défaut à aucune.

systemd.show_status=
Prend un argument booléen ou la constante auto. Si oui, le gestionnaire systemd (PID 1)
affiche des mises à jour succinctes de l'état du service sur la console pendant le démarrage. auto se comporte comme
non jusqu'à ce qu'un service échoue ou qu'il y ait un retard important au démarrage. Par défaut à oui,
à moins que calme est passé en tant qu'option de ligne de commande du noyau, auquel cas il est par défaut
auto.

systemd.log_target=, systemd.log_level=, systemd.log_color=, systemd.log_location=
Contrôle la sortie du journal, avec le même effet que le $SYSTEMD_LOG_TARGET,
$SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LOCATION Variables d'environnement
décrit ci-dessus.

systemd.default_standard_output=, systemd.default_standard_error=
Contrôle la sortie standard par défaut et la sortie d'erreur pour les services, avec le même effet
car --default-standard-output= et --default-standard-erreur= arguments de ligne de commande
décrit ci-dessus, respectivement.

systemd.setenv=
Prend un argument de chaîne sous la forme VARIABLE=VALUE. Peut être utilisé pour définir par défaut
variables d'environnement à ajouter aux processus enfants forkés. 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
pour le démarrage réseau où le même identifiant de machine est souhaité pour chaque démarrage.

calme
Désactivez la sortie d'état au démarrage, un peu comme systemd.show_status=false aurait. Noter que
cette option est également lue par le noyau lui-même et désactive la sortie du journal du noyau. Qui passe
cette option désactive donc la sortie habituelle du gestionnaire de système et du
noyau.

déboguer
Activez la sortie de débogage. Ceci équivaut à systemd.log_level=déboguer. Noter que
cette option est également lue par le noyau lui-même et active la sortie de débogage du noyau. Qui passe
cette option active donc la sortie de débogage du gestionnaire système et du
noyau.

urgences dentaires., -b
Démarrez en mode d'urgence. Ceci équivaut à systemd.unit=urgence.target et
fourni pour des raisons de compatibilité et pour être plus facile à saisir.

sauver, unique, s, S, 1
Démarrez en mode de secours. Ceci équivaut à systemd.unit=rescue.target et fourni
pour des raisons de compatibilité et pour être plus facile à taper.

2, 3, 4, 5
Démarrez dans le niveau d'exécution SysV hérité spécifié. Ceux-ci sont équivalents à
systemd.unit = runlevel2.target, systemd.unit = runlevel3.target,
systemd.unit = runlevel4.targetet la bien-aimée Sonate en la majeur systemd.unit = runlevel5.target, respectivement, et
fourni pour des raisons de compatibilité et pour être plus facile à saisir.

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_MESURE=,
locale.LC_IDENTIFICATION=
Définissez les paramètres régionaux du système à utiliser. Cela remplace les paramètres dans /etc/locale.conf. Pour
plus d'informations, voir locale.confde Géographie (5) et avec la local (7).

Pour les autres paramètres de ligne de commande du noyau compris par les composants du système d'exploitation principal, veuillez
faire référence à ligne de commande du noyau (7).

DOUILLES ET FIFO

/run/systemd/notifier
Socket de notification d'état du démon. C'est un AF_UNIX socket datagramme et est utilisé pour
implémenter la logique de notification du démon telle qu'elle est implémentée par sd_notifier (3).

/exécuter/systemd/privé
Utilisé en interne comme canal de communication entre systemctl(1) et le processus systemd.
C'est un AF_UNIX socket de flux. Cette interface est privée à systemd et ne doit pas
être utilisé dans des projets externes.

/dev/initctl
Prise en charge de compatibilité limitée pour l'interface client SysV, telle qu'implémentée par le
unité systemd-initctl.service. Il s'agit d'un tube nommé dans le système de fichiers. Cette interface
est obsolète et ne doit pas être utilisé dans de nouvelles applications.

Utilisez systemd en ligne à l'aide des services onworks.net