Traduction japonaise du manuel affiché par `` man systemd ''.
systemd, init --systemd Manager qui gère les systèmes et les services.
/lib/systemd/systemd [OPTIONS...]
init [OPTIONS...] {COMMAND}
systemd est un gestionnaire qui gère les systèmes et services pour le système d'exploitation Linux. Lorsqu'il est exécuté en tant que premier processus au démarrage (en tant que PID 1), il agit comme un système d'initialisation qui démarre et gère les services de l'espace utilisateur.
Pour la compatibilité SysV, si systemd est appelé comme init et que le PID n'est pas 1, telinit est exécuté et tous les arguments de ligne de commande sont transmis inchangés. Autrement dit, init et telinit sont à peu près les mêmes lorsqu'ils sont appelés à partir d'une session de connexion normale. Voir telinit (8) pour plus d'informations.
Lorsque vous exécutez systemd en tant qu'instance système, systemd interprète les fichiers dans les répertoires des fichiers de configuration system.conf '' et system.conf.d ''.
Lorsqu'il est exécuté en tant qu'instance utilisateur, systemd interprète les fichiers dans les répertoires des fichiers de configuration user.conf et user.conf.d.
Voir systemd-system.conf (5) pour plus d'informations.
Les options suivantes sont comprises.
--test
Déterminez la séquence de démarrage, vidage et sortie. C'est une option qui n'est utile que pour le débogage.
--dump-configuration-items
Videz les éléments de configuration de l'unité compris. Cela produira une liste concise et complète des éléments de configuration reconnus dans le fichier de définition d'unité.
--dump-bus-properties
Videz les propriétés de bus exposées. Cela donnera une liste concise et complète des propriétés exposées à dbus.
--unit=
Définit l'unité par défaut à activer au démarrage. S'il n'est pas spécifié, la valeur par défaut est default.target.
--system, --user
--system indique à systemd d'exécuter l'instance système même si l'ID de processus n'est pas 1.
Autrement dit, systemd ne s'exécute pas en tant que processus init.
--user fait le contraire et exécute l'instance utilisateur même si l'ID de processus est 1.
Normalement, systemd détectera automatiquement le mode dans lequel il a été démarré, vous n'avez donc pas besoin de passer ces options.
Ces options sont rarement utilisées.
Pour le débogage.
Il ne prend pas en charge le démarrage et la gestion complets du système avec systemd fonctionnant en mode --system, mais le PID n'est pas 1.
En fait, passer explicitement --system n'est utile que lorsqu'il est combiné avec --test.
--dump-core
Activez le vidage de mémoire en cas de panne. Ce commutateur n'a aucun effet lors de l'exécution en tant qu'instance utilisateur. Ce paramètre peut également être activé sur la ligne de commande du noyau au démarrage via l'option systemd.dump_core. Veuillez vous référer à ce qui suit.
--crash-vt = VT
Basculez vers une console virtuelle (VT) spécifique en cas de panne.
Il prend un entier positif compris entre 1 et 63 ou un argument booléen.
Sélectionnez le VT vers lequel basculer si un entier est passé.
Si oui '', l'emplacement où le message du noyau VT est écrit est sélectionné. Si non '', aucun commutateur VT ne sera tenté.
Ce commutateur n'a aucun effet lors de l'exécution en tant qu'instance utilisateur.
Ce paramètre peut également être activé sur la ligne de commande du noyau au moment du démarrage via l'option systemd.crash_chvt.
Veuillez vous référer à ce qui suit.
--crash-shell
Exécute le shell en cas de panne. Ce commutateur n'a aucun effet lors de l'exécution en tant qu'instance utilisateur. Ce paramètre peut également être activé sur la ligne de commande du noyau au démarrage via l'option systemd.crash_shell. Veuillez vous référer à ce qui suit.
--crash-reboot
Redémarre automatiquement le système en cas de panne. Ce commutateur n'a aucun effet lors de l'exécution en tant qu'instance utilisateur. Ce paramètre peut également être activé sur la ligne de commande du noyau au démarrage via l'option systemd.crash_reboot. Veuillez vous référer à ce qui suit.
--confirm-spawn
Demandez une confirmation lors de la création d'un processus. Ce commutateur n'a aucun effet lors de l'exécution en tant qu'instance utilisateur.
--show-status=
Prend un argument booléen ou la valeur spéciale `ʻauto``.
: Le comportement est similaire à off, mais il s'allume automatiquement dès que la première unité tombe en panne ou a un retard de démarrage important. Ce commutateur n'a aucun effet lorsqu'il est appelé en tant qu'instance utilisateur. S'il est spécifié, il remplace à la fois le paramètre de ligne de commande du noyau [systemd.show_status](#systemdshow_status) et l'option du fichier de configuration ShowStatus de manière appropriée.
Voir systemd-system.conf (5).--log-target=
Définissez la cible du journal. L'argument doit être l'un des suivants:
--log-level=
Définissez le niveau de journalisation. En tant qu'argument, acceptez un niveau de journal numérique ou le nom symbolique bien connu de syslog (3) (inférieur).
--log-color=
Mettez en surbrillance les messages de journal importants. L'argument est une valeur booléenne. Si vous omettez l'argument, la valeur par défaut est `` true ''.
--log-location=
Incluez l'emplacement du code dans le message du journal. Ceci est principalement lié au débogage. L'argument est une valeur booléenne. Si vous omettez l'argument, la valeur par défaut est `` true ''.
--default-standard-output=, --default-standard-error=
Définissez la sortie par défaut ou d'erreur pour tous les services et sockets, respectivement.
Autrement dit, il contrôle les valeurs par défaut pour StandardOutput spécifiquement et StandardError de manière appropriée (voir systemd.exec (5) pour plus d'informations).
Prenez l'un des arguments suivants comme argument.
Si vous omettez l'argument, --default-standard-output par défaut de manière appropriée est journalet --default-standard-error séquentiellement par défaut à ```inherit``.
--machine-id=
Remplace l'identifiant de l'ordinateur défini sur le disque dur. Utile pour les démarrages réseau et les conteneurs. Il ne peut pas être réglé sur tous les zéros.
--service-watchdogs=
Globalement, active / désactive tous les délais d'expiration du chien de garde de service et les actions d'urgence. Ce paramètre peut également être spécifié au moment du démarrage sur la ligne de commande du noyau via l'option systemd.service_watchdogs (#systemdservice_watchdogs). Veuillez vous référer à ce qui suit. La valeur par défaut est «activer».
-h, --help
Affichez un court texte d'aide et quittez.
--version
Produit une chaîne de version courte et quitte.
systemd fournit un système de dépendance entre diverses entités appelé 11 types d '"unités". L'unité encapsule divers objets liés au démarrage et à la gestion du système. La plupart des unités sont constituées de fichiers de configuration d'unité, dont la syntaxe et le jeu d'options de base sont décrits dans systemd.unit (5), mais certains proviennent automatiquement de l'état du système ou d'autres configurations. Créé par programme au moment de l'exécution. Les unités sont «actives» (signifiant démarrées, liées, branchées, etc., selon le type d'unité; voir ci-dessous), ou «inactives» (signifiant arrêtées, non liées, débranchées, etc.), Et le processus d'activation ou de désactivation, c'est-à-dire entre deux états (ces états sont appelés «« activation »,« désactivation »). Un état spécial `` échec '' est également disponible. Ceci est très similaire à «inactif», qui se termine lorsque le service échoue de quelque manière que ce soit (le processus renvoie un code d'erreur ou se bloque, l'opération expire ou redémarre fréquemment à la sortie). Si trop). Lorsque cela se produit, la cause est enregistrée pour référence ultérieure. Notez que les différents types d'unité ont des sous-états supplémentaires, qui tombent dans les cinq états d'unité généralisés décrits ici.
Les types d'unité suivants sont disponibles:
Une unité de service qui démarre et contrôle le démon et les processus qui composent le démon. Voir systemd.service (5) pour plus d'informations.
Une unité de prise qui encapsule l'IPC local ou la prise réseau du système. Utile pour l'activation basée sur socket. Pour plus d'informations sur les unités de prise, consultez systemd.socket (5). Pour plus d'informations sur l'activation basée sur le socket et d'autres formes d'activation, consultez daemon (7).
Les unités cibles aident à regrouper les unités et fournissent des points de synchronisation connus au moment du démarrage. Voir systemd.target (5).
L'unité de périphérique expose les périphériques du noyau systemd et peut être utilisée pour implémenter l'activation basée sur le périphérique. Voir systemd.device (5) pour plus d'informations.
L'unité de montage contrôle le point de montage du système de fichiers. Voir systemd.mount (5) pour plus d'informations.
L'unité de montage automatique permet le montage à la demande du système de fichiers et le montage automatique pour le démarrage parallèle. Voir systemd.automount (5).
L'unité de minuterie aide à déclencher l'activation d'autres unités basées sur la minuterie. Les détails peuvent être trouvés dans systemd.timer (5).
L'unité d'échange est très similaire à l'unité de montage et encapsule la partition ou le fichier d'échange de mémoire du système d'exploitation. Ils sont décrits dans systemd.swap (5).
Les unités de chemin peuvent être utilisées pour activer d'autres services lorsqu'un objet du système de fichiers change ou change. Voir systemd.path (5).
Les unités de tranche peuvent être utilisées pour regrouper les unités qui gèrent les processus système (tels que les unités de service et les unités d'étendue) dans une arborescence hiérarchique pour la gestion des ressources. Voir systemd.slice (5).
Les unités de portée sont similaires aux unités de service, mais gèrent au lieu de démarrer des processus externes. Voir systemd.scope (5). L'unité est nommée en tant que fichier de configuration. Certaines unités ont une sémantique spéciale. Une liste détaillée peut être trouvée dans systemd.special (7).
systemd peut être une variété de dépendances d'exigences positives et négatives (c'est-à-dire Requis et '' Conflit séquentiellement) et de dépendances d'ordre ( Après en particulier et `` Avant simplement) Nous sommes conscients de divers types de dépendances.
Remarque: les dépendances d'ordre et d'exigence sont orthogonales. Il n'y a qu'une dépendance d'exigence entre les deux unités (par exemple, foo.service nécessite bar.service), aucune dépendance d'ordre (par exemple, foo.service suivi de bar.service) et les deux démarrent Si demandé, ils seront démarrés en parallèle. Il s'agit d'un modèle commun pour les exigences et les dépendances d'ordre à placer entre deux unités. Notez également que la plupart des dépendances sont créées et gérées implicitement par systemd. Dans la plupart des cas, vous n'avez pas besoin de déclarer manuellement des dépendances supplémentaires, mais vous pouvez le faire.
Les programmes d'application et les unités (via les dépendances) peuvent demander des changements d'état des unités. Dans systemd, ces demandes sont encapsulées en tant que `` travail '' et conservées dans la file d'attente des travaux. Le travail peut réussir ou échouer. L'exécution du travail est basée sur les dépendances d'unité planifiées.
Au démarrage, systemd lance l'unité cible default.target, qui est un travail lancé en appelant les services de démarrage et d'autres unités de démarrage via des dépendances. Le nom de l'unité est généralement graphical.target (pour un démarrage complet de l'interface utilisateur) ou multi-user.target (pour un démarrage limité de la console à utiliser dans un environnement embarqué ou serveur), ou similaire. Alias (lien symbolique); un sous-ensemble de graphic.target). Cependant, il appartient à l'administrateur de le configurer comme alias pour une autre unité cible. Pour plus d'informations sur ces unités cibles, voir systemd.special (7).
systemd ne contient que la plus petite unité lue en mémoire. Plus précisément, les seules unités qui restent chargées en mémoire sont celles qui remplissent au moins l'une des conditions suivantes:
État actif, activé, désactivé ou échoué (c'est-à-dire tous les états de l'unité sauf «inactif»)
Un travail est en attente.
C'est la dépendance d'au moins une autre unité qui est chargée en mémoire.
Une unité de service qui a encore une certaine forme de ressource allouée (par exemple, une unité de service qui est inactive mais qui a toujours des processus qui ont ignoré les demandes d'arrêt).
Épinglé par programmation à la mémoire par un appel D-Bus.
systemd charge automatiquement et implicitement l'unité à partir du disque dès qu'une opération est demandée sur l'unité si elle n'est pas déjà chargée. Par conséquent, à bien des égards, le client ne sait pas si l'unité est chargée. Utilisez `` systemctl list-units --all '' pour lister toutes les unités actuellement chargées. Les unités qui ne remplissent aucune des conditions ci-dessus seront déchargées immédiatement. Notez que lorsqu'une unité est déchargée de la mémoire, ses données comptables sont également vidées. Cependant, ces données ne sont généralement pas perdues car chaque fois que l'unité s'arrête, un enregistrement de journal de journal est généré qui déclare les ressources consommées.
Les processus engendrés par systemd sont placés dans des groupes de contrôle Linux individuels nommés d'après les unités auxquelles ils appartiennent dans une hiérarchie systemd privée.
(Voir cgroups.txt ou cgroups pour plus d'informations sur les groupes de contrôle).
systemd l'utilise pour suivre efficacement le processus.
Les informations du groupe de contrôle sont conservées dans le noyau et sont stockées dans la hiérarchie du système de fichiers (sous `` / sys / fs / cgroup / systemd / ''), ou systemd-cgls (1) ou ps (1).
(ps xawf -eo pid, user, cgroup, args sont particulièrement utiles pour lister tous les processus et les unités systemd auxquelles ils appartiennent.)
systemd est hautement compatible avec les systèmes d'initialisation SysV.
Les scripts SysVinit sont pris en charge et lus comme un format de fichier de configuration alternatif (bien que limité).
Une interface SysV / dev / initctl '' est fournie et des implémentations compatibles de divers outils clients SysV sont disponibles. De plus, diverses fonctionnalités Unix sont prises en charge, telles que / etc / fstab '' et la base de données utmp.
systemd a un système de transaction minimal. Lorsqu'une unité doit démarrer ou s'arrêter, l'unité et toutes ses dépendances sont ajoutées à la transaction temporaire. Vérifiez ensuite si la transaction est cohérente (c'est-à-dire s'il y a un cycle dans l'ordre de toutes les unités). S'il y a un cycle dans l'ordre des unités, systemd essaiera de le réparer et de supprimer les travaux non essentiels de la transaction qui peuvent être en mesure de supprimer la boucle. Systemd tente également de supprimer les travaux insignifiants dans les transactions qui arrêtent l'exécution des services. Enfin, il vérifie si le travail dans la transaction n'est pas cohérent avec un travail qui a déjà été mis en file d'attente et abandonne éventuellement la transaction. Si tout fonctionne et que la transaction est cohérente et a un impact minimal, elle sera fusionnée avec tous les travaux en cours et ajoutée à la file d'attente d'exécution. Cela signifie effectivement que systemd vérifiera qu'il est valide, le modifiera si possible et échouera uniquement s'il ne fonctionne pas réellement, avant d'effectuer l'opération demandée.
Notez que la transaction est générée indépendamment de l'état de l'unité au moment de l'exécution. Ainsi, par exemple, si un travail de démarrage est demandé sur une unité qui a déjà été démarrée, une transaction sera générée et une dépendance inactive sera invoquée (la propagation d'autres travaux se produira également pour chaque relation définie). .. Cela est dû au fait que le travail en file d'attente est en cours d'exécution par rapport à l'état de l'unité cible et est marqué comme réussi et terminé lorsque les deux sont satisfaits. Cependant, ce travail capture également d'autres dépendances en raison des relations définies, donc dans cet exemple, tout travail de l'unité inactive sera également mis en file d'attente.
systemd contient des implémentations natives de diverses tâches qui doivent être effectuées dans le cadre du processus de démarrage.
Par exemple, définissez un nom d'hôte ou configurez un périphérique réseau en boucle.
Il configure et monte également divers systèmes de fichiers API tels que / sys et / proc.
Pour plus d'informations sur les concepts et les idées derrière systemd, consultez le document de conception original (http://0pointer.de/blog/projects/systemd.html).
Veuillez noter que certaines interfaces fournies par systemd sont couvertes par la promesse de stabilité d'interface (https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise).
Les unités peuvent être générées dynamiquement au moment du démarrage et au rechargement du gestionnaire système. Par exemple, il est basé sur d'autres fichiers de configuration ou paramètres passés sur la ligne de commande du noyau. Voir systemd.generator (7) pour plus d'informations.
Le système qui appelle systemd dans un environnement conteneur ou initrd est l'interface conteneur (https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface) ou l'interface initrd (https://www.freedesktop.org), respectivement. Vous devez implémenter la spécification (/ wiki / Software / systemd / InitrdInterface).
systemd System Manager lit la configuration de l'unité à partir de divers répertoires.
Les paquets qui installent les fichiers unitaires les placent 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 / lib / systemd / system ''. Les paramètres utilisateur ont toujours la priorité. pkg-config systemd --variable = systemdsystemconfdir retourne le chemin vers le répertoire de configuration du système. Le paquet n'a besoin de changer le contenu de ces répertoires qu'avec les commandes ```enable et disable de l'outil systemctl (1).
Une liste complète des répertoires peut être trouvée dans systemd.unit (5).
Des règles similaires s'appliquent aux répertoires des unités utilisateur. Cependant, ici, nous recherchons des unités selon la spécification du répertoire de base XDG.
L'application doit placer les fichiers d'unité dans le répertoire renvoyé par pkg-config systemd --variable = systemduserunitdir ''. Les paramètres globaux sont définis dans le répertoire indiqué par pkg-config systemd --variable = systemduserconfdir ''.
Les commandes ```enableet disable`` de l'outil systemctl (1) peuvent gérer à la fois l'activation / la désactivation globale (c'est-à-dire tous les utilisateurs) et privée (un utilisateur) de l'unité. Je vais.
Une liste complète des répertoires peut être trouvée dans systemd.unit (5).
L'emplacement du répertoire du script d'initialisation SysV dépend de la distribution. Si le fichier d'unité natif du service demandé n'est pas trouvé, systemd recherche un script d'initialisation SysV avec le même nom mais avec le suffixe `` .service '' supprimé.
L'emplacement du répertoire de la batterie de serveurs de liens au niveau de l'exécution SysV dépend de la distribution. systemd prend en compte la batterie de serveurs liée au moment de décider d'activer le service. Les unités de service avec des fichiers de configuration d'unité natifs ne peuvent pas être activées et démarrées sur une batterie de serveurs liée au niveau de l'exécution SysV.
SIGTERM
À la réception de ce signal, systemd System Manager sérialise l'état, se réexécute et désérialise à nouveau l'état enregistré. C'est principalement équivalent à `` systemctl daemon-reexec ''.
Lorsque le gestionnaire d'utilisateurs systemd reçoit ce signal, il démarre l'unité exit.target. Ceci est presque équivalent à `` systemctl --user start exit.target --job-mode = replace-irréversible ''.
SIGINT
À la réception de ce signal, le gestionnaire système systemd lance l'unité ctrl-alt-del.target. C'est à peu près équivalent à `` systemctl start ctrl-alt-del.target --job-mode = replace-irrreversible ''. Si ce signal est reçu plus de 7 fois en 2 secondes, un redémarrage immédiat sera déclenché. Notez que le fait d'appuyer sur Ctrl + Alt + Suppr sur la console déclenche ce signal. Par conséquent, si le redémarrage est suspendu, appuyer sur Ctrl + Alt + Suppr plus de 7 fois en 2 secondes est un moyen relativement sûr de redémarrer immédiatement.
Le gestionnaire d'utilisateurs systemd gère ce signal de la même manière que SIGTERM.
SIGWINCH
À la réception de ce signal, le gestionnaire système systemd démarre l'unité kbrequest.target. C'est presque équivalent à `` systemctl start kbrequest.target ''.
Ce signal est ignoré par le gestionnaire d'utilisateurs de systemd.
SIGPWR
À la réception de ce signal, le gestionnaire systemd lance l'unité sigpwr.target. C'est presque équivalent à `` systemctl start sigpwr.target ''.
SIGUSR1
À la réception de ce signal, le gestionnaire systemd tentera de se reconnecter au bus D-Bus.
SIGUSR2
Lors de la réception de ce signal, le gestionnaire systemd enregistre son état complet dans un format lisible par l'homme. Les données enregistrées sont les mêmes que celles produites par `` systemd-analyser dump ''.
SIGHUP
Rechargez la configuration complète du démon. C'est à peu près équivalent à `` systemctl daemon-reload ''.
SIGRTMIN+0
Entrez dans le mode par défaut et démarrez l'unité default.target. C'est presque équivalent à `` systemctl isolate default.target ''.
SIGRTMIN+1
Entrez en mode de sauvetage et démarrez l'unité rescue.target. Cela équivaut à peu près à `` systemctl isolate rescue.target ''.
SIGRTMIN+2
Passez en mode d'urgence et démarrez l'unité de service d'urgence. Cela équivaut le plus souvent à `` systemctl isolate immédiat.service ''.
SIGRTMIN+3
Arrêtez la machine et démarrez l'unité halt.target. C'est presque équivalent à `` systemctl start halt.target --job-mode = replace-irréversible ''.
SIGRTMIN+4
Mettez la machine hors tension et démarrez l'unité poweroff.target. C'est presque équivalent à `` systemctl start poweroff.target --job-mode = replace-irréversible ''.
SIGRTMIN+5
Redémarrez la machine et démarrez l'unité reboot.target. C'est presque équivalent à `` systemctl start reboot.target --job-mode = replace-irrreversible ''.
SIGRTMIN+6
Redémarrez la machine via kexec et démarrez l'unité kexec.target. C'est presque équivalent à `` systemctl start kexec.target --job-mode = replace-irréversible ''.
SIGRTMIN+13
Arrêtez immédiatement la machine.
SIGRTMIN+14
Éteignez immédiatement la machine.
SIGRTMIN+15
Redémarrez immédiatement la machine.
SIGRTMIN+16
Redémarrez immédiatement la machine avec kexec.
SIGRTMIN+20
Active l'affichage des messages d'état sur la console afin qu'elle soit contrôlée par `` systemd.show_status = 1 '' sur la ligne de commande du noyau.
SIGRTMIN+21
Désactive l'affichage des messages d'état sur la console afin qu'il soit contrôlé par `` systemd.show_status = 0 '' sur la ligne de commande du noyau.
SIGRTMIN+22
Définissez le niveau de journalisation du gestionnaire de services sur "debug" de la même manière que systemd.log_level = debug sur la ligne de commande du noyau.
SIGRTMIN+23
Restaure le niveau de journalisation à la valeur définie.
Les valeurs configurées sont, selon la priorité, la valeur spécifiée par systemd.log-level notamment dans la ligne de commande du noyau, ou la valeur spécifiée par LogLevel notamment dans le fichier de configuration, ou le built-in ''. Dérivé de la valeur par défaut «info».
SIGRTMIN+24
Quittez immédiatement le gestionnaire (disponible uniquement pour les instances --user).
SIGRTMIN+26
Restaure la cible du journal à la valeur définie. Les valeurs configurées sont, selon la priorité, la valeur spécifiée par [systemd.log-target](# -log-target) sur la ligne de commande du noyau, ou la valeur spécifiée par `` LogTarget spécifiquement dans le fichier de configuration. , Ou à partir de la valeur par défaut intégrée.
SIGRTMIN+27, SIGRTMIN+28
Définissez la cible du journal sur SIGRTMIN + 27 console '' (ou SIGRTMIN) de la même manière que systemd.log_target = console '' (ou SIGRTMIN + 28 systemd.log_target = kmsg '') sur la ligne de commande du noyau. Régler sur +28 kmsg '').
$SYSTEMD_LOG_LEVEL
systemd lit le niveau de journalisation à partir de cette variable d'environnement. Cela peut être remplacé par [--log-level](# --log-level).
$SYSTEMD_LOG_TARGET
systemd lit la cible du journal à partir de cette variable d'environnement. Cela peut être remplacé par [--log-target](# --log-target).
$SYSTEMD_LOG_COLOR
Contrôle si systemd met en évidence les messages de journal importants. Cela peut être remplacé par [--log-color](# --log-color).
$SYSTEMD_LOG_LOCATION
Contrôle si systemd imprime la position du code avec le message du journal. Cela peut être remplacé par [--log-location](# --log-location).
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
Le gestionnaire d'utilisateurs de systemd utilise ces variables pour trouver sa configuration conformément à la spécification du répertoire de base XDG (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
$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 au niveau de l'exécution du script d'initialisation SysV.
$SYSTEMD_COLORS
La valeur doit être une valeur booléenne. Détermine s'il faut produire une sortie colorisée. Vous pouvez le spécifier pour remplacer la décision prise par systemd en fonction de `` $ TERM '' et de la destination de la console.
$SYSTEMD_URLIFY
La valeur doit être une valeur booléenne. Contrôle si les liens cliquables sont générés dans la sortie des émulateurs de terminal qui le prennent en charge. Vous pouvez le spécifier pour remplacer les décisions prises par systemd en fonction de `` $ TERM '' et d'autres conditions.
$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
Configuré par systemd pour les processus surveillés lors de l'activation basée sur socket. Voir sd_listen_fds (3) pour plus d'informations.
$NOTIFY_SOCKET
Défini par systemd pour les processus surveillés pour les notifications d'état et d'achèvement de démarrage. Voir sd_notify (3) pour plus d'informations.
Voir Variables d'environnement connues pour plus d'informations sur systemd et d'autres variables d'environnement comprises par ses divers composants.
Lorsqu'il est exécuté en tant qu'instance système, systemd analyse certains arguments de ligne de commande du noyau.
systemd.unit=, rd.systemd.unit=
Ecrase l'unité et l'active au moment du démarrage.
La valeur par défaut est default.target.
Cela peut être utilisé pour démarrer temporairement avec une autre unité de démarrage, telle que rescue.target ou Emergency.service.
Pour plus d'informations sur ces unités, voir systemd.special (7).
Les options commençant par rd. ne sont valides que sur le disque RAM initial (initrd), par opposition aux disques RAM non préfixés uniquement sur le système principal.
systemd.dump_core
Prend un argument booléen ou active l'option si elle est spécifiée sans argument. Lorsqu'il est activé, le gestionnaire systemd (PID 1) videra les cœurs en cas de panne. Sinon, aucun vidage de mémoire ne sera créé. La valeur par défaut est valide.
systemd.crash_chvt
Prend un entier positif ou un argument booléen. Il peut être spécifié sans argument et a le même effet qu'une valeur booléenne positive. Si un entier positif (compris entre 1 et 63) est spécifié, System Manager (PID 1) active le terminal virtuel (VT) spécifié en cas de panne. La valeur par défaut n'est pas valide. Autrement dit, aucun changement de ce type n'est effectué. Lorsqu'elle est activée, le VT sur lequel les messages du noyau sont écrits est sélectionné.
systemd.crash_shell
Prend un argument booléen ou active l'option si elle est spécifiée sans argument. Lorsqu'il est activé, System Manager (PID 1) génère un shell après un délai de 10 secondes lorsqu'il se bloque. Sinon, aucun shell ne sera généré. Le shell n'est pas protégé par l'authentification par mot de passe et est désactivé par défaut pour des raisons de sécurité.
systemd.crash_reboot
Prend un argument booléen ou active l'option si elle est spécifiée sans argument. Lorsqu'il est activé, System Manager (PID 1) redémarrera automatiquement la machine après 10 secondes en cas de panne. Sinon, le système se bloquera indéfiniment. Il est désactivé par défaut pour éviter une boucle de redémarrage. Combiné avec systemd.crash_shell, le système sera redémarré après la fermeture du shell.
systemd.confirm_spawn
Obtient l'argument booléen ou le chemin d'accès à la console virtuelle à laquelle le message de confirmation sera envoyé.
Il peut être spécifié sans argument et a le même effet qu'une valeur booléenne positive.
S'il est activé, System Manager (PID 1) utilise / dev / console '' pour demander une confirmation au démarrage du processus. Si un chemin ou un nom de console (tel que ttyS0 '') est spécifié, la console virtuelle spécifiée dans ce chemin ou décrite par le nom spécifié sera utilisée à la place.
Il est désactivé par défaut.
systemd.service_watchdogs=
Prend un argument booléen.
Lorsqu'il est désactivé, tous les chiens de garde d'exécution du service (WatchdogSec séquentiellement) et les actions d'urgence (telles que` ʻOnFailure de manière appropriée et StartLimitAction de manière appropriée) sont ignorés par System Manager (PID 1).
Voir systemd.service (5).
Il est activé par défaut.
Autrement dit, les chiens de garde et les actions sur les pannes sont gérés avec succès.
Les chiens de garde matériels ne sont pas concernés par cette option.
systemd.show_status
Prend un argument booléen ou la constante ʻauto``. Il peut être spécifié sans argument et a le même effet qu'une valeur booléenne positive. S'il est activé, le gestionnaire systemd (PID 1) affichera une brève mise à jour de l'état du service sur la console au démarrage. ```Auto`` se comporte comme `` false`` jusqu'à ce que l'unité tombe en panne ou qu'il y ait un retard important dans le démarrage. Il est activé par défaut à moins que `` quiet`` ne soit passé comme option de ligne de commande du noyau. Dans ce cas, la valeur par défaut est ʻauto. Si spécifié, l'option du fichier de configuration du gestionnaire système ShowStatus sera prioritaire.
Voir systemd-system.conf (5).
Cependant, l'option de ligne de commande de processus [--show-status](# --show-status) est prioritaire sur cette option de ligne de commande du noyau et sur l'option de fichier de configuration.
systemd.log_target=, systemd.log_level=, systemd.log_location=, systemd.log_color
Contrôle la sortie du journal avec le même effet que ci-dessus $ SYSTEMD_LOG_TARGET, $ SYSTEMD_LOG_LEVEL, $ SYSTEMD_LOG_LOCATION, [$ SYSTEMD_LOG_COLOR_COLOR] environnement .. systemd.log_color peut être spécifié sans argument et a le même effet qu'une valeur booléenne positive.
systemd.default_standard_output=, systemd.default_standard_error=
Même effet que les arguments de ligne de commande [--default-standard-output, --default-standard-error](# --default-standard-output --- default-standard-error), mais le service par défaut Contrôle la sortie standard et la sortie d'erreur.
systemd.setenv=
Prend un argument de chaîne de la forme `` VARIABLE = VALUE ''. Il peut être utilisé pour définir des variables d'environnement par défaut à ajouter aux processus enfants fourchus. Peut être utilisé plusieurs fois pour définir plusieurs variables.
systemd.machine_id=
Prend une valeur hexadécimale de 32 caractères utilisée pour définir l'ID machine. La cible principale est les démarrages réseau, qui nécessitent le même identifiant d'ordinateur pour tous les démarrages.
systemd.unified_cgroup_hierarchy
Sans argument ou avec l'argument true '', vous pouvez utiliser la hiérarchie de groupe de contrôle intégré (https://www.kernel.org/doc/Documentation/cgroup-v2.txt). (Aussi connu sous le nom de cgroups-v2). Si vous spécifiez l'argument false '', il rappellera la hiérarchie hybride ou complète du groupe de contrôle Legacy (https://www.kernel.org/doc/Documentation/cgroup-v1/).
Si cette option n'est pas spécifiée, le comportement par défaut est déterminé à la compilation (option -Ddefault-hierarchy = meson).
Si le noyau ne prend pas en charge la hiérarchie intégrée des groupes de contrôle, la hiérarchie héritée sera utilisée même si cette option est spécifiée.
systemd.legacy_systemd_cgroup_controller
Activé lorsque la hiérarchie de groupes de contrôle entièrement intégrée n'est pas utilisée (voir l'option précédente).
Sans argument ou avec l'argument true '', la hiérarchie du groupe de contrôle hybride '' (l'arborescence cgroups-v2 utilisée pour systemd, et pour les autres contrôleurs la hiérarchie de groupe de contrôle Legacy) (https: // www) Désactivez l'utilisation de .kernel.org / doc / Documentation / cgroup-v1 /), également appelé cgroups-v1).
Force le mode hérité '' complet. L'argument faux '' permet l'utilisation de la hiérarchie hybride ''. Si cette option n'est pas spécifiée, le comportement par défaut est déterminé à la compilation (option -Ddefault-hierarchy = meson``).
Si le noyau ne prend pas en charge la hiérarchie intégrée des groupes de contrôle, la hiérarchie héritée sera utilisée même si cette option est spécifiée.
quiet
Désactive la sortie d'état au démarrage, similaire à systemd.show_status = no.
Notez que cette option est également chargée dans le noyau lui-même, désactivant la sortie du journal du noyau.
Par conséquent, passer cette option désactive la sortie normale à la fois du gestionnaire système et du noyau.
debug
Activez la sortie de débogage. C'est équivalent à `` systemd.log_level = debug ''. Notez que cette option est également chargée dans le noyau lui-même, permettant la sortie de débogage pour le noyau. Par conséquent, passer cette option active la sortie de débogage à la fois du gestionnaire système et du noyau.
emergency, rd.emergency, -b
Démarrez en mode d'urgence.
Ceci équivaut à systemd.unit = Emergency.target '' ou rd.systemd.unit = Emergency.target '', respectivement, et est fourni pour des raisons de compatibilité et de simplification des entrées.
rescue, rd.rescue, single, s, S, 1
Démarrez en mode de secours.
Ceci est équivalent à systemd.unit = rescue.target '' ou rd.systemd.unit = rescue.target '', respectivement, et est fourni pour des raisons de compatibilité et de simplification des entrées. ..
2, 3, 4, 5
Démarre au niveau d'exécution SysV hérité spécifié.
Ce sont respectivement systemd.unit = runlevel2.target, systemd.unit = runlevel3.target '', systemd.unit = runlevel4.target '' et `` systemd.unit = runlevel5.target ''. Équivaut à ʻet fourni pour des raisons de compatibilité et de simplification des entrées.
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éfinit les paramètres régionaux du système à utiliser. Cela remplacera les paramètres dans `` / etc / locale.conf ''. Voir locale.conf (5) et locale (7) pour plus d'informations. Voir kernel-command-line (7) pour d'autres paramètres de ligne de commande du noyau que les composants de base du système d'exploitation peuvent comprendre.
/run/systemd/notify
Prise de notification de l'état du démon. Il s'agit d'un socket de datagramme AF_UNIX et est utilisé pour implémenter la logique de notification du démon implémentée par sd_notify (3).
/run/systemd/private
Utilisé en interne comme canal de communication entre systemctl (1) et le processus systemd. Il s'agit d'un socket de flux AF_UNIX. Cette interface est pour systemd uniquement et ne doit pas être utilisée dans des projets externes.
/dev/initctl
Prise en charge de la compatibilité limitée pour l'interface client SysV implémentée dans l'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ée dans de nouvelles applications.
SEE ALSO
NOTES
Lors de l'exécution dans un conteneur Linux, ces arguments peuvent être passés comme arguments de ligne de commande à systemd lui-même à côté des options de ligne de commande répertoriées dans la section Options ci-dessus.
Lors de l'exécution en dehors du conteneur Linux, ces arguments sont analysés à partir de / proc / cmdline à la place.
Recommended Posts