SYSTEMD(1) systemd SYSTEMD(1) NOM systemd, init - Gestionnaire de services et de systeme systemd SYNOPSIS /usr/lib/systemd/systemd [OPTIONS...] init [OPTIONS...] DESCRIPTION systemd est un gestionnaire de services et de systeme pour les systemes d'exploitation Linux. Lance comme premier processus (PID 1) lors de l'amorcage, il agit comme un systeme init qui met en place et entretient les services de l'espace utilisateur. Des instances distinctes sont lancees pour les utilisateurs connectes afin de demarrer leurs services. systemd n'est generalement pas appele directement par l'utilisateur, mais est installe comme lien symbolique /sbin/init et demarre au tout debut de l'amorcage du systeme. Les instances du gestionnaire d'utilisateurs sont demarrees automatiquement avec le service user@.service(5). Lorsqu'il est execute en tant qu'instance du systeme, systemd interprete le fichier de configuration system.conf et les fichiers des repertoires system.conf.d. Lorsqu'utilise comme instance utilisateur, systemd interprete le fichier de configuration user.conf et les fichiers dans les repertoires user.conf.d. Consulter systemd-system.conf(5) pour plus d'informations. systemd contient des implementations natives de differentes taches qui doivent etre executees lors du processus d'amorcage. Par exemple, il definit le nom d'hote ou configure le peripherique loopback de reseau. Il definit aussi et monte divers systemes de fichier d'API, tels que /sys/ ou /proc/ et /dev/. systemd reinitialisera aussi l'horloge systeme au tout debut de l'amorcage si elle parait etre reglee de facon incorrecte. Voir la section << Epoch de l'horloge systeme >> ci-dessous. Notez que certaines, mais pas toutes, interfaces fournies par systemd sont couvertes par la Portabilite d'interface et promesse de stabilite[1]. L'API D-Bus de systemd est decrite dans org.freedesktop.systemd1(5) et org.freedesktop.LogControl1(5). Les systemes qui invoquent systemd dans un conteneur ou un environnement initrd devraient implementer les specifications Interface conteneur[4] ou Interface initrd[5], respectivement. UNITES systemd offre un systeme de dependances entre diverses entites appelees << unites >> de onze types differents. Les unites encapsulent divers objets utiles a l'amorcage du systeme et a son entretien. La majorite des unites sont configurees dans des fichiers de configuration d'unite dont la syntaxe et l'ensemble basique des options sont decrits dans systemd.unit(5), neanmoins d'autres sont creees automatiquement a partir d'autres fichiers de configuration, dynamiquement depuis l'etat du systeme ou de maniere programmable au moment de l'execution. Les unites peuvent avoir differents etats decrits dans la table ci-dessous. Prenez en compte que les divers types d'unites peuvent avoir un certain nombre de sous-etats supplementaires qui sont mappes dans les etats generaux d'unites decrits ici. Table 1. etats d'ACTIVITE des unites +-------------+----------------------------+ |Etat | Description | +-------------+----------------------------+ |active | Demarree, liee, | | | branchee,..., suivant le | | | type d'unite. | +-------------+----------------------------+ |inactive | Stoppee, non liee, | | | debranchee,..., suivant le | | | type d'unite. | +-------------+----------------------------+ |failed | Similaire a inactive, mais | | | l'unite a echoue quelque | | | part (processus renvoyant | | | un code d'erreur, | | | plantage, operation | | | expiree ou apres trop de | | | redemarrages). | +-------------+----------------------------+ |activating | Modification d'inactive en | | | active. | +-------------+----------------------------+ |deactivating | Modification d'active en | | | inactive. | +-------------+----------------------------+ |maintenance | L'unite est inactive et | | | une operation d'entretien | | | est en cours. | +-------------+----------------------------+ |reloading | L'unite est active et est | | | en cours de recharge de | | | configuration. | +-------------+----------------------------+ |refreshing | L'unite est active et un | | | nouveau montage a ete | | | active dans son espace de | | | noms. | +-------------+----------------------------+ Les types d'unite suivants sont disponibles : 1. Les unites service, qui demarrent et controlent les demons et les processus qui les composent. Pour plus d'informations, consulter systemd.service(5). 2. Les unites socket, qui encapsulent les IPC (inter-process communication) locaux ou les sockets reseau du systeme, pratiques pour l'activation basee socket. Pour d'avantage de details sur les unites socket, voir systemd.socket(5), pour des details sur l'activation basee socket et d'autres formes d'activation, voir daemon(7). 3. Les unites cible sont utiles pour les unites groupe ou pour fournir des points de synchronisation bien connus durant l'amorcage, consulter systemd.target(5). 4. Les unites peripherique exposent les peripheriques du noyau dans systemd et devraient etre utilisees pour implementer l'activation basee peripherique. Pour plus de details, consulter systemd.device(5). 5. Les unites montage controlent les points de montage dans le systeme de fichiers, pour les details voir systemd.mount(5). 6. Les unites automontage fournissent des capacites d'automontage, pour les montages a la demande de systemes de fichiers ainsi que pour l'amorcage en parallele. Consulter systemd.automount(5). 7. Les unites timer sont utiles pour declencher l'activation d'autres unites basees sur les temporisateurs. Vous devriez trouver des details dans systemd.timer(5). 8. Les unites swap sont semblables aux unites de montage et encapsulent les partitions ou les fichiers de memoire d'echange du systeme d'exploitation. Elles sont decrites dans systemd.swap(5). 9. Les unites path devraient etre utilisees pour activer d'autres services lorsque les objets du systeme de fichiers changent ou sont modifies. Consulter systemd.path(5). 10. Les unites slice devraient etre utilisees pour grouper les unites qui gerent le fonctionnement du systeme (comme les unites service et scope) dans un arbre hierarchique pour des besoins de gestion de ressources. Consulter systemd.slice(5). 11. Les unites scope sont identiques aux unites service, mais gerent les processus exterieurs au lieu de les demarrer egalement. Voir systemd.scope(5). Les unites sont nommees en fonction de leurs fichiers de configuration. Quelques unites ont une semantique speciale. Consulter systemd.special(7) pour une liste detaillee. systemd reconnait differentes sortes de dependances, incluant les dependances positives ou negatives d'exigence (c.a-d. Requires= et Conflicts=) tout comme les dependances ordonnees (After= et Before=). Remarquez que l'ordre et la requete de dependances sont independants. Si seulement une demande de dependance existe entre deux unites (par exemple, truc.service demande machin.service), mais sans dependance ordonnee (truc.service apres machin.service) et que les deux doivent demarrer, alors elles seront demarrees en parallele. C'est un modele courant que des dependances ordonnees et de requetes soient placees entre deux unites. Tenez compte aussi, que la majorite des dependances sont implicitement creees et entretenues par systemd. Dans la plupart des cas, il n'est pas necessaire de declarer de dependances supplementaires manuellement, toutefois cela reste possible a faire. Les programmes d'application et les unites (a travers les dependances) peuvent necessiter des changements d'etat d'unites. Dans systemd ces requetes sont encapsulees comme << jobs >>, et entretenues dans une file de taches. Les taches (jobs) peuvent reussir ou echouer, leur execution est commandee selon l'ordonnancement des dependances des unites pour lesquelles elles ont ete planifiees. A l'amorcage systemd active l'unite target default.target dont la tache est d'activer les services a l'amorcage et autres unites a l'amorcage en les requerant a travers des dependances. Habituellement, le nom d'unite est juste un alias (lien symbolique) pour soit graphical.target (pour un amorcage des plus complets dans l'interface utilisateur) ou multi-user.target (pour des amorcages uniquement en console, pour une utilisation dans des environnements embarques ou de serveurs, ou similaires ; un sous-ensemble de graphical.target). Cependant, cela reste a la discretion de l'administrateur de le configurer comme un alias pour toute autre unite target. Voir systemd.special(7) pour plus de details sur les unites target. Lors du premier amorcage, systemd activera ou desactivera les unites selon une politique preetablie. Voir systemd.preset(5) et << First Boot Semantics >> dans machine-id(5). systemd ne conserve qu'un ensemble minimal d'unites chargees en memoire. Specifiquement, les seules unites chargees en memoire sont celles pour lesquelles au moins l'une de ces conditions est vraie : 1. Elle est dans un etat actif, activation, desactivation ou en echec (c'est-a-dire tout etat d'unite excepte << inactif >>) 2. Elle possede une file de taches pour ca 3. Elle est une dependance pour au moins une autre unite chargee en memoire 4. Elle dispose d'une certaine forme de ressource encore allouee (p.ex une unite service qui est inactive mais pour laquelle un processus perdure qui a ignore la demande d'arret). 5. Elle a ete attachee en memoire par programmation avec un appel a D-Bus systemd chargera automatiquement et implicitement les unites du disque (si elles ne sont pas deja chargees) des qu'elles seront demandees par les operations en cours. Cependant, sous bien des aspects, le fait qu'une unite soit chargee ou pas reste invisible aux clients. Utilisez systemctl list-units --all pour lister de maniere comprehensible toutes les unites actuellement chargees. Toute unite pour laquelle aucune des conditions ci-dessus ne s'applique est des que possible dechargee. Remarquez que lorsqu'une unite est dechargee de la memoire, ses donnees comptables sont videes aussi. De toute maniere, ces donnees ne sont generalement pas perdues, vu qu'un enregistrement de journal est genere declarant les ressources consommees chaque fois qu'une unite s'eteint. Les processus crees par systemd sont places dans des groupes de controle Linux individuels nommes d'apres l'unite a laquelle ils appartiennent dans la hierarchie privee de systemd.(voir Groupes de controle v2[1] pour plus d'informations sur les groupes de controle ou << cgroups >>). systemd utilise cela pour garder une trace effective des processus. L'information du groupe de controle est entretenue dans le noyau, et est accessible a l'aide de la hierarchie du systeme de fichiers (sous /sys/fs/cgroup/), ou des outils comme systemd-cgls(1) ou ps(1) (ps xawf -eo pid,user,cgroup,args est particulierement utile pour lister tous les processus et les unites systemd auxquelles ils appartiennent). systemd is compatible with various established Unix functionality such as /etc/fstab or the utmp database. systemd a un systeme de transactions minimal : si une unite a besoin de demarrer ou de s'eteindre, il l'ajoutera ainsi que ses dependances dans une transaction temporaire. Alors, il verifiera la coherence de la transaction (c'est-a-dire si l'ordre de toutes les unites est sans cycle). Sinon, systemd essaiera de la reparer, et supprimera les taches non essentielles de la transaction qui pourraient supprimer la boucle. Aussi, systemd essaie de supprimer les taches dans la transaction qui pourraient stopper un service en fonctionnement. Finalement, il verifie si les taches de la transaction rentrent en contradiction avec d'autres taches deja dans la liste d'attente, et facultativement la transaction est annulee. Si tout va bien et que la transaction est coherente et minime dans son impact, elle est integree aux autres taches en attente et ajoutee a la liste d'execution. Dans les faits, cela signifie qu'avant d'executer une operation demandee systemd verifiera que cela a du sens, la reparera si possible, et n'echouera que si vraiment cela ne peut pas fonctionner. Remarquez que les transactions sont generees independamment de l'etat de l'unite au moment du fonctionnement, ainsi, par exemple, si une tache de demarrage est demandee sur une unite deja demarree, elle generera toujours une transaction et reveillera toutes les dependances inactives (et provoquera la propagation d'autres taches conformement aux relations definies). En effet, la tache mise en file d'attente est comparee, au moment de l'execution, a l'etat de l'unite cible et est consideree comme reussie et terminee lorsque les deux exigences sont satisfaites. Toutefois, cette tache attire egalement d'autres dependances en raison des relations definies et entraine donc, dans notre exemple, des taches de demarrage pour n'importe laquelle de ces unites inactives alors aussi mises en file d'attente. Les unites peuvent etre generees dynamiquement au moment du demarrage et du rechargement du gestionnaire de systeme, par exemple sur la base d'autres fichiers de configuration ou de parametres transmis sur la ligne de commande du noyau. Pour les details, voir systemd.generator(7). REPERTOIRES Repertoires des unites systeme Le gestionnaire de systeme systemd lit a partir de nombreux repertoires la configuration des unites. Les paquets qui desirent installer des fichiers d'unite devraient les placer dans le repertoire renvoye par pkg-config systemd --variable=systemdsystemunitdir. Les autres repertoires verifies sont /usr/local/lib/systemd/system et /usr/lib/systemd/system. La configuration de l'utilisateur a toujours la preseance. pkg-config systemd --variable=systemdsystemconfdir renvoie le chemin du repertoire de la configuration du systeme. Les paquets ne modifieront le contenu de ces repertoires seulement avec les commandes enable et disable de l'outil systemctl(1). La liste de l'ensemble des repertoires est fournie dans systemd.unit(5). Repertoires de l'unite utilisateur Des regles similaires s'appliquent aux repertoires utilisateur de l'unite. La neanmoins, la Specification du repertoire de base XDG[6] est suivie pour trouver les unites. Les applications devraient placer leurs fichiers d'unite dans le repertoire renvoye par pkg-config systemd --variable=systemduserunitdir. La configuration globale est faite dans le repertoire mentionne par pkg-config systemd --variable=systemduserconfdir. Les commandes enable et disable de l'outil systemctl(1) peuvent gerer l'activation ou la desactivation d'unites globalement (c'est-a-dire pour tous les utilisateurs) ou en prive (pour un utilisateur). La liste complete des repertoires est fournie dans systemd.unit(5). SIGNAUX Le service ecoute divers signaux de processus UNIX qui peuvent etre utilises pour demander differentes actions de maniere asynchrone. La gestion du signal est activee tres tot lors du demarrage, avant que tout autre processus ne soit invoque. Neanmoins, un gestionnaire de supervision de conteneur ou similaire qui veut demander ces operations a travers ce mecanisme doit prendre en compte que cette fonctionnalite n'est pas disponible lors de la phase premiere d'initialisation. Un message de notification sd_notify() portant le champ X_SYSTEMD_SIGNALS_LEVEL=2 n'est emis qu'une fois les gestionnaires de signaux actives ; voir ci-dessous. Cela est utilise pour planifier correctement la soumission de ces signaux. SIGTERM A la reception de ce signal, le gestionnaire de systeme systemd serialise son etat, s'execute a nouveau et deserialise a nouveau l'etat sauvegarde. Cela est quasiment equivalent a systemctl daemon-reexec. Les gestionnaires d'utilisateur de systemd demarreront l'unite exit.target quand le signal est recu. Cela est quasiment equivalent a systemctl --user start exit.target --job-mode=replace-irreversibly. SIGINT A la reception de ce signal, le gestionnaire de systeme systemd demarre l'unite ctrl-alt-del.target. Cela est quasiment l'equivalent de systemctl start ctrl-alt-del.target --job-mode=replace=irreversibly. Si ce signal est recu plus de sept fois en deux secondes, un reamorcage (reboot) immediat est declenche. Remarquez que presser Ctrl+Alt+Suppr sur la console declenchera ce signal. Par consequent, si un reamorcage est suspendu, presser Ctrl+Alt+Suppr plus de sept fois en deux secondes est une maniere relativement sure pour declencher un reamorcage immediat. Les gestionnaires d'utilisateur de systemd traitent ce signal de la meme maniere que SIGTERM. SIGWINCH Lorsque ce signal est recu, le gestionnaire de systeme systemd demarrera l'unite kbrequest.target. Cela est quasiment equivalent a systemctl start kbrequest.target. Ce signal est ignore par les gestionnaires d'utilisateur de systemd. SIGPWR Lorsque ce signal est recu, le gestionnaire systemd demarrera l'unite sigpwr.target. C'est quasiment equivalent a systemctl start sigpwr.target. SIGUSR1 Le gestionnaire systemd essaiera de se reconnecter au bus D-Bus a la reception de ce message. SIGUSR2 Lorsque ce signal est recu, le gestionnaire systemd journalisera son etat complet sous une forme humainement lisible. Les donnees journalisees sont les memes que celles affichees par systemd-analyze dump. SIGHUP Rechargement de la configuration complete du demon. Cela est quasiment equivalent a systemctl daemon-reload. SIGRTMIN+0 Entrer en mode par defaut, demarrer l'unite default.target. Cela est quasiment equivalent a systemctl isolate default.target. SIGRTMIN+1 Entrer en mode de secours (rescue), demarrer l'unite rescue.target. Cela est quasiment equivalent a systemctl isolate rescue.target. SIGRTMIN+2 Entrer en mode urgence, demarrer l'unite emergency.service. Cela est quasiment equivalent a systemctl isolate emergency.service. SIGRTMIN+3 Arreter la machine, demarrer l'unite halt.target. Cela est quasiment equivalent a systemctl start halt.target --job-mode=replace-irreversibly. SIGRTMIN+4 Eteindre la machine, demarrer l'unite poweroff.target. Cela est quasiment equivalent a systemctl start poweroff.target --job-mode=replace-irreversibly. SIGRTMIN+5 Reamorcer la machine, demarrer le reamorcage des unites reboot.target. Cela est quasiment equivalent a systemctl start reboot.target --job-mode=replace-irreversibly. SIGRTMIN+6 Reamorcer la machine a l'aide de kexec, demarrer les unites kexec.target. Cela est quasiment equivalent a systemctl start kexec.target --job-mode=replace-irreversibly. SIGRTMIN+7 Reamorcer l'espace utilisateur, demarrer le reamorcage de l'unite soft-reboot.target . Cela est quasiment equivalent a systemctl start soft-reboot.target --job-mode=replace-irreversibly. Ajoute dans la version 254. SIGRTMIN+13 Arreter la machine immediatement. SIGRTMIN+14 Eteindre la machine immediatement. SIGRTMIN+15 Reamorcer immediatement la machine. SIGRTMIN+16 Reamorcer immediatement la machine avec kexec. SIGRTMIN+17 Reamorcer immediatement l'espace utilisateur Ajoute dans la version 254. SIGRTMIN+20 Activer l'affichage des messages d'etat sur la console, comme controle a l'aide de systemd.show_status=1 sur la ligne de commande du noyau. Vous pouvez preferer utiliser SetShowStatus() au lieu de SIGRTMIN+20 pour prevenir les situations de competition. Voir org.freedesktop.systemd1(5). SIGRTMIN+21 Desactiver l'affichage des messages d'etat sur la console, comme controle a l'aide de systemd.show_status=0 sur la ligne de commande du noyau. Vous pouvez preferer utiliser SetShowStatus() au lieu de SIGRTMIN+21 pour prevenir les situations de competition. Voir org.freedesktop.systemd1(5). SIGRTMIN+22 Definir le niveau de journal du gestionnaire de services a << debug >>, d'une maniere equivalente a systemd.log_level=debug sur la ligne de commande du noyau. SIGRTMIN+23 Restaurer le niveau de journalisation a sa valeur configuree. La valeur configuree est derivee de - dans l'ordre de priorite - la valeur specifiee avec systemd.log-level= sur la ligne de commande du noyau, ou la valeur specifiee avec LogLevel= dans le fichier de configuration ou celle interne par defaut de << info >>. Ajoute dans la version 239. SIGRTMIN+24 Sortie immediate du gestionnaire (disponible seulement pour --user instances). Ajoute dans la version 195. SIGRTMIN+25 Des reception de ce message le gestionnaire systemd s'executera a nouveau de lui-meme. C'est quasiment equivalent a systemctl daemon-reexec sauf que cela sera fait de maniere asynchrone. Le gestionnaire systemd traite ce signal de la meme facon que SIGTERM. Ajoute dans la version 250. SIGRTMIN+26 Restaurer la cible journal a sa valeur configuree. La valeur configuree est derivee de - dans l'ordre de priorite - la valeur specifiee avec systemd.log.target= sur la ligne de commande du noyau, ou est la valeur specifiee avec LogTarget= dans le fichier de configuration ou celle interne par defaut. Ajoute dans la version 239. SIGRTMIN+27, SIGRTMIN+28 Definir la cible journal a << console >> pour SIGRTMIN+27 (ou << kmsg >> pour SIGRTMIN+28), d'une maniere equivalente a systemd.log_target=console (ou systemd.log_target=kmsg pour SIGRTMIN+28) sur la ligne de commande du noyau. Ajoute dans la version 239. ENVIRONNEMENT Le bloc d'environnement du gestionnaire de systeme est initialement defini par le noyau. (En particulier, les assignations << cle=valeur >> de la ligne de commande du noyau sont changees en variables d'environnement pour le PID 1). Pour le gestionnaire d'utilisateurs, le gestionnaire systeme definit l'environnement comme decrit dans la section << Environment Variables in Spawned Processes >> (<< Variables d'environnement dans les processus crees >>) de systemd.exec(5). Le reglage DefaultEnvironment= du gestionnaire du systeme s'applique a tous les services, incluant user@.service. Des entrees supplementaires peuvent etre configurees (comme pour tout autre service) avec les reglages Environment= et EnvironmentFile= pour user@.service (voir systemd.exec(5)). De meme, des variables d'environnement peuvent etre definies avec le reglage de ManagerEnvironment= dans systemd-system.conf(5) et systemd-user.conf(5). Quelques variables interpretables par systemd : $SYSTEMD_LOG_LEVEL Le niveau maximal de journalisation de messages emis (messages avec un niveau de journalisation superieur, c'est-a-dire les moins importants seront supprimes). Cette variable prend une liste de valeurs separees par des virgules. Une valeur peut etre (par ordre d'importance decroissante) emerg, alert, crit, err, warning, notice, info, debug ou un entier dans l'intervalle 0...7. Consultez syslog(3) pour davantage d'informations. Chaque valeur peut etre optionnellement prefixee avec console, syslog, kmsg ou journal suivi d'un deux-points (:) pour definir le niveau de journalisation maximal pour la cible specifique de journal (par exemple SYSTEMD_LOG_LEVEL=debug,console:info indique de journaliser au niveau debug excepte pour la journalisation vers la console qui doit s'effectuer au niveau info). Notez que le niveau maximal de journalisation globale est prioritaire sur tout niveau maximal de journalisation par cible. Cela peut-etre ecrase par -log-level=. $SYSTEMD_LOG_COLOR Un booleen. Si la valeur est vrai, les messages ecrits sur le terminal seront colores selon la priorite. Cela peut etre ecrase avec -log-color=. $SYSTEMD_LOG_TIME Un booleen. Si la valeur est vrai, les messages du journal de la console seront prefixes d'un horodatage. Cela peut etre ecrase avec -log-time=. Ajoute dans la version 246. $SYSTEMD_LOG_LOCATION Un booleen. Si la valeur est vrai, les messages seront prefixes par un nom de fichier et du numero de ligne du code source d'ou vient le message. Cela peut etre ecrase avec -log-location=. $SYSTEMD_LOG_TID Un booleen. Si la valeur est vrai, les messages seront prefixes par l'identifiant numerique du thread actuel (TID). Ajoute dans la version 247. $SYSTEMD_LOG_TARGET Destination pour journaliser les messages. Une des destinations parmi console (journaliser dans le terminal attache), console-prefixed (journaliser dans le terminal attache, mais avec des prefixes qui codent le niveau et le << service >> de journalisation, consultez syslog(3)), kmsg (journaliser dans le tampon de journalisation circulaire du noyau), journal (journaliser dans le journal), journal-or-kmsg (journaliser dans le journal s'il est disponible et sinon dans kmsg), auto (determiner automatiquement la cible appropriee de journalisation, c'est la destination par defaut), null (desactive la sortie de journalisation). Cela peut etre ecrase avec -log-target=. $SYSTEMD_LOG_RATELIMIT_KMSG Que ce soit pour le taux de requete kmsg ou pas. Prend un booleen. Par defaut << true >>. Si desactive, systemd ne limitera pas le taux des messages ecrits a kmsg. Ajoute dans la version 254. $XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS Le gestionnaire utilisateur de systemd utilise ces variables en accord avec la XDG Base Directory specification[6] pour sa configuration. $SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH, $SYSTEMD_ENVIRONMENT_GENERATOR_PATH Pour controler ou systemd cherche les fichiers d'unite et les generateurs. Ces variables peuvent contenir une liste de chemins, separes par des deux-points (:). Lorsque definie, si la liste se termine avec un composant vide (<< ...: >>), cette liste est prefixee avec la l'ensemble habituel des chemins. Sinon, la liste indiquee remplace l'ensemble habituel des chemins. $SYSTEMD_PAGER, $PAGER Afficheur a utiliser lorsque --no-pager n'est pas precise. $SYSTEMD_PAGER est utilise s'il est defini ; autrement, $PAGERest utilise. Si ni $SYSTEMD_PAGER, ni $PAGER n'ont de valeur, un ensemble d'afficheurs bien connus sont essayes a tour de role, incluant less(1) et more(1), jusqu'a ce qu'il y en ait un qui soit trouve. Si aucun afficheur n'est trouve, aucun afficheur n'est appele. Definir ces variables d'environnement a une chaine vide ou a << cat >> est equivalent a l'utilisation de --no-pager. Remarque : si $SYSTEMD_PAGERSECURE n'est pas defini, $SYSTEMD_PAGER et $PAGER ne peuvent etre utilises que pour desactiver l'afficheur (avec << cat >> ou << "" >>) et autrement seront ignores. $SYSTEMD_LESS Outrepasser les options passees a less (par defaut << FRSXMK >>). Les utilisateurs voudront peut-etre changer deux options en particulier : K Cette option ordonne a l'afficheur de quitter immediatement lorsque Ctrl+C est entre. Pour permettre a less de gerer Ctrl+C lui-meme le retour a l'invite de commande de l'afficheur, ne pas fournir cette option. Si la valeur de $SYSTEMD_LESS n'inclut pas << K >> et si l'afficheur appele est less, Ctrl+C sera ignore par l'executable et doit etre gere par l'afficheur. X Cette option ordonne a l'afficheur de ne pas envoyer les chaines d'initialisation et de desinitialisation de termcap au terminal. C'est le choix par defaut afin de permettre aux sorties des commandes de rester visibles dans le terminal meme apres que l'afficheur soit ferme. Toutefois, cela empeche quelques fonctionnalites de l'afficheur de fonctionner, en particulier, il n'est pas possible de faire defiler les sorties affichees avec la souris. Notez que le reglage de la variable d'environnement $LESS normale n'a aucun effet sur les invocations de less par les outils de systemd. Voir less(1) pour plus de details. $SYSTEMD_LESSCHARSET Outrepasser le jeu de caracteres passe a less (par defaut << utf-8 >>, si le terminal invoque est compatible avec l'UTF-8). Notez que le reglage de la variable d'environnement $LESSCHARSET normale n'a aucun effet sur les invocations de less par les outils de systemd. $SYSTEMD_PAGERSECURE Les commandes d'afficheur courantes comme less(1), en plus de << l'affichage >>, c'est-a-dire le defilement de la sortie, prennent en charge l'ouverture et l'ecriture d'autres fichiers et l'execution de commandes d'interpreteur arbitraires. Quand les commandes sont invoquees avec des privileges eleves, par exemple sous sudo(8) ou pkexec(1), l'afficheur devient une limite de securite. Il convient de veiller a ce que seuls des programmes avec des fonctionnalites strictement limitees soient utilises comme afficheurs et que les fonctionnalites comme l'ouverture ou la creation de nouveaux fichiers ou le demarrage de sous-processus ne soient pas autorisees. Un << mode securise >> pour l'afficher peut etre active comme decrit ci-dessous, si l'afficheur le prend en charge (la plupart des afficheurs ne sont pas ecrits de facon a prendre cela en consideration). Il est recommande soit d'activer explicitement le << mode securise >> soit de desactiver completement l'afficheur en utilisant --no-pager ou PAGER=cat lorsque des utilisateurs non fiables sont autorises a executer des commandes avec des privileges eleves. Cette option prend un argument booleen. Lorsqu'elle est definie a vrai, le << mode securise >> de l'afficheur est active. En << mode securise >>, LESSSECURE=1 est defini lors de l'invocation de l'afficheur, ce qui lui indique de desactiver les commandes qui ouvrent ou creent des fichiers, ou qui demarrent un nouveau sous-processus. Actuellement, seul less(5) est connu pour comprendre cette variable et implementer le << mode securise >>. Quand l'option est definie a faux, aucune limitation n'est imposee a l'afficheur. Definir SYSTEMD_PAGERSECURE=0 ou ne pas le supprimer de l'environnement herite peut permettre a l'utilisateur d'invoquer des commandes arbitraires. Quand $SYSTEMD_PAGERSECURE n'est pas defini, les outils de systemd tentent de determiner automatiquement si le << mode securise >> doit etre active et si l'afficheur le prend en charge. Le << mode securise >> est active si l'UID effectif est different de celui du proprietaire de la session de connexion (voir geteuid(2)) et sd_pid_get_owner_uid(3)) ou lors de l'execution sous sudo(8) ou des outils similaires ($SUDO_UID est defini a [6]). Dans ces cas, SYSTEMD_PAGERSECURE=1 sera defini et les afficheurs qui ne sont pas connus pour implementer le << mode securise >> ne seront pas du tout utilises. Notez que cette detection automatique ne couvre que les mecanismes les plus courants d'elevation des privileges et qu'elle est concue pour faciliter la tache. Il est recommande de definir explicitement $SYSTEMD_PAGERSECURE ou de desactiver l'afficheur. Notez que si les variables $SYSTEMD_PAGER ou $PAGER doivent etre respectees, sauf pour desactiver l'afficheur, $SYSTEMD_PAGERSECURE doit aussi etre defini. $SYSTEMD_COLORS Takes a boolean argument, or a special value. By default (unset), systemd and related utilities will use colors in their output if possible. If $COLORTERM is set to "truecolor" or "24bit", 24-bit colors will be enabled, 256 colors otherwise, unless $NO_COLOR or $TERM indicates colors are disabled. true Same as unset, except that $NO_COLOR is ignored. false The output will be monochrome. "16", "256", "24bit" Always use the base 16 ANSI colors, 256 colors, or 24 bit color, respectively. "auto-16", "auto-256", "auto-24bit" Use the given quantity of colours, subject to $TERM, and what the console is connected to. $SYSTEMD_URLIFY La valeur doit etre un booleen. Controle si les liens cliquables doivent etre generes dans la sortie pour des emulateurs de terminaux le prenant en charge. Cela peut etre indique pour passer outre la decision faite par systemd basee sur $TERM et d'autres conditions. $LISTEN_PID, $LISTEN_PIDFDID, $LISTEN_FDS, $LISTEN_FDNAMES Definition par systemd des processus supervises lors de l'activation basee socket. Consulter sd_listen_fds(3) pour plus d'informations. $NOTIFY_SOCKET Definie par le gestionnaire de services pour ses services pour les notifications d'etat et de disponibilite. Cette variable est egalement utilisee par le gestionnaire de services pour notifier aux gestionnaires de supervision de conteneurs ou aux gestionnaires de services situes au-dessus de la pile de sa propre progression. Voir sd_notify(3) et la section concernee ci-dessous pour plus d'informations. Pour les variables d'environnement supplementaires comprises par systemd et ses divers composants, consulter Variables d'environnement connues[7]. LIGNE DE COMMANDE DU NOYAU When run as the system instance, systemd parses a number of options listed below. They can be specified as kernel command line arguments which are parsed from a number of sources depending on the environment in which systemd is executed. If run inside a Linux container, these options are parsed from the command line arguments passed to systemd itself, next to any of the command line options listed in the Options section above. If run outside of Linux containers, these arguments are parsed from /proc/cmdline instead. Les variables suivantes sont comprises : systemd.unit=, rd.systemd.unit= Outrepasser l'unite a activer lors de l'amorcage. C'est par defaut default.target. Cela peut etre utilise pour amorcer temporairement avec une unite d'amorcage differente, par exemple rescue.target ou emergency.service. Voir systemd.special(7) pour des details a propos de ces unites. L'option prefixee avec << rd. >> n'est honoree que dans l'initrd, tandis que celle qui n'est pas prefixee n'est honoree que dans le systeme principal. systemd.dump_core Prend un argument booleen ou active l'option si specifiee sans argument. Si active, le gestionnaire de systemd (PID 1) effectue un vidage du noyau lorsqu'il plante. Sinon, aucun vidage du noyau n'est cree. La valeur par defaut est << enabled >> (activee). Ajoute dans la version 233. systemd.crash_chvt Prend un entier positif ou un argument booleen. Peut aussi etre specifie sans argument, avec le meme effet qu'avec un booleen positif. Si un entier positif (dans la plage 1-63) est indique, le gestionnaire du systeme (PID 1) activera le terminal virtuel indique lorsqu'il plante. Par defaut desactive, ce qui signifie que de telles interruptions ne sont pas prevues. Si regle a active, le terminal virtuel sur lequel les messages du noyau sont ecrits est utilise a la place. Ajoute dans la version 233. systemd.crash_shell Prend un argument booleen ou active l'option si indiquee sans aucun argument. Si active, le gestionnaire systeme (PID 1) fait apparaitre un interpreteur de commandes lorsqu'il plante. Autrement, aucun interpreteur de commandes n'apparait. Desactive par defaut, pour raisons de securite, car l'interpreteur de commandes n'est pas protege par une authentification par mot de passe. Ajoute dans la version 233. systemd.crash_action= Prend un des arguments << freeze >>, << reboot >> ou << poweroff >>. Par defaut, c'est << freeze >>. Si regle a << freeze >>, le systeme restera suspendu indefiniment si le gestionnaire de services (PID 1) plante. Si regle sur << reboot >>, le gestionnaire du systeme (PID 1) reamorcera la machine automatiquement lors d'un plantage, apres un delai de dix secondes. Si regle a << poweroff >>, le gestionnaire de services (PID 1) eteindra la machine immediatement apres un plantage. Si combine avec systemd.crash_shell, l'action de plantage configuree est executee apres que l'interpreteur de commandes a quitte. Ajoute dans la version 256. systemd.confirm_spawn Prend un argument booleen ou un chemin vers la console virtuelle ou les messages de confirmation devraient etre envoyes. Peut aussi etre specifie sans aucun argument, avec le meme effet qu'avec un booleen positif. Si active, le gestionnaire du systeme (PID 1) demande confirmation pour faire apparaitre les processus utilisant /dev/console. Si un chemin ou un nom de console (tel que << ttyS0 >>) est fourni, la console virtuelle pointee par ce chemin ou celui decrit par le nom donne sera utilisee a la place. Desactive par defaut. Ajoute dans la version 233. systemd.service_watchdogs= Prend un argument booleen. Si desactive, tous les chiens de garde d'execution de service (WatchdogSet=) et les actions d'urgence (p. ex. OnFailure= ou StartLimitAction=) sont ignores par le gestionnaire du systeme (PID 1) ; consulter systemd.service(5). Active par defaut, c'est-a-dire les chiens de garde et les actions d'echec sont executes normalement. Le chien de garde materiel n'est pas affecte par cette option. Ajoute dans la version 237. systemd.show_status Prend un argument booleen ou les constantes error et auto. Peut aussi etre specifie sans argument, auquel cas, c'est equivalent a l'effet d'un booleen positif. Si active, le gestionnaire du systeme (PID 1) affiche des mises a jour laconiques de l'etat des services sur la console pendant le demarrage. Avec error, seuls les messages d'echec sont affiches, mais sinon l'amorcage est silencieux. auto se comporte comme false jusqu'a ce qu'il y ait un delai significatif dans l'amorcage. Active par defaut, a moins que quiet soit passe comme option sur la ligne de commandes du noyau, dans lequel cas c'est error par defaut. Si specifie, cela ecrase l'option du fichier de configuration ShowStatus= du gestionnaire de systeme, consulter systemd-system.conf(5). Ajoute dans la version 233. systemd.status_unit_format= Prend name, description ou combined comme valeur. Si name, alors le gestionnaire de systeme utilisera les noms d'unite dans les messages d'etat. Si combined, le gestionnaire de systeme utilisera les noms et description d'unite dans les messages d'etat. Lorsque specifie, ecrase l'option StatusUnitFormat= de la configuration du gestionnaire du systeme, voir systemd-system.conf(5). Ajoute 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 Controle la sortie des journaux, avec le meme 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 decrites ci-dessus. systemd.log_color, systemd.log_location, systemd.log_time, systemd.log_tid et systemd.log_ratelimit_kmsg peuvent etre indiquees sans argument, ayant le meme effet qu'un booleen positif. systemd.default_standard_output=, systemd.default_standard_error= Controle la sortie standard par defaut et les sorties d'erreur pour les services et les sockets. C'est-a-dire, controle la sortie par defaut de StandardOutput= et StandError= (consulter systemd.exec(5) pour les details). Prend l'un de inherit, null, tty, journal, journal+console, kmsg, kmsg+console. Si l'argument est omis, systemd.default-standard-output= sera par defaut journal et systemd.default-standard-error= inherit. systemd.setenv= Prendre un argument chaine de la forme VARIABLE=VALEUR. Cela peut etre utilise pour definir des variables d'environnement par defaut a ajouter pour fourcher vers des processus enfant. Peut etre utilise plus d'une fois pour definir plusieurs variables. systemd.machine_id= Prend une valeur hexadecimale de 32 caracteres a utiliser pour definir l'ID de la machine. Destine principalement au demarrage en reseau, lorsque le meme identifiant de machine est souhaite pour chaque demarrage. Ajoute dans la version 229. systemd.set_credential=, systemd.set_credential_binary= Definit un justificatif d'identite du systeme, qui peut alors etre propage aux services du systeme en utilisant le reglage ImportCredential= ou LoadCredential=, consulter systemd.exec(5) pour plus de details. Prend une paire de justificatifs de nom et valeur, separes par un deux-points (:). Prenez en compte que la ligne de commande du noyau est habituellement accessible par les programmes non privilegies dans /proc/cmdline. Cela etant, un tel mecanisme n'est pas apte a transferer des donnees sensibles. A n'utiliser qu'avec des donnees non sensibles telles que cles publiques ou certificats, pas avec les cles privees, ni dans un environnement de test ou de debogage. Pour plus d'informations, consulter la documentation Identifiants du systeme et des services[8]. Ajoute dans la version 251. systemd.import_credentials= Prend un argument booleen. Si faux, desactive l'importation d'informations d'identification a partir de la ligne de commande du noyau, de la table des chaines OEM DMI/SMBIOS, du sous-systeme qemu_fw_cfg ou de la partie EFI du noyau. Ajoute dans la version 251. quiet Desactiver la sortie d'etat a l'amorcage, comme ferait systemd&.show_status=no. Remarque, cette option est aussi lue par le noyau lui-meme et desactive la sortie journal du noyau. Passer cette option desactive donc les sorties habituelles du gestionnaire de systeme et du noyau. Ajoute dans la version 186. debug Desactiver la sortie d'etat a l'amorcage, comme ferait systemd&.show_status=no. Remarque, cette option est aussi lue par le noyau lui-meme et desactive la sortie journal du noyau. Passer cette option desactive donc les sorties habituelles du gestionnaire de systeme et du noyau. Ajoute dans la version 205. emergency, rd.emergency, -b Demarrer en mode urgence. C'est l'equivalent de systemd.unit=emergency.target ou rd.systemd.unit=emergency.target respectivement, et est fourni pour des besoins de compatibilite et pour etre plus simples a taper. Ajoute dans la version 186. rescue, rd.rescue, single, s, S, 1 Demarrer en mode sauvetage (rescue). C'est l'equivalent de systemd.unit=rescue.target ou rd.systemd.unit=rescue.target respectivement, et est fourni pour des raisons de compatibilite et etre plus simple a saisir. Ajoute dans la version 186. 2, 3, 4, 5 Amorcer en niveau d'execution patrimonial (legacy) specifie de SysV. 2, 3 et 4 sont equivalents a systemd.unit=multi-user.target ; 5 est equivalent a systemd.unit=graphical.target et est fourni pour raison de compatibilite et de simplification de saisie. Ajoute 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= Definir les parametre regionaux du systeme a utiliser. Cela ecrase les reglages dans /etc/locale.conf. Pour plus d'informations, consultez locale.conf(5) et locale(7). Ajoute dans la version 186. Pour les autres parametres de la ligne de commande du noyau compris par les composants du coeur du systeme d'exploitation, veuillez vous referer a kernel-command-line(7). INFORMATIONS D'IDENTIFICATION DU SYSTEME Durant l'initialisation, le gestionnaire de services importera des justificatifs depuis diverses sources dans les informations d'identification du systeme, qui alors pourront etre propages dans les services et consommes par les generateurs : o Lorsque le gestionnaire de services s'initialisera, il lira les informations d'identification depuis les chaines du vendeur Type 11 SMBIOS io.systemd.credential:nom=valeur, et io.systemd.credential.binary:nom=valeur. o Au meme moment, il importera les informations d'identification depuis QEMU << fw_cfg >>. (A noter que le mecanisme SMBIOS est habituellement prefere, car il est plus rapide et generique.) o Les informations d'identification doivent etre passees au noyau a l'aide de la ligne de commande en utilisant le parametre systemd.set-credential=, voir ci-dessus. o Les informations d'identification doivent etre passees de l'environnement UEFI avec systemd-stub(7). o Lorsque le gestionnaire de services est invoque durant l'initrd lors de la transition de l'hote, tous les fichiers dans /run/credentials/@initrd/ seront importes comme informations d'identification du systeme. Invoquer systemd-creds(1) comme il suit pour visualiser la liste d'informations d'identification passees au systeme : # systemd-creds --system list Pour plus d'informations, consulter la documentation Identifiants du systeme et des services[8]. Le gestionnaire de services consomme les informations d'identification suivantes du systeme lorsque lance en tant que PID 1 : vmm.notify_socket Contient une adresse AF_VSOCK ou AF_UNIX ou envoyer un message de notification READY=1 lorsque le systeme a completement demarre. Voir sd_notify(3) et la section suivante pour plus d'informations. A noter que dans le cas ou l'hyperviseur ne gere pas SOCK_DGRAM pour AF_VSOCK, SOCK_SEQPACKET sera essaye a la place. La charge utile de l'information d'identification pour AF_VSOCK doit etre une chaine de la forme << vsock:CID:PORT >>. << vstock-stream >>, << vstock-dgram >> et << vsock-seqpacket >> peuvent etre utilises a la place de << vstock >> pour forcer l'utilisation du type de socket correspondant. Cette fonctionnalite est utile pour les gestionnaires de machine ou d'autres processus de l'hote pour recevoir une notification a travers VSOCK lorsqu'une machine virtuelle a fini son demarrage. Ajoute dans la version 254. system.machine_id Prend une ID hexadecimale de 128 octets pour y initialiser /etc/machine-id, si le fichier n'est pas encore pret. Voir machine-id(5) pour les details. Ajoute dans la version 254. Pour une liste des identifiants du systeme que divers autres composants de systemd utilisent, voir systemd.system-credentials(7). PROTOCOLE DE DISPONIBILITE Le gestionnaire de services implemente un protocole de notification de disponibilite entre le gestionnaire et ses services (c'est-a-dire en bas de la pile) et entre le gestionnaire et un eventuel superviseur plus en haut de la pile (ce denier pouvant etre une machine ou un gestionnaire de conteneur, ou, dans le cas d'un gestionnaire de services par utilisateur, l'instance du gestionnaire de services du systeme). Le protocole elementaire, et l'API suggeree pour le faire, sont decrits dans sd_notify(3). Le socket de notification que le gestionnaire de services (incluant PID 1) utilise pour annoncer la disponibilite a son propre superviseur est defini a travers la variable d'environnement habituelle $NOTIFY_SOCKET (voir ci-dessus). Cela n'etant directement definissable que pour les gestionnaires de conteneur et pour l'instance par utilisateur du gestionnaire de services, un mecanisme supplementaire pour le configurer est disponible, destine particulierement a une utilisation dans un environnement de machine virtuelle : l'identifiant du systeme vmm.notify_socket (voir ci-dessus) peut etre regle a un socket adapte (generalement un de AF_VSOCK) a l'aide de chaines SMBIOS Type 11 de fournisseur. Pour les details voir ci-dessus. Le protocole de notification du gestionnaire de services au sommet de la pile pour un superviseur prend en charge un certain nombre de champs d'extension qui permettent au superviseur de connaitre les proprietes specifiques du systeme et de suivre la progression de son demarrage. En particulier, les champs suivants sont envoyes : o Un message X_SYSTEMD_HOSTNAME=... sera envoye une fois que le nom d'hote initial pour le systeme aura ete determine. Notez que dans les derniers instants de l'execution, le nom d'hote peut etre change de maniere programmatique, et (actuellement) aucune notification supplementaire n'est envoyee dans ce cas. Ajoute dans la version 256. o Un message X_SYSTEMD_MACHINE_ID=... sera envoye une fois que l'identifiant machine du systeme aura ete determine. Voir machine-id(5) pour les details. Ajoute dans la version 256. o Un message X_SYSTEMD_SIGNALS_LEVEL=... sera envoye lorsque le gestionnaire de services aura installe les divers gestionnaires de signaux des processus UNIX decrits ci-dessus. La valeur du champ est un entier non signe formate en chaine decimale, et indique le niveau de fonctionnalite pris en charge des signaux de processus UNIX du gestionnaire de services. Actuellement, un seul niveau de caracteristique est defini : o X_SYSTEMD_SIGNALS_LEVEL=2 couvre les divers signaux de processus UNIX documentes ci-dessus qui sont un sur-ensemble de ceux pris en charge par le systeme historique init de SysV. Les signaux envoyes au PID 1 avant que ce message ne soit envoye peuvent ne pas avoir ete correctement geres pour le moment. Un consommateur de ces messages devra analyser la valeur comme une indication d'entier non signe du niveau de prise en charge. Actuellement, seul le niveau 2 mentionne est defini, mais prochainement d'autres niveaux devraient etre definis avec des entiers superieurs, ce qui implementera un sur-ensemble du comportement actuellement defini. Ajoute dans la version 256. o Des messages X_SYSTEMD_UNIT_ACTIVE=... et X_SYSTEMD_UNIT_INACTIVE=... seront envoyes pour chaque unite cible qui devient active ou cesse d'etre active. Cela est utile pour suivre la progression du demarrage et la fonctionnalite. Par exemple, des que l'unite ssh-access.target est declaree demarree, un acces SSH est typiquement disponible, voir systemd.special(7) pour les details. Ajoute dans la version 256. o Un message X_SYSTEMD_SHUTDOWN=... sera envoye juste avant que le systeme ne s'eteigne. La valeur est l'une des chaines << reboot >>, << halt >>, << poweroff >>, << kexec >>, et indique quelle sorte d'extinction est executee. Ajoute dans la version 256. o Un message X_SYSTEMD_REBOOT_PARAMETER=... sera aussi envoye juste avant que le systeme ne s'eteigne. Sa valeur est l'argument de redemarrage comme configure avec systemctl --reboot-argument=.... Ajoute dans la version 256. Notez que ces champs d'extension sont envoyes en plus des notifications habituelles << READY=1 >> et << RELOADING=1 >>. OPTIONS systemd n'est que rarement appele directement, etant donne qu'il est lance tot et qu'il est deja en cours d'execution au moment ou les utilisateurs peuvent interagir avec lui. Normalement, des outils tels que systemctl(1) sont utilises pour passer les commandes au gestionnaire. Comme systemd n'est generalement pas appele directement, les options listees ci-dessous sont surtout utiles a des fins de debogage ou pour des buts specifiques. Options d'introspection et de debogage Ces options sont utilisees pour les tests et l'introspection, et systemd peut etre invoque avec elles a tout moment : --dump-configuration-items Vider les elements geres de configuration de l'unite. Il en resulte une liste laconique mais complete des elements de configuration geres dans les fichiers de definition des unites. --dump-bus-properties Vidage des proprietes exposees du bus. Cela produit une liste laconique mais complete des proprietes exposees sur le D-Bus. Ajoute dans la version 239. --test Determiner la transaction initiale de demarrage (c'est-a-dire la liste des taches mises en file d'attente lors du demarrage), la vider et terminer -- sans executer reellement aucun des taches determinees. Cette option n'est utile que pour le debogage. Notez que durant le demarrage usuel du gestionnaire de service, des unites additionnelles, non visibles avec cette operation, peuvent etre demarrees parce qu'un materiel, un socket, un bus ou un autre types d'activation pourraient ajoutees de nouvelles taches lors de l'execution de la transaction. Utilisez --system pour demander la transaction initiale du gestionnaire de service systeme (c'est aussi la valeur implicite par defaut), combinez avec --user pour demander la transaction initiale du gestionnaire de service par utilisateur a la place. --system, --user Lorsqu'utilise avec --test, selectionne s'il faut calculer la transaction initiale pour l'instance du systeme ou pour une instance par utilisateur. Ces options sont sans effet si elles sont appelees sans --test, comme durant d'usuels appels (c'est-a-dire sans --test) le gestionnaire de services detectera automatiquement s'il doit agir dans le mode systeme ou celui utilisateur, en verifiant si le PID du processus lance est 1 ou pas. Notez qu'il n'est pas pris en charge l'amorcage et la maintenance d'un systeme avec le gestionnaire de services lance en mode --system mais avec un PID autre que 1. -h, --help Afficher un aide-memoire succinct et quitter. --version Afficher une information de version courte et quitter. Options pour dupliquer en ligne de commande les reglages du noyau Ces options correspondent exactement aux options listees ci-dessus dans << Ligne de commande du noyau >>. Les deux formes peuvent etre utilisees de maniere equivalente pour le gestionnaire du systeme, mais il est recommande d'utiliser les formes citees ci-dessus dans ce contexte, car elles sont proprement placees dans le bon espace de noms. Lorsqu'une option est indiquee a la fois sur la ligne de commande du noyau et comme argument de la ligne de commande, la derniere a la precedence. Lorsque systemd est utilise comme gestionnaire utilisateur, la ligne de commandes du noyau est ignoree et seules les options decrites ci-dessous sont gerees. Neanmoins, systemd est generalement demarre dans ce mode, a travers le service user@service(5), qui est partage entre tous les utilisateurs. Il est plus aise d'utiliser les fichiers de configuration pour modifier les reglages (voir systemd-user.conf(5)) ou les variables d'environnement. Consulter la section << Environnement >> ci-dessus pour des explications sur comment est defini le bloc environnement. --unit= Definir une unite par defaut a activer au demarrage. Si cela n'est pas indique, c'est par defaut default.target. Voir systemd.unit= ci-dessus. --dump-core Activer le vidage du coeur en cas de plantage. Cela n'a aucun effet lorsqu'utilise sous une instance utilisateur. Pareil a systemd.dump_core= ci-dessus. --crash-vt=VT Basculer dans une console virtuelle (VT) definie en cas de plantage. Ce changement n'a aucun effet lorsque lance depuis une instance utilisateur. Comme systemd.crash_chvt= ci-dessus (mais pas l'orthographe differente !). Ajoute dans la version 227. --crash-shell Lancer un interpreteur de commandes lors d'un plantage. Cela n'a aucun effet si lance depuis une instance utilisateur. Voir systemd.crash_shell= ci-dessus. --crash-action= Indiquer quoi faire en cas de plantage du gestionnaire du systeme (PID 1). Cela n'a aucun effet si systemd est lance comme instance utilisateur. Voir systemd.crash_action= ci-dessus. Ajoute dans la version 256. --confirm-spawn Demander confirmation lors de la creation de processus. Cela n'a aucun effet lance en instance utilisateur. Voir systemd.confirm_spawn ci-dessus. --show-status Afficher des informations laconiques sur l'etat de l'unite sur la console lors du demarrage et de l'arret de l'unite. Voir systemd.show_status ci-dessus. Ajoute dans la version 244. --log-color Mettre en surbrillance les messages journal importants. Voir systemd.log_color ci-dessus. Ajoute dans la version 244. --log-level= Definir le niveau de journalisation. Voir systemd.log_level ci-dessus. --log-location Inclure l'emplacement du code dans les messages journal. Voir systemd.log_location ci-dessus. Ajoute dans la version 244. --log-target= Definir la cible du journal. Voir systemd.log_target ci-dessus. --log-time= Prefixer les messages de la console avec un horodatage. Voir systemd.log_time ci-dessus. Ajoute dans la version 246. --machine-id= Ecraser l'identifiant de la machine defini sur le disque dur. Voir systemd.machine_id= ci-dessus. Ajoute dans la version 229. --service-watchdogs Activer ou desactiver de facon globale toutes les actions urgentes ou minutees du service chien de garde. Voir systemd.service_watchdogs ci-dessus. Ajoute dans la version 237. --default-standard-output=, --default-standard-error= Definition de la sortie par defaut ou la sortie d'erreur pour tous les services et les sockets respectivement. Voir systemd.default_standard_output= et systemd.default_standard_error= ci-dessus. EPOCH DE L'HORLOGE SYSTEME Lorsque systemd est demarre ou redemarre, il se peut qu'il regle l'horloge systeme a l'<< epoch >>. Ce mecanisme est utilise pour s'assurer que l'horloge systeme reste raisonnablement initialisee et de facon a peu pres monotone lors des divers demarrages, dans le cas ou aucune horloge en temps reel (RTC) locale avec batterie de secours n'est disponible ou si elle ne fonctionne pas correctement. L'epoch est la date la plus ancienne a partir de laquelle le systeme est presume etre correctement regle. Lors de l'initialisation, l'horloge locale est avancee vers l'epoch si elle etait reglee a une valeur trop ancienne. Un cas particulier : si l'horloge locale est suffisamment eloignee dans le futur (par defaut 15 ans, mais cela peut etre configure lors de la construction), l'horloge materielle est presumee cassee et l'horloge systeme est ramenee a l'epoch. L'epoch est reglee a la valeur la plus recente des dates suivantes : le moment de construction de systemd, la date de modification (<< mtime >>) de /usr/lib/clock-epoch ou la date de modification de /var/lib/systemd/timesync/clock. FICHIERS /run/systemd/notify Socket de notification de l'etat du demon. C'est un socket datagramme AF_UNIX qui est utilise pour implementer la logique de notification du demon comme implemente par sd_notify(3). /run/systemd/private Utilise en interne comme canal de communication entre systemctl(1) et le processus systemd. C'est un socket flux AF_UNIX. Cette interface est personnelle a systemd et ne devrait pas etre utilisee pour des projets exterieurs. /usr/lib/clock-epoch La date de modification (<< mtime >>) de ce fichier est utilisee pour l'heure de l'epoch, voir la section precedente. Ajoute dans la version 247. /var/lib/systemd/timesync/clock La date de modification (<< mtime >>) de ce fichier est mise a jour par systemd-timesyncd.service(8). Si presente, la date de modification du fichier est utilisee pour l'epoch, voir la section precedente. Ajoute dans la version 257. HISTORIQUE systemd 252 Les arguments de la ligne de commandes du noyau systemd.unified_cgroup_hierarchy et systemd.legacy_systemd_cgroup_controller sont consideres obsoletes. Veuillez changer pour une hierarchie cgroups unifiee. VOIR AUSSI La page d'accueil de systemd[9], systemd-system.conf(5), locale.conf(5), systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-daemon(3), org.freedesktop.systemd1(5), systemd.unit(5), systemd.special(7), pkg-config(1), kernel-command-line(7), bootup(7), systemd.directives(7), org.freedesktop.systemd1(5) Pour davantage d'informations sur les concepts et idees derriere systemd, veuillez consulter le Document de conception originel[10]. NOTES 1. Portabilite d'interface et promesse de stabilite https://systemd.io/PORTABILITY_AND_STABILITY/ 2. Interface conteneur https://systemd.io/CONTAINER_INTERFACE 3. Interface initrd https://systemd.io/INITRD_INTERFACE/ 4. Groupes de controle version 2 https://docs.kernel.org/admin-guide/cgroup-v2.html 5. Specification du repertoire de base XDG https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html 6. Il est recommande pour les autres outils de definir et verifier $SUDO_UID comme il convient, en le considerant comme une interface courante. 7. Variables d'environnement connues https://systemd.io/ENVIRONMENT 8. Identifiants du systeme et des services https://systemd.io/CREDENTIALS 9. Page d'accueil de systemd https://systemd.io/ 10. Document de conception originel https://0pointer.de/blog/projects/systemd.html TRADUCTION La traduction francaise de cette page de manuel a ete creee par bubu Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . systemd 260.2 SYSTEMD(1)