systemd, init - gestionnaire de système et de services systemd
SYNTAXE
/usr/lib/systemd/systemd [OPTIONS...]
init [OPTIONS...]
DESCRIPTION
systemd est un gestionnaire de système et de services pour les systèmes d'exploitation Linux. Lorsqu'il est exécuté comme premier processus au démarrage (en tant que PID 1), il agit comme un système d'initialisation qui lance et maintient les services de l'espace utilisateur. Des instances distinctes sont démarrées pour les utilisateurs connectés afin de démarrer leurs services.
systemd n'est généralement pas invoqué directement par l'utilisateur, mais il est installé comme le lien symbolique /sbin/init et démarré pendant le démarrage initial. Les instances de gestionnaire d'utilisateur sont démarrées automatiquement via le service [email protected](5).
Lorsque exécuté en tant qu'instance système, systemd interprète le fichier de configuration system.conf et les fichiers des 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 des répertoires user.conf.d. Voir systemd-system.conf(5) pour plus d'informations.
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 périphérique réseau de bouclage.
Il configure et monte également divers systèmes de fichiers d'API, tels que /sys/, /proc/ et /dev/.
systemd réinitialisera également l'horloge système pendant le démarrage initial si cela semble incorrect. Voir la section "Époque de l'horloge système" ci-dessous.
Notez que certaines, mais pas toutes, des interfaces fournies par systemd sont couvertes par la promesse de portabilité et de stabilité de l'interface[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 environnement de conteneur ou initrd doivent implémenter les spécifications de l'interface de conteneur[2] ou de l'interface initrd[3], respectivement.
UNITÉS
systemd fournit un système de dépendances entre diverses entités appelées "unités" de 11 types différents. Les unités encapsulent divers objets qui sont pertinents pour le démarrage et la maintenance du système. 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 certaines sont créées automatiquement à partir d'autres fichiers de configuration, dynamiquement à partir de l'état du système ou de manière programmatique au moment de l'exécution. Les unités peuvent être dans un certain nombre d'états, décrits dans le tableau suivant. Notez que les différents types d'unités peuvent avoir un certain nombre d'états secondaires supplémentaires, qui sont mappés aux états d'unité généralisés décrits ici.
Tableau 1. États ACTIF de l'unité
┌──────────────┬─────────────────────────────────────┐
│ État │ Description │
├──────────────┼─────────────────────────────────────┤
│ actif │ Démarré, lié, connecté, ..., │
│ │ selon le type d'unité. │
├──────────────┼─────────────────────────────────────┤
│ inactif │ Arrêté, non lié, déconnecté, ..., │
│ │ selon le type d'unité. │
├──────────────┼─────────────────────────────────────┤
│ échec │ Similaire à inactif, mais l'unité │
│ │ a échoué d'une manière ou d'une autre (le processus │
│ │ a renvoyé un code d'erreur à la sortie, │
│ │ s'est bloqué, une opération a expiré ou │
│ │ après trop de redémarrages). │
├──────────────┼─────────────────────────────────────┤
│ activation │ Passage de l'état inactif à l'état actif. │
├──────────────┼─────────────────────────────────────┤
│ désactivation │ Passage de l'état actif à l'état inactif. │
├──────────────┼─────────────────────────────────────┤
│ maintenance │ L'unité est inactive et une opération de maintenance │
│ │ est en cours. │
├──────────────┼─────────────────────────────────────┤
│ rechargement │ L'unité est active et elle recharge │
│ │ sa configuration. │
├──────────────┼─────────────────────────────────────┤
│ actualisation │ L'unité est active et un nouveau montage est │
│ │ activé dans son espace de noms. │
└──────────────┴─────────────────────────────────────┘
Les unités de service servent à démarrer et à contrôler des démons et les processus qui les composent. Pour plus de détails, voir systemd.service(5).
Les unités de socket encapsulent les sockets IPC locaux ou réseau du système, ce qui est utile pour l’activation basée sur les sockets. Pour plus de détails sur les unités de socket, voir systemd.socket(5), et pour plus de détails sur l’activation basée sur les sockets et d’autres formes d’activation, voir daemon(7).
Les unités cibles sont utiles pour regrouper des unités ou pour fournir des points de synchronisation bien connus pendant le démarrage, voir systemd.target(5).
Les unités de périphériques exposent les périphériques du noyau dans systemd et peuvent être utilisées pour implémenter l’activation basée sur les périphériques. Pour plus de détails, voir systemd.device(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).
Les unités d’automontage fournissent des capacités d’automontage, pour le montage à la demande des systèmes de fichiers ainsi que pour un démarrage parallélisé. Voir systemd.automount(5).
Les unités de temporisation sont utiles pour déclencher l’activation d’autres unités en fonction de temporisateurs. Vous trouverez plus de détails dans systemd.timer(5).
Les unités d’échange sont très similaires aux unités de montage et encapsulent les partitions ou les fichiers d’échange de mémoire du système d’exploitation. Elles sont décrites dans systemd.swap(5).
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.path(5).
Les unités de section peuvent être utilisées pour regrouper des unités qui gèrent les processus système (tels que les unités de service et d’étendue) dans une arborescence hiérarchique à des fins de gestion des ressources. Voir systemd.slice(5).
Les unités d’étendue sont similaires aux unités de service, mais gèrent des processus externes au lieu de les démarrer. Voir systemd.scope(5).
Les unités sont nommées d’après leurs fichiers de configuration. Certaines unités ont une sémantique spéciale. Une liste détaillée est disponible dans systemd.special(7).
systemd prend en charge divers types de dépendances, notamment les dépendances de type « requis » et « conflit » (c’est-à-dire Requires= et Conflicts=) ainsi que les dépendances d’ordre (After= et Before=). Remarque : les dépendances d’ordre et de type « requis » sont orthogonales. Si seule une dépendance de type « requis » existe entre deux unités (par exemple, foo.service requiert bar.service), mais pas de dépendance d’ordre (par exemple, foo.service après bar.service) et que les deux sont demandées pour être démarrées, elles seront démarrées en parallèle. Il est courant que les deux types de dépendances, à la fois de type « requis » et d’ordre, soient placés entre deux unités. Notez également que la plupart des dépendances sont créées et maintenues implicitement par systemd. Dans la plupart des cas, il ne devrait pas être nécessaire de déclarer des dépendances supplémentaires manuellement, mais il est possible de 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 sous forme de « tâches » et maintenues dans une file d’attente de tâches. Les tâches peuvent réussir ou échouer, leur exécution est ordonnée en fonction des dépendances d’ordre des unités pour lesquelles elles ont été planifiées.
Au démarrage, systemd active l’unité cible default.target, dont le rôle est d’activer les services de démarrage et les autres unités de démarrage en les incluant via des dépendances. Généralement, le nom de l’unité n’est qu’un alias (lien symbolique) pour graphical.target (pour les démarrages entièrement fonctionnels vers l’interface utilisateur) ou multi-user.target (pour les démarrages en mode console uniquement, pour une utilisation dans les environnements intégrés ou serveurs, ou similaire ; un sous-ensemble de graphical.target). Toutefois, il appartient à l’administrateur de le configurer en tant qu’alias vers toute autre unité cible. Voir systemd.special(7) pour plus de détails sur ces unités cibles.
Au premier démarrage, systemd active ou désactive les unités en fonction d’une politique prédéfinie. Voir systemd.preset(5) et « Sémantique du premier démarrage » dans machine-id(5).
systemd conserve uniquement un ensemble minimal d’unités chargées en mémoire. Plus précisément, seules les unités pour lesquelles au moins une des conditions suivantes est vraie sont conservées en mémoire :
Elle est dans un état actif, en cours d’activation, en cours de désactivation ou en échec (c’est-à-dire dans n’importe quel état d’unité autre que « inactif »).
Elle a une tâche en attente.
Elle est une dépendance d’au moins une autre unité qui est chargée en mémoire.
Elle a encore une forme de ressource allouée (par exemple, une unité de service inactive mais pour laquelle un processus qui a ignoré la demande de terminaison est toujours en cours).
Elle a été épinglée en mémoire par un appel D-Bus.
systemd charge automatiquement et implicitement les unités à partir du disque (si elles ne sont pas déjà chargées) dès qu’une opération est demandée pour elles. Ainsi, dans de nombreux cas, le fait qu’une unité soit chargée ou non est invisible pour les clients. Utilisez `systemctl list-units --all` pour lister de manière exhaustive toutes les unités actuellement chargées. Toute unité pour laquelle aucune des conditions ci-dessus ne s’applique est rapidement déchargée. Notez que lorsque une unité est déchargée de la mémoire, ses données comptables sont également supprimées. Cependant, ces données ne sont généralement pas perdues, car un enregistrement de journal est généré déclarant les ressources consommées chaque fois qu’une unité s’arrête.
Les processus que systemd lance 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 systemd. (voir Control Groups v2[4] pour plus d’informations sur les groupes de contrôle, ou en abrégé « cgroups »). systemd utilise cela pour suivre efficacement les processus. Les informations sur les groupes de contrôle sont conservées dans le noyau et sont accessibles via la hiérarchie du système de fichiers (en dessous de /sys/fs/cgroup/), ou dans des outils tels que systemd-cgls(1) ou [ps]({filename}../../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 diverses fonctionnalités Unix établies telles que /etc/fstab ou la base de données utmp.
systemd dispose d’un système de transactions minimal : si une unité est demandée pour être démarrée ou arrêtée, elle l’ajoute ainsi que toutes ses dépendances à une transaction temporaire. Ensuite, il vérifie si la transaction est cohérente (c’est-à-dire si l’ordre de toutes les unités est sans cycle). Si ce n’est pas le cas, systemd tentera de la corriger et supprimera les tâches non essentielles de la transaction qui pourraient supprimer la boucle. De plus, systemd tente de supprimer les tâches non essentielles dans la transaction qui arrêteraient un service en cours d’exécution. Enfin, il est vérifié si les tâches de la transaction contredisent les tâches qui ont déjà été mises en file d’attente, et la transaction est éventuellement abandonnée. Si tout s’est bien passé et que la transaction est cohérente et minimisée dans son impact, elle est fusionnée avec toutes les tâches en attente et ajoutée à la file d’exécution. En termes simples, avant d’exécuter une opération demandée, systemd vérifie qu’elle est logique, en la corrigeant si possible, et échoue uniquement si cela n’est vraiment pas possible.
Notez que les transactions sont générées indépendamment de l'état d'une unité au moment de l'exécution. Par conséquent, par exemple, si une demande de démarrage est effectuée sur une unité déjà démarrée, une transaction sera tout de même générée et toutes les dépendances inactives seront réactivées (et cela entraînera la propagation d'autres tâches, conformément aux relations définies). En effet, la tâche en attente est comparée à l'état de l'unité cible au moment de l'exécution et est marquée comme réussie et terminée lorsque les deux correspondent. Cependant, cette tâche inclut également d'autres dépendances en raison des relations définies, ce qui entraîne, dans notre exemple, le fait que des tâches de démarrage pour toutes ces unités inactives soient également ajoutées à la file d'attente.
Les unités peuvent être générées dynamiquement au démarrage et lors du rechargement du gestionnaire de système, par exemple en fonction d'autres fichiers de configuration ou de paramètres passés sur la ligne de commande du noyau. Pour plus de détails, consultez systemd.generator(7).
RÉPERTOIRES
Répertoires des unités système
Le gestionnaire de système systemd lit les configurations des unités à partir de divers répertoires. Les paquets qui souhaitent installer des fichiers d'unité doivent 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 utilisateur a toujours la priorité. pkg-config systemd --variable=systemdsystemconfdir renvoie le chemin du répertoire de configuration du système.
Les paquets ne doivent modifier le contenu de ces répertoires qu'avec les commandes enable et disable de l'outil systemctl(1). La liste complète 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, la spécification XDG Base Directory[5] est suivie pour trouver les unités. Les applications doivent placer leurs fichiers d'unité dans le répertoire renvoyé par pkg-config systemd --variable=systemduserunitdir. La configuration globale est effectuée dans le répertoire indiqué par pkg-config systemd --variable=systemduserconfdir. Les commandes enable et disable de l'outil systemctl(1) peuvent gérer l'activation/désactivation des unités, tant au niveau global (c'est-à-dire pour tous les utilisateurs) qu'au niveau privé (pour un seul utilisateur). La liste complète des répertoires est fournie dans systemd.unit(5).
SIGNALS
Le service écoute divers signaux de processus UNIX qui peuvent être utilisés pour demander diverses actions de manière asynchrone. La gestion des signaux est activée très tôt au démarrage, avant que d'autres processus ne soient invoqués. Cependant, un gestionnaire de conteneurs superviseur ou similaire qui souhaite demander ces opérations via ce mécanisme doit tenir compte du fait que cette fonctionnalité n'est pas disponible pendant la phase d'initialisation la plus précoce. Un message de notification sd_notify() contenant le champ X_SYSTEMD_SIGNALS_LEVEL=2 est émis une fois que les gestionnaires de signaux sont activés, voir ci-dessous. Cela peut être utilisé pour planifier correctement la soumission de ces signaux.
SIGTERM
Lors de la réception de ce signal, le gestionnaire de système systemd sérialise son état, se réexécute et désérialise à nouveau l’état enregistré. Cela équivaut en grande partie à systemctl daemon-reexec.
Les gestionnaires de système systemd utilisateur démarreront l’unité exit.target lorsqu’ils recevront ce signal. Cela
équivaut en grande partie à systemctl --user start exit.target --job-mode=replace-irreversibly.
SIGINT
Lors de la réception de ce signal, le gestionnaire de système systemd démarrera l’unité ctrl-alt-del.target . Cela équivaut en grande partie à systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly. Si ce signal est reçu plus de 7 fois en 2 secondes, un redémarrage immédiat est déclenché. Notez que l’appui sur Ctrl+Alt+Suppr sur la console déclenche ce signal. Par conséquent, si un redémarrage est bloqué, appuyer plus de 7 fois sur Ctrl+Alt+Suppr en 2 secondes est un moyen relativement sûr de déclencher un redémarrage immédiat.
Les gestionnaires de système systemd utilisateur traitent ce signal de la même manière que SIGTERM.
SIGWINCH
Lors de la réception de ce signal, le gestionnaire de système systemd démarrera l’unité kbrequest.target. Cela équivaut en grande partie à systemctl start kbrequest.target.
Ce signal est ignoré par les gestionnaires de système systemd utilisateur.
SIGPWR
Lors de la réception de ce signal, le gestionnaire systemd démarrera l’unité sigpwr.target. Cela équivaut en grande partie à systemctl start sigpwr.target.
SIGUSR1
Lors de 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 enregistrera son état complet sous une forme lisible par l’homme. Les données enregistrées sont les mêmes que celles affichées par systemd-analyze dump.
SIGHUP
Recharge la configuration complète du démon. Cela équivaut en grande partie à systemctl daemon-reload.
SIGRTMIN+0
Entre en mode par défaut et démarre l’unité default.target. Cela équivaut en grande partie à systemctl isolate default.target.
SIGRTMIN+1
Entre en mode de récupération et démarre l’unité rescue.target. Cela équivaut en grande partie à systemctl isolate rescue.target.
SIGRTMIN+2
Entre en mode d’urgence et démarre l’unité emergency.service. Cela équivaut en grande partie à systemctl isolate emergency.service.
SIGRTMIN+3
Arrête la machine et démarre l’unité halt.target. Cela équivaut en grande partie à systemctl start halt.target --job-mode=replace-irreversibly.
SIGRTMIN+4
Éteint la machine et démarre l’unité poweroff.target. Cela équivaut en grande partie à systemctl start poweroff.target --job-mode=replace-irreversibly.
SIGRTMIN+5
Redémarre la machine et démarre l’unité reboot.target. Cela équivaut en grande partie à systemctl start reboot.target --job-mode=replace-irreversibly.
SIGRTMIN+6
Redémarre la machine via kexec et démarre l’unité kexec.target. Cela équivaut en grande partie à systemctl start kexec.target --job-mode=replace-irreversibly.
SIGRTMIN+7
Redémarre l’espace utilisateur et lance l’unité soft-reboot.target. Cela équivaut en grande partie à la commande systemctl start soft-reboot.target --job-mode=replace-irreversibly.
Ajouté dans la version 254.
SIGRTMIN+13
Arrête immédiatement la machine.
SIGRTMIN+14
Met la machine hors tension immédiatement.
SIGRTMIN+15
Redémarre immédiatement la machine.
SIGRTMIN+16
Redémarre immédiatement la machine avec kexec.
SIGRTMIN+17
Redémarre immédiatement l’espace utilisateur.
Ajouté dans la version 254.
SIGRTMIN+20
Active l’affichage des messages d’état sur la console, comme contrôlé par systemd.show_status=1 sur la ligne de commande du noyau.
Il est préférable d’utiliser SetShowStatus() au lieu de SIGRTMIN+20 afin d’éviter les conflits. Voir org.freedesktop.systemd1(5).
SIGRTMIN+21
Désactive l’affichage des messages d’état sur la console, comme contrôlé par systemd.show_status=0 sur la ligne de commande du noyau.
Il est préférable d’utiliser SetShowStatus() au lieu de SIGRTMIN+21 afin d’éviter les conflits. Voir org.freedesktop.systemd1(5).
SIGRTMIN+22
Définit le niveau de journalisation du gestionnaire de services sur « debug », d’une manière équivalente à systemd.log_level=debug sur la ligne de commande du noyau.
SIGRTMIN+23
Restaure le niveau de journalisation à sa valeur configurée. La valeur configurée est dérivée, par ordre de priorité, de la valeur spécifiée avec systemd.log-level= sur la ligne de commande du noyau, ou de la valeur spécifiée avec LogLevel= dans le fichier de configuration, ou de la valeur par défaut intégrée de « info ».
Ajouté dans la version 239.
SIGRTMIN+24
Quitte immédiatement le gestionnaire (uniquement disponible pour les instances --user).
Ajouté dans la version 195.
SIGRTMIN+25
Lorsqu’il reçoit ce signal, le gestionnaire systemd se réexécute. Cela équivaut en grande partie à la commande systemctl daemon-reexec, sauf que cela se fait de manière asynchrone.
Le gestionnaire système systemd traite ce signal de la même manière que SIGTERM.
Ajouté dans la version 250.
SIGRTMIN+26
Restaure la cible de journalisation à sa valeur configurée. La valeur configurée est dérivée, par ordre de priorité, de la valeur spécifiée avec systemd.log-target= sur la ligne de commande du noyau, ou de la valeur spécifiée avec LogTarget= dans le fichier de configuration, ou de la valeur par défaut intégrée.
Ajouté dans la version 239.
SIGRTMIN+27, SIGRTMIN+28
Définit la cible de journalisation sur « console » avec SIGRTMIN+27 (ou sur « kmsg » avec SIGRTMIN+28), d’une manière équivalente à systemd.log_target=console (ou systemd.log_target=kmsg avec SIGRTMIN+28) sur la ligne de commande du noyau.
Ajouté dans la version 239.
ENVIRONNEMENT
Le bloc d’environnement du gestionnaire système est initialement défini par le noyau. (En particulier, les affectations « key=value » sur la ligne de commande du noyau sont transformées en variables d’environnement pour PID 1. Pour le gestionnaire utilisateur, le gestionnaire système définit l’environnement comme décrit dans la section « Variables d’environnement dans les processus générés » de systemd.exec(5). Le paramètre DefaultEnvironment= dans le gestionnaire système s’applique à tous les services, y compris [email protected]. Des entrées supplémentaires peuvent être configurées (comme pour tout autre service) via les paramètres Environment= et EnvironmentFile= pour [email protected] (voir systemd.exec(5)). De plus, des variables d’environnement supplémentaires peuvent être définies via le paramètre ManagerEnvironment= dans systemd-system.conf(5) et systemd-user.conf(5).
Voici quelques-unes des variables comprises par systemd :
$SYSTEMD_LOG_LEVEL
Le niveau de journalisation maximal des messages émis (les messages ayant un niveau de journalisation plus élevé, c’est-à-dire moins importants, seront supprimés). Prend une liste de valeurs séparées par des virgules. Une valeur peut être l’une des suivantes (par ordre d’importance décroissante) : emerg, alert, crit, err, warning, notice, info, debug, ou un entier dans la plage 0…7. Voir syslog(3) pour plus d’informations. Chaque valeur peut être précédée en option de l’un des éléments suivants : console, syslog, kmsg ou journal, suivi de deux-points, pour définir le niveau de journalisation maximal pour cette cible de journalisation spécifique (par exemple, `SYSTEMD_LOG_LEVEL=debug,console:info` spécifie d’enregistrer au niveau debug, sauf lors de l’enregistrement dans la console, ce qui doit se faire au niveau info). Notez que le niveau de journalisation maximal global a la priorité sur les niveaux de journalisation maximaux par cible.
Cela peut être remplacé avec --log-level=.
$SYSTEMD_LOG_COLOR
Une valeur booléenne. Si elle est vraie, les messages écrits dans le terminal seront colorés en fonction de leur priorité.
Cela peut être remplacé avec --log-color=.
$SYSTEMD_LOG_TIME
Une valeur booléenne. Si elle est vraie, les messages de journalisation de la console seront préfixés d’un horodatage.
Ajouté dans la version 246.
Cela peut être remplacé avec --log-time=.
$SYSTEMD_LOG_LOCATION
Une valeur booléenne. Si elle est vraie, les messages seront préfixés du nom de fichier et du numéro de ligne dans le code source où le message a été généré.
Cela peut être remplacé avec --log-location=.
$SYSTEMD_LOG_TID
Une valeur booléenne. Si elle est vraie, les messages seront préfixés de l’ID de thread numérique actuel.
Ajouté dans la version 247.
$SYSTEMD_LOG_TARGET
La destination des messages de journalisation. L’une des valeurs suivantes : console (journalisation vers le terminal connecté), console-prefixed (journalisation vers le terminal connecté, mais avec des préfixes codant le niveau de journalisation et la « facility », voir syslog(3)), kmsg (journalisation vers le tampon de journalisation circulaire du noyau), journal (journalisation vers le journal), journal-or-kmsg (journalisation vers le journal si celui-ci est disponible, et vers kmsg sinon), auto (déterminer automatiquement la cible de journalisation appropriée, par défaut), null (désactiver la sortie de journalisation).
Cela peut être remplacé avec --log-target=.
$SYSTEMD_LOG_RATELIMIT_KMSG
Indique s’il faut limiter le débit de kmsg ou non. Prend une valeur booléenne. La valeur par défaut est « true ». Si elle est désactivée, systemd ne limitera pas le débit des messages écrits vers kmsg.
Ajouté dans la version 254.
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
Le gestionnaire d’utilisateurs systemd utilise ces variables conformément à la spécification XDG Base Directory[5] pour trouver sa configuration.
$SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH, $SYSTEMD_ENVIRONMENT_GENERATOR_PATH
Indique où systemd recherche 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 cette liste est définie, si elle se termine par un composant vide ("...:") cette liste est ajoutée au début de l’ensemble de chemins habituel. Sinon, la liste spécifiée remplace l’ensemble de chemins habituel.
$SYSTEMD_PAGER, $PAGER
Le paginator à utiliser lorsque l’option --no-pager n’est pas spécifiée. $SYSTEMD_PAGER est utilisé s’il est défini ; sinon, $PAGER est utilisé. Si ni $SYSTEMD_PAGER ni $PAGER ne sont définis, une série d’implémentations de paginateur bien connues est essayée à tour de rôle, y compris [less]({filename}../../less)(1) et more(1), jusqu’à ce qu’une soit trouvée. Si aucune implémentation de paginateur n’est découverte, aucun paginateur n’est invoqué. Définir ces variables d’environnement sur une chaîne vide ou sur la valeur « cat » équivaut à utiliser l’option --no-pager.
Remarque : si $SYSTEMD_PAGERSECURE n’est pas défini, $SYSTEMD_PAGER et $PAGER ne peuvent être utilisés que pour désactiver le paginateur (avec « cat » ou « »), et sont sinon ignorés.
$SYSTEMD_LESS
Remplace les options transmises à less (par défaut, « FRSXMK »).
Les utilisateurs peuvent souhaiter modifier deux options en particulier :
K
Cette option indique au paginateur de quitter immédiatement lorsque Ctrl+C est enfoncé. Pour permettre à less de gérer lui-même Ctrl+C afin de revenir à l’invite de commandes du paginateur, désactivez cette option.
Si la valeur de $SYSTEMD_LESS n’inclut pas « K », et que le paginateur invoqué est less, Ctrl+C sera ignoré par l’exécutable, et devra être géré par le paginateur.
X
Cette option indique au paginateur de ne pas envoyer de chaînes d’initialisation et de désinitialisation termcap au terminal. Elle est définie par défaut pour permettre au résultat de la commande de rester visible dans le terminal même après la fermeture du paginateur. Toutefois, cela empêche certaines fonctionnalités du paginateur de fonctionner, en particulier, la sortie paginée ne peut pas être défilée avec la souris.
Notez que définir la variable d’environnement $LESS standard n’a aucun effet pour les invocations de less par les outils systemd.
Consultez [less]({filename}../../less)(1) pour plus d’informations.
$SYSTEMD_LESSCHARSET
Remplace le jeu de caractères transmis à less (par défaut, « utf-8 », si le terminal d’appel est déterminé comme étant compatible UTF-8).
Notez que définir la variable d’environnement $LESSCHARSET standard n’a aucun effet pour les invocations de less par les outils systemd.
$SYSTEMD_PAGERSECURE
Les commandes de paginateur courantes, telles que [less]({filename}../../less)(1), en plus de la « pagination », c’est-à-dire du défilement de la sortie, prennent en charge l’ouverture ou l’écriture dans d’autres fichiers et l’exécution de commandes shell arbitraires. Lorsque les commandes sont invoquées avec des privilèges élevés, par exemple sous [sudo]({filename}../../sudo)(8) ou pkexec(1), le paginateur devient une limite de sécurité. Il faut veiller à ce que seuls les programmes ayant une fonctionnalité strictement limitée soient utilisés comme paginateurs, et que les fonctionnalités interactives non intentionnelles telles que l’ouverture ou la création de nouveaux fichiers ou le démarrage de sous-processus ne soient pas autorisées. Le « mode sécurisé » pour le paginateur peut être activé comme décrit ci-dessous, si le paginateur le prend en charge (la plupart des paginateurs ne sont pas écrits de manière à prendre cela en considération). Il est recommandé d’activer explicitement le « mode sécurisé » ou de désactiver complètement le paginateur en utilisant l’option --no-pager ou PAGER=cat lorsque des utilisateurs non approuvés exécutent des commandes avec des privilèges élevés.
Cette option prend un argument booléen. Lorsqu’elle est définie sur true, le « mode sécurisé » du paginateur est activé. En « mode sécurisé », LESSSECURE=1 est défini lors de l’appel du paginateur, ce qui indique au paginateur de désactiver les commandes qui ouvrent ou créent de nouveaux fichiers ou qui démarrent de nouveaux sous-processus. Actuellement, seul less(1) est connu pour prendre en charge cette variable et implémenter le « mode sécurisé ».
Lorsqu’elle est définie sur false, aucune limitation n’est appliquée au paginateur. Définir SYSTEMD_PAGERSECURE=0 ou ne pas le supprimer de l’environnement hérité peut permettre à l’utilisateur d’exécuter des commandes arbitraires.
Lorsque $SYSTEMD_PAGERSECURE n’est pas défini, les outils systemd tentent de déterminer automatiquement si le « mode sécurisé » doit être activé et si le paginateur le prend en charge. Le « mode sécurisé » est activé si l’UID effectif n’est pas le même que celui du propriétaire de la session de connexion, voir geteuid(2) et sd_pid_get_owner_uid(3), ou lors de l’exécution sous sudo(8) ou des outils similaires ($SUDO_UID est défini [6]). Dans ces cas, SYSTEMD_PAGERSECURE=1 est défini et les paginateurs qui ne prennent pas en charge le « mode sécurisé » ne sont pas utilisés. Notez que cette détection automatique ne couvre que les mécanismes d’élévation de privilèges les plus courants et est conçue pour plus de commodité. Il est recommandé de définir explicitement $SYSTEMD_PAGERSECURE ou de désactiver le paginateur.
Notez que si les variables $SYSTEMD_PAGER ou $PAGER doivent être prises en compte, autre que pour désactiver le paginateur, $SYSTEMD_PAGERSECURE doit également être défini.
$SYSTEMD_COLORS
Prend un argument booléen. Lorsqu’elle est définie sur true, systemd et les utilitaires associés utiliseront des couleurs dans leur sortie, sinon la sortie sera monochrome. De plus, la variable peut prendre l’une des valeurs spéciales suivantes : « 16 », « 256 » pour restreindre l’utilisation des couleurs aux 16 ou 256 couleurs ANSI de base, respectivement. Cela peut être spécifié pour remplacer la décision automatique basée sur $TERM et la connexion de la console.
$SYSTEMD_URLIFY
La valeur doit être un booléen. Contrôle si des liens cliquables doivent être générés dans la sortie pour les émulateurs de terminal qui prennent en charge cette fonction. Cela peut être spécifié pour remplacer la décision que systemd prend en fonction de $TERM et d’autres conditions.
$LISTEN_PID, $LISTEN_PIDFDID, $LISTEN_FDS, $LISTEN_FDNAMES
Défini par systemd pour les processus supervisés pendant l’activation basée sur socket. Voir sd_listen_fds(3) pour plus d’informations.
$NOTIFY_SOCKET
Défini par le gestionnaire de services pour ses services afin de notifier l’état et la disponibilité. Également utilisé par le gestionnaire de services pour notifier les gestionnaires de conteneurs ou les gestionnaires de services supérieurs dans la pile sur ses propres progrès. Voir sd_notify(3) et la section correspondante ci-dessous pour plus d’informations.
Pour plus de variables d’environnement prises en charge par systemd et ses différents composants, voir Variables d’environnement connues [7].
LIGNE DE COMMANDE DU NOYAU
Lorsqu’il est exécuté en tant qu’instance système, systemd analyse un certain nombre d’options répertoriées ci-dessous. Elles peuvent être spécifiées en tant qu’arguments de la ligne de commande du noyau, qui sont analysés à partir de plusieurs sources en fonction de l’environnement dans lequel systemd est exécuté. S’il est exécuté à l’intérieur d’un conteneur Linux, ces options sont analysées à partir des arguments de la ligne de commande passés à systemd lui-même, en plus de toutes les options de ligne de commande répertoriées dans la section Options ci-dessus. S’il est exécuté à l’extérieur des conteneurs Linux, ces arguments sont analysés à partir de /proc/cmdline.
Les variables suivantes sont prises en compte :
systemd.unit=, rd.systemd.unit=
Remplace l’unité à activer au démarrage. La valeur par défaut est default.target. Cela peut être utilisé pour démarrer temporairement dans une unité de démarrage différente, par exemple rescue.target ou emergency.service. Voir systemd.special(7) pour plus de détails sur ces unités. L’option précédée de « rd. » n’est prise en compte que dans l’initrd, tandis que celle qui ne l’est pas ne l’est que dans le système principal.
systemd.dump_core
Accepte un argument booléen ou active l’option si elle est spécifiée sans argument. Si elle est activée, le gestionnaire systemd (PID 1) crée un fichier core lorsqu’il se bloque. Sinon, aucun fichier core n’est créé. La valeur par défaut est activée.
Ajouté dans la version 233.
systemd.crash_chvt
Accepte un entier positif ou un argument booléen. Peut également être spécifié sans argument, ce qui a le même effet qu’un booléen positif. Si un entier positif (dans la plage de 1 à 63) est spécifié, le gestionnaire système (PID 1) activera le terminal virtuel spécifié lorsqu’il se bloque. La valeur par défaut est désactivée, ce qui signifie qu’aucune commutation n’est tentée. Si elle est définie sur activée, le terminal virtuel vers lequel les messages du noyau sont écrits est utilisé à la place.
Ajouté dans la version 233.
systemd.crash_shell
Accepte un argument booléen ou active l’option si elle est spécifiée sans argument. Si elle est activée, le gestionnaire système (PID 1) lance un shell lorsqu’il se bloque. Sinon, aucun shell n’est lancé. La valeur par défaut est désactivée, pour des raisons de sécurité, car le shell n’est pas protégé par une authentification par mot de passe.
Ajouté dans la version 233.
systemd.crash_action=
Accepte l’une des valeurs suivantes : « freeze », « reboot » ou « poweroff ». La valeur par défaut est « freeze ». Si elle est définie sur « freeze », le système se bloquera indéfiniment lorsque le gestionnaire système (PID 1) se bloquera. Si elle est définie sur « reboot », le gestionnaire système (PID 1) redémarrera automatiquement la machine lorsqu’il se bloquera, après un délai de 10 secondes. Si elle est définie sur « poweroff », le gestionnaire système (PID 1) éteindra immédiatement la machine lorsqu’il se bloquera. Si elle est combinée avec systemd.crash_shell, l’action de blocage configurée est exécutée après la fermeture du shell.
Ajouté dans la version 256.
systemd.confirm_spawn
Accepte un argument booléen ou un chemin d’accès à la console virtuelle où les messages de confirmation doivent être affichés. Peut également être spécifié sans argument, ce qui a le même effet qu’un booléen positif. Si elle est activée, le gestionnaire système (PID 1) demande une confirmation lors du lancement de processus à l’aide de /dev/console. Si un chemin ou un nom de console (tel que « ttyS0 ») est fourni, la console virtuelle pointée par ce chemin ou décrite par le nom donné sera utilisée à la place. La valeur par défaut est désactivée.
Ajouté dans la version 233.
systemd.service_watchdogs=
Accepte un argument booléen. Si désactivé, tous les chiens de garde d’exécution des services (WatchdogSec=) et les actions d’urgence (par exemple, OnFailure= ou StartLimitAction=) sont ignorés par le gestionnaire de système (PID 1) ; voir systemd.service(5). Par défaut, il est activé, ce qui signifie que les chiens de garde et les actions en cas d’échec sont traités normalement. Le chien de garde matériel n’est pas affecté par cette option.
Ajouté dans la version 237.
systemd.show_status
Accepte un argument booléen, ou les constantes error et auto. Peut également être spécifié sans argument, avec le même effet qu’un booléen positif. S’il est activé, le gestionnaire systemd (PID 1) affiche des mises à jour d’état de service succinctes sur la console pendant le démarrage. Avec error, seuls les messages concernant les échecs sont affichés, mais le démarrage est sinon silencieux. auto se comporte comme false jusqu’à ce qu’il y ait un retard important au démarrage. Par défaut, il est activé, à moins que quiet ne soit passé en tant qu’option de ligne de commande du noyau, auquel cas il est par défaut sur error. Si spécifié, il remplace l’option de fichier de configuration du gestionnaire de système ShowStatus=, voir systemd-system.conf(5).
Ajouté dans la version 233.
systemd.status_unit_format=
Accepte name, description ou combined comme valeur. Si name, le gestionnaire de système utilisera les noms des unités dans les messages d’état. Si combined, le gestionnaire de système utilisera les noms des unités et la description dans les messages d’état. Lorsqu’il est spécifié, il remplace l’option de fichier de configuration du gestionnaire de système StatusUnitFormat=, 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 du journal, 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 spécifiés sans argument, avec le même effet qu’un booléen positif.
systemd.default_standard_output=, systemd.default_standard_error=
Contrôle la sortie standard et la sortie d’erreur par défaut pour les services et les sockets. C’est-à-dire, contrôle la valeur par défaut pour StandardOutput= et StandardError= (voir systemd.exec(5) pour plus de détails). Accepte l’une des valeurs suivantes : inherit, null, tty, journal, journal+console, kmsg, kmsg+console. Si l’argument est omis, systemd.default-standard-output= a la valeur journal et systemd.default-standard-error= a la valeur inherit.
systemd.setenv=
Accepte un argument de chaîne au format VARIABLE=VALUE. Peut être utilisé pour définir des variables d’environnement par défaut à ajouter aux processus enfants créés. Peut être utilisé plusieurs fois pour définir plusieurs variables.
systemd.machine_id=
Accepte une valeur hexadécimale de 32 caractères à utiliser pour définir l’ID de machine. Principalement destiné au démarrage en réseau où le même ID de machine est souhaité pour chaque démarrage.
Ajouté dans la version 229.
systemd.set_credential=, systemd.set_credential_binary=
Définit une credential système, qui peut ensuite être propagée aux services système à l’aide du paramètre ImportCredential= ou LoadCredential=, voir systemd.exec(5) pour plus de détails. Prend une paire de nom et de valeur de credential, séparés par deux points. Le paramètre systemd.set_credential= attend la valeur de la credential sous forme de texte littéral, le paramètre systemd.set_credential_binary= prend des données binaires encodées en Base64. Notez que la ligne de commande du noyau est généralement accessible par les programmes non privilégiés dans /proc/cmdline. Par conséquent, ce mécanisme ne convient pas au transfert de données sensibles. Utilisez-le uniquement pour les données qui ne sont pas sensibles (par exemple, les clés publiques/certificats, plutôt que les clés privées), ou dans les environnements de test/débogage.
Pour plus d’informations, consultez la documentation [System and Service Credentials][8].
Ajouté dans la version 251.
systemd.import_credentials=
Prend un argument booléen. Si la valeur est false, l’importation des credentials à partir de la ligne de commande du noyau, de la table OEM DMI/SMBIOS, du sous-système qemu_fw_cfg ou du stub du noyau EFI est désactivée.
Ajouté dans la version 251.
quiet
Désactive la sortie de l’état au démarrage, comme le ferait systemd.show_status=no. Notez que cette option est également lue par le noyau lui-même et désactive la sortie du journal du noyau. Le passage de cette option désactive donc la sortie habituelle à la fois du gestionnaire de système et du noyau.
Ajouté dans la version 186.
debug
Active la sortie de débogage. Cela équivaut à systemd.log_level=debug. Notez que cette option est également lue par le noyau lui-même et active la sortie de débogage du noyau. Le passage de cette option active donc la sortie de débogage à la fois du gestionnaire de système et du noyau.
Ajouté dans la version 205.
emergency, rd.emergency, -b
Démarre en mode d’urgence. Cela équivaut à systemd.unit=emergency.target ou rd.systemd.unit=emergency.target, respectivement, et est fourni pour des raisons de compatibilité et pour faciliter la saisie.
Ajouté dans la version 186.
rescue, rd.rescue, single, s, S, 1
Démarre en mode de récupération. Cela équivaut à systemd.unit=rescue.target ou rd.systemd.unit=rescue.target, respectivement, et est fourni pour des raisons de compatibilité et pour faciliter la saisie.
Ajouté dans la version 186.
2 3, 4, 5
Démarre dans le niveau d’exécution SysV hérité spécifié. 2, 3 et 4 sont équivalents à systemd.unit=multi-user.target ; et 5 est équivalent à systemd.unit=graphical.target, et est fourni pour des raisons de compatibilité et pour faciliter la 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éfinit la locale système à utiliser. Cela remplace les paramètres dans /etc/locale.conf. Pour plus d’informations, voir locale.conf(5) et locale(7).
Ajouté dans la version 186.
Pour les autres paramètres de ligne de commande du noyau compris par les composants du système d’exploitation principal, veuillez consulter kernel-command-line(7).
INFORMATIONS D'IDENTIFICATION DU SYSTÈME
Lors de l'initialisation, le gestionnaire de services importe les informations d'identification provenant de diverses sources dans l'ensemble des informations d'identification du système, qui peuvent ensuite être propagées aux services et utilisées par les générateurs :
Lorsque le gestionnaire de services s'initialise pour la première fois, il lit les informations d'identification du système à partir des chaînes du type 11 SMBIOS, io.systemd.credential:name=value et io.systemd.credential.binary:name=value.
Au même moment, il importe les informations d'identification de QEMU « fw_cfg ». (Notez que le mécanisme SMBIOS est généralement préféré, car il est plus rapide et générique.)
Les informations d'identification peuvent être transmises via la ligne de commande du noyau, en utilisant le paramètre systemd.set-credential=, voir ci-dessus.
Les informations d'identification peuvent être transmises depuis l'environnement UEFI via systemd-stub(7).
Lorsque le gestionnaire de services est invoqué pendant la transition initrd → hôte, il importe tous les fichiers de /run/credentials/@initrd/ en tant qu'informations d'identification du système.
Invoquez systemd-creds(1) comme suit pour afficher la liste des informations d'identification transmises au système :
# systemd-creds --system list
Pour plus d'informations, consultez la documentation Système et informations d'identification des services [8].
Le gestionnaire de services, lorsqu'il est exécuté en tant que PID 1, consomme les informations d'identification du système suivantes :
vmm.notify_socket
Contient une adresse AF_VSOCK ou AF_UNIX vers laquelle envoyer un message de notification READY=1 lorsque le gestionnaire de services a terminé le démarrage. Voir sd_notify(3) et la section suivante pour plus d'informations. Notez que si l'hyperviseur ne prend pas en charge SOCK_DGRAM sur AF_VSOCK, SOCK_SEQPACKET sera essayé à la place. La charge utile d'informations d'identification pour AF_VSOCK doit être une chaîne du formulaire « vsock:CID:PORT ». « vsock-stream », « vsock-dgram » et « vsock-seqpacket » peuvent être utilisés à la place de « vsock » pour forcer l'utilisation du type de socket correspondant.
Cette fonctionnalité est utile pour les gestionnaires de machines ou d'autres processus sur l'hôte afin de recevoir une notification via VSOCK lorsqu'une machine virtuelle a terminé le démarrage.
Ajouté dans la version 254.
system.machine_id
Prend un ID hexadécimal de 128 bits pour initialiser /etc/machine-id, si le fichier n'est pas encore configuré. Voir machine-id(5) pour plus de détails.
Ajouté dans la version 254.
Pour une liste des informations d'identification du système que divers autres composants de systemd consomment, consultez systemd.systemcredentials(7).
PROTOCOLE DE PRÉPARATION
Le gestionnaire de services met en œuvre un protocole de notification de préparation à la fois entre le gestionnaire et ses services (c'est-à-dire vers le bas de la pile), et entre le gestionnaire et un superviseur potentiel plus haut dans la pile (ce dernier pouvant être un gestionnaire de machines ou de conteneurs, ou dans le cas d'un gestionnaire de services par utilisateur, l'instance du gestionnaire de services système). Le protocole de base (et l'API suggérée pour celui-ci) est décrit dans sd_notify(3).
Le socket de notification que le gestionnaire de services (y compris PID 1) utilise pour signaler la préparation à son propre superviseur est défini via la variable d'environnement $NOTIFY_SOCKET (voir ci-dessus). Étant donné que cela ne peut être défini directement que pour les gestionnaires de conteneurs et pour l'instance par utilisateur du gestionnaire de services, un mécanisme supplémentaire pour configurer cela est disponible, en particulier dans le but d'être utilisé dans les environnements de machines virtuelles : l'information d'identification du système vmm.notify_socket peut être définie sur un socket approprié (généralement un AF_VSOCK) via les chaînes du type 11 SMBIOS. Pour plus de détails, voir ci-dessus.
Le protocole de notification du gestionnaire de services vers les niveaux supérieurs de la hiérarchie, à destination d’un superviseur, prend en charge un certain nombre de champs d’extension qui permettent à un superviseur d’en apprendre davantage sur les propriétés spécifiques du système et de suivre sa progression au démarrage. Les champs suivants sont envoyés :
Un message X_SYSTEMD_HOSTNAME=... sera envoyé une fois que le nom d’hôte initial du système aura été déterminé. Notez que, ultérieurement, le nom d’hôte peut être modifié à nouveau par programmation, et (actuellement) aucun autre message n’est envoyé dans ce cas.
Ajouté dans la version 256.
Un message X_SYSTEMD_MACHINE_ID=... sera envoyé une fois que l’ID de machine du système aura été déterminé. Voir machine-id(5) pour plus de détails.
Ajouté dans la version 256.
Un message X_SYSTEMD_SIGNALS_LEVEL=... sera envoyé une fois que le gestionnaire de services aura installé les différents gestionnaires de signaux de processus UNIX décrits ci-dessus. La valeur du champ est un entier non signé mis en forme sous forme de chaîne décimale et indique le niveau de prise en charge des fonctionnalités de signaux de processus UNIX du gestionnaire de services. Actuellement, un seul niveau de fonctionnalité est défini :
X_SYSTEMD_SIGNALS_LEVEL=2 couvre les différents signaux de processus UNIX documentés ci-dessus, qui constituent un sur-ensemble de ceux pris en charge par le système SysV init historique.
Les signaux envoyés au PID 1 avant l’envoi de ce message peuvent ne pas être correctement gérés. Un consommateur de ces messages doit analyser la valeur en tant qu’entier non signé qui indique le niveau de prise en charge. Pour l’instant, seul le niveau 2 mentionné est défini, mais ultérieurement, des niveaux supplémentaires peuvent être définis avec des entiers plus élevés, qui mettront en œuvre 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 lorsqu’elle devient active ou cesse de l’être. Ceci est utile pour suivre la progression du démarrage et les fonctionnalités. Par exemple, une fois que l’unité ssh-access.target est signalée comme ayant démarré, l’accès SSH est généralement disponible, voir systemd.special(7) pour plus de détails.
Ajouté dans la version 256.
Un message X_SYSTEMD_SHUTDOWN=... sera envoyé peu avant que le système ne s’éteigne. La valeur est l’une des chaînes « reboot », « halt », « poweroff » et « kexec » et indique le type d’arrêt qui est exécuté.
Ajouté dans la version 256.
Un message X_SYSTEMD_REBOOT_PARAMETER=... sera également envoyé peu avant que le système ne s’éteigne. Sa valeur est l’argument de redémarrage tel que configuré avec systemctl --reboot-argument=....
Ajouté dans la version 256.
Notez que ces champs d’extension sont envoyés en plus des notifications « READY=1 » et « RELOADING=1 » habituelles.
OPTIONS
systemd est rarement invoqué directement, car il est démarré tôt et 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 donner des commandes au gestionnaire. Étant donné que systemd n’est généralement pas invoqué directement, les options énumérées ci-dessous sont principalement utiles pour le débogage et à des fins spéciales.
Options d’introspection et de débogage
Ces options sont utilisées pour les tests et l’introspection, et systemd peut être invoqué avec ces options à tout moment :
--dump-configuration-items
Affiche la liste des éléments de configuration d’unité pris en charge. Cela génère une liste concise mais complète des éléments de configuration pris en charge dans les fichiers de définition d’unité.
--dump-bus-properties
Affiche les propriétés exposées sur le bus. Cela génère une liste concise mais complète des propriétés exposées sur D-Bus.
Ajouté dans la version 239.
--test
Détermine la transaction de démarrage initiale (c’est-à-dire la liste des tâches mises en file d’attente au démarrage), l’affiche et quitte — sans exécuter réellement aucune des tâches déterminées. Cette option est utile uniquement pour le débogage. Notez que, lors du démarrage normal du gestionnaire de services, des unités supplémentaires non affichées par cette opération peuvent être démarrées, car le matériel, les sockets, le bus ou d’autres types d’activation peuvent ajouter des tâches supplémentaires au fur et à mesure de l’exécution de la transaction. Utilisez --system pour demander la transaction initiale du gestionnaire de services système (il s’agit également de la valeur par défaut implicite), combinez avec --user pour demander la transaction initiale de l’instance par utilisateur.
--system, --user
Lorsqu’ils sont utilisés en conjonction avec --test, ils sélectionnent si la transaction initiale doit être calculée pour l’instance système ou pour une instance par utilisateur. Ces options n’ont aucun effet lorsqu’elles sont invoquées sans --test, car lors des invocations normales (c’est-à-dire non --test), le gestionnaire de services détectera automatiquement s’il doit fonctionner en mode système ou en mode par utilisateur, en vérifiant si le PID avec lequel il est exécuté est 1 ou non. Notez qu’il n’est pas pris en charge de démarrer et de maintenir un système avec le gestionnaire de services fonctionnant en mode --system mais avec un PID autre que 1.
-h, --help
Affiche un court texte d’aide et quitte.
--version
Affiche une courte chaîne de version et quitte.
Options qui dupliquent les paramètres de la ligne de commande du noyau
Ces options correspondent directement aux options répertoriées ci-dessus dans « Ligne de commande du noyau ». Les deux formes peuvent être utilisées de manière équivalente pour le gestionnaire de services, mais il est recommandé d’utiliser les formes répertoriées ci-dessus dans ce contexte, car elles sont correctement nommées. Lorsqu’une option est spécifiée à la fois dans la ligne de commande du noyau et en tant qu’argument de ligne de commande normal, cette dernière a la priorité.
Lorsque systemd est utilisé comme gestionnaire d’utilisateur, la ligne de commande du noyau est ignorée et seules les options décrites ci-dessous sont prises en charge. Néanmoins, systemd est généralement démarré dans ce mode via le service [email protected](5), qui est partagé entre tous les utilisateurs. Il peut être plus pratique d’utiliser des fichiers de configuration pour modifier les paramètres (voir systemd-user.conf(5)), ou des variables d’environnement. Voir la section « Environnement » ci-dessus pour une discussion sur la façon dont le bloc d’environnement est défini.
--unit=
Définit l’unité par défaut à activer au démarrage. Si ce paramètre n’est pas spécifié, la valeur par défaut est default.target. Voir systemd.unit= ci-dessus.
--dump-core
Active la création de fichiers core en cas de plantage. Cette option n’a aucun effet lorsque systemd est exécuté en tant qu’instance utilisateur. Identique à systemd.dump_core= ci-dessus.
--crash-vt=VT
Passe à une console virtuelle (VT) spécifique en cas de plantage. Cette option n’a aucun effet lorsque systemd est exécuté en tant qu’instance utilisateur. Identique à systemd.crash_chvt= ci-dessus (mais avec une orthographe différente !).
Ajouté dans la version 227.
--crash-shell
Exécute une invite de commandes en cas de plantage. Cette option n’a aucun effet lorsque systemd est exécuté en tant qu’instance utilisateur. Voir systemd.crash_shell= ci-dessus.
--crash-action=
Spécifie l’action à effectuer lorsque le gestionnaire de système (PID 1) plante. Cette option n’a aucun effet lorsque systemd est exécuté en tant qu’instance utilisateur. Voir systemd.crash_action= ci-dessus.
Ajouté dans la version 256.
--confirm-spawn
Demande une confirmation lors du lancement de processus. Cette option n’a aucun effet lorsque systemd est exécuté en tant qu’instance utilisateur. Voir systemd.confirm_spawn ci-dessus.
--show-status
Affiche des informations succinctes sur l’état des unités dans la console pendant le démarrage et l’arrêt. Voir systemd.show_status ci-dessus.
Ajouté dans la version 244.
--log-color
Met en surbrillance les messages de journal importants. Voir systemd.log_color ci-dessus.
Ajouté dans la version 244.
--log-level=
Définit le niveau de journalisation. Voir systemd.log_level ci-dessus.
--log-location
Inclut l’emplacement du code dans les messages de journalisation. Voir systemd.log_location ci-dessus.
Ajouté dans la version 244.
--log-target=
Définit la cible de journalisation. Voir systemd.log_target ci-dessus.
--log-time=
Ajoute un horodatage en préfixe des messages de la console. Voir systemd.log_time ci-dessus.
Ajouté dans la version 246.
--machine-id=
Remplace l’ID de machine défini sur le disque dur. Voir systemd.machine_id= ci-dessus.
Ajouté dans la version 229.
--service-watchdogs
Active ou désactive globalement tous les délais d’attente et actions d’urgence des chiens de garde de service. Voir systemd.service_watchdogs ci-dessus.
Ajouté dans la version 237.
--default-standard-output=, --default-standard-error=
Définit la sortie standard ou la sortie d’erreur par défaut pour tous les services et sockets, respectivement. Voir systemd.default_standard_output= et systemd.default_standard_error= ci-dessus.
ÉPOQUE DE L’HORLOGE SYSTÈME
Lorsque systemd est démarré ou redémarré, il peut définir l’horloge système à « l’époque ». Ce mécanisme est utilisé pour garantir que l’horloge système reste raisonnablement initialisée et approximativement monotone entre les redémarrages, au cas où il n’y aurait pas de RTC locale alimentée par batterie, ou si celle-ci ne fonctionne pas correctement.
L’époque est la date la plus ancienne après laquelle l’heure de l’horloge système est supposée être définie correctement. Lors de l’initialisation, l’horloge locale est avancée à l’époque si elle était définie sur une valeur inférieure. Dans un cas particulier, si l’horloge locale est suffisamment avancée dans le futur (par défaut, 15 ans, mais cela peut être configuré au moment de la compilation), l’horloge matérielle est supposée être défectueuse, et l’horloge système est ramenée à l’époque.
L’époque est définie sur la valeur la plus élevée parmi : la date de compilation de systemd, la date de modification (« mtime ») de /usr/lib/clock-epoch, et la date de modification de /var/lib/systemd/timesync/clock.
FICHIERS
/run/systemd/notify
Socket de notification d’état du démon. Il s’agit d’un socket datagramme AF_UNIX et il est utilisé pour implémenter la logique de notification du démon telle qu’elle est implémentée par sd_notify(3).
/run/systemd/private
Utilisé en interne comme canal de communication entre [systemctl]({filename}../../systemctl)(1) et le processus systemd. Il s’agit d’un socket de flux AF_UNIX. Cette interface est privée à systemd et ne doit pas être utilisée dans des projets externes.
/usr/lib/clock-epoch
La date de modification (« mtime ») de ce fichier est utilisée pour l’époque temporelle, 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). S’il est présent, la date de modification du fichier est utilisée pour l’époque, voir la section précédente.
Ajouté dans la version 257.
HISTORIQUE
systemd 252
Les arguments de ligne de commande du noyau systemd.unified_cgroup_hierarchy et systemd.legacy_systemd_cgroup_controller ont été dépréciés. Veuillez passer à la hiérarchie cgroup unifiée.
VOIR AUSSI
La page d’accueil de systemd[9], systemd-system.conf(5), locale.conf(5), [systemctl]({filename}../../systemctl)(1), [journalctl]({filename}../../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 plus d’informations sur les concepts et les idées qui sous-tendent systemd, veuillez consulter le document de conception original[10].
NOTES
Portabilité et promesse de stabilité de l’interface
https://systemd.io/PORTABILITY_AND_STABILITY/
Interface de conteneur
https://systemd.io/CONTAINER_INTERFACE
Interface initrd
https://systemd.io/INITRD_INTERFACE/
Groupes de contrôle v2
https://docs.kernel.org/admin-guide/cgroup-v2.html
Spécification du répertoire de base XDG
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Il est recommandé que d’autres outils définissent et vérifient $SUDO_UID de manière appropriée, en le traitant comme une interface courante.
Variables d’environnement connues
https://systemd.io/ENVIRONMENT
Identifiants système et de service
https://systemd.io/CREDENTIALS
Page d’accueil de systemd
https://systemd.io/
Document de conception original
https://0pointer.de/blog/projects/systemd.html