SYSTEMD(1) systemd SYSTEMD(1) NOM systemd, init - Gestionnaire de services et de systeme systemd SYNOPSIS /usr/lib/systemd/systemd [OPTIONS...] init [OPTIONS...] {COMMANDE} 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). Pour la compatibilite avec SysV, si le binaire est appele comme init et n'est pas le premier processus de la machine (son PID n'est pas 1), cela executera telinit et passera tous les arguments de la ligne de commande sans modification. Cela signifie que init et telinit sont quasiment equivalents lorsqu'ils sont appeles d'une session de connexion normale. Consulter telinit(8) pour davantage d'informations. 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. CONCEPTS 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 etre << actives >> (c-a-d demarrees, liees, branchees, ... selon le type d'unite, voir ci-dessous), ou << inactives >> (c-a-d stoppees, deliees, debranchees,...), ainsi que dans le processus d'etre activees ou desactivees, c-a-d entre les deux etats (ces etats sont nommes << activation >> et << desactivation >>). Un etat special nomme << echec >> existe aussi, qui est tres similaire a << inactif >> et est entre lorsque le service echoue en quelque maniere (le processus renvoie un code d'erreur a la sortie, ou plante, le delai d'une operation a expire, ou apres d'incessants redemarrages). Si cet etat est entre, la cause sera enregistree dans un journal, pour une reference ulterieure. Prenez en compte que les divers types d'unites peuvent avoir un certain nombre de sous-etats supplementaires qui sont mappes dans les cinq etats generaux d'unites decrits ici. 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-a-d. 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 est compatible avec le systeme init de SysV dans un large degre : les scripts init de SysV sont pris en charge et simplement lus comme une alternative (avec des limites) au format des fichiers de configuration. L'interface /dev/initctl de SysV est fournie et des implementations compatibles des divers outils client SysV sont disponibles. En plus de cela, differentes fonctionnalites Unix implantees comme /etc/fstab ou la base de donnees utmp sont prises en charge. 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-a-d 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. 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/. Pour davantage d'informations sur les concepts et idees derriere systemd, veuillez consulter le Document de conception originel[2]. Notez que certaines, mais pas toutes, interfaces fournies par systemd sont couvertes par la Portabilite d'interface et promesse de stabilite[3]. 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). 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. 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-a-d pour tous les utilisateurs) ou en prive (pour un utilisateur). La liste complete des repertoires est fournie dans systemd.unit(5). Repertoire des scripts init de SysV L'endroit ou est place le repertoire de script init de SysV varie suivant les distributions. Si systemd ne peut pas trouver de fichier d'unite natif pour un service demande, il cherchera un script init de SysV du meme nom (avec le suffixe .service enleve). Repertoire de ferme de liens de niveau d'execution de SysV L'endroit du repertoire de la ferme de liens de niveau d'execution de SysV varie entre les distributions. systemd prendra en compte cette ferme de liens pour savoir si un service doit etre active. Notez qu'une unite service avec un fichier de configuration natif ne peut pas etre demarree en l'activant dans la ferme de lien de niveau d'execution de SysV. 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 tres similaire a systemctl daemon-reexec. Les gestionnaires d'utilisateur de systemd demarreront l'unite exit.target quand le signal est recu. Cela est generalement l'equivalent de 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 generalement 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 generalement 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 generalement 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 generalement equivalent a systemctl daemon-reload. SIGRTMIN+0 Entrer en mode par defaut, demarrer l'unite default.target. Cela est generalement equivalent a systemctl isolate default.target. SIGRTMIN+1 Entrer en mode de secours (rescue), demarrer l'unite rescue.target. Cela est generalement equivalent a systemctl isolate rescue.target. SIGRTMIN+2 Entrer en mode urgence, demarrer l'unite emergency.service. Cela est generalement equivalent a systemctl isolate emergency.service. SIGRTMIN+3 Arreter la machine, demarrer l'unite halt.target. Cela est generalement equivalent a systemctl start halt.target --job-mode=replace-irreversibly. SIGRTMIN+4 Eteindre la machine, demarrer l'unite poweroff.target. Cela est generalement equivalent a systemctl start poweroff.target --job-mode=replace-irreversibly. SIGRTMIN+5 Reamorcer la machine, demarrer le reamorcage des unites reboot.target. Cela est generalement 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 generalement 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 generalement 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. 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. 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 generalement 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 des messages emis (les messages avec un niveau de journalisation plus eleve, c'est-a-dire les moins importants seront supprimes). Soit un de ces niveaux (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 plus d'informations. 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 Afficheur a utiliser lorsque --no-pager n'est pas precise ; outrepasse $PAGER. 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 cette variable 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 (tout comme $PAGER) sera ignore silencieusement. $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. 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). $SYSTEMD_PAGERSECURE Prend un argument booleen. Quand c'est << vrai >>, le mode << secure >> de l'afficheur est active et quand c'est << faux >>, il est desactive. Si $SYSTEMD_PAGERSECURE n'est pas du tout defini, le mode << secure >> est active si l'UID effectif n'est pas le meme que celle du proprietaire de la session connectee, consulter geteuid(2) et sd_pid_get_owner_uid(3). En mode << secure >>, LESSSECURE=1 sera defini lors de l'invocation de l'afficheur, et l'afficheur desactivera les commandes qui ouvrent ou creent de nouveaux fichiers ou lancent de nouveaux sous-processus. Quand $SYSTEMD_PAGERSECURE n'est pas du tout defini, les afficheurs qui ne sont pas reconnus comme implementant le mode << secure >> ne seront pas utilises. (Actuellement seul less(1) implemente le mode << secure >>.) Note : quand des commandes sont invoquees avec des privileges eleves, par exemple avec sudo(8) ou pkexec(1), des precautions doivent etre prises pour s'assurer que des fonctions interactives indesirables ne sont pas activees. Le mode << Secure >> de l'afficheur interactif peut etre active automatiquement comme decrit plus haut. Definir SYSTEMD_PAGERSECURE=0 ou ne pas le supprimer de l'environnement herite autorise l'utilisateur a invoquer des commandes arbitraires. Notez que si les variables $SYSTEMD_PAGER ou $PAGER doivent etre respectees, $SYSTEMD_PAGERSECURE doit aussi etre defini. Il pourrait etre raisonnable de desactiver completement l'afficheur interactif en utilisant plutot --no-pager. $SYSTEMD_COLORS Prend un argument booleen. Quand c'est << vrai >>, systemd et les utilitaires lies utiliseront la couleur pour leurs sorties, autrement, la sortie sera monochrome. En plus, la variable peut prendre une des valeurs speciales suivantes : 16 ou 256 pour limiter l'usage des couleurs aux couleurs ANSI base 16 ou base 256 respectivement. Cela peut etre precise pour outrepasser la decision automatique prise sur $TERM et quel que soit ce a quoi la console est connectee. $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_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 Definition par systemd des notifications d'etat et d'achevement du demarrage pour les processus supervises. Voir sd_notify(3) pour davantage d'information. Pour les variables d'environnement supplementaires comprises par systemd et ses divers composants, consulter Variables d'environnement connues[7]. LIGNE DE COMMANDE DU NOYAU Lorsque lance comme instance systeme, systemd analyse un certain nombre d'options listees ci-dessous. Elles peuvent etre specifiees comme arguments de ligne de commande du noyau qui sont analyses de diverses sources en fonction de l'environnement dans lequel systemd est execute. Si lance dans un conteneur Linux, ces options sont analysees depuis les arguments de la ligne de commande passes a systemd lui-meme, apres n'importe quelle option de ligne de commande listee dans la section OPTIONS ci-dessous. Si lance hors d'un conteneur Linux, ces arguments sont analyses depuis /proc/cmdline et sinon depuis la variable EFI << SystemdOptions >> (pour les systemes EFI). Les options de /proc/cmdline ont une priorite plus haute. Remarque : l'utilisation de << SystemdOptions >> est obsolete. 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, apres un delai de dix secondes. Autrement, aucun interpreteur de commandes n'apparait. Desactive par defaut, pour raisons de securite, car l'interpreteur de commandes n'est protege par aucune authentification par mot de passe. Ajoute dans la version 233. systemd.crash_reboot Prend un argument booleen ou active l'option si specifiee sans aucun argument. Si active, le gestionnaire du systeme (PID 1) reamorcera la machine automatiquement lors d'un plantage, apres un delai de dix secondes. Sinon, le systeme va rester suspendu indefiniment. Desactive par defaut, pour prevenir d'une boucle de reamorcage. Si combinee avec systemd.crash_shell, le systeme est reamorce apres que le shell finisse. Ajoute dans la version 227. 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-a-d 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 m[blue]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 Afficher la sortie du debogage. Cela est equivalent a systemd.log_level=debug. Notez aussi que cette option est aussi lue par le noyau et active la sortie debogage du noyau. Passer cette option demarre donc la sortie du debogage a la fois du gestionnaire du 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. Cela est equivalent a systemd.unit=runlevel2.target, systemd.unit=runlevel3.target, systemd.unit=runlevel4.target et systemd.unit=runlevel5.target respectivement, 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 m[blue]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 datagramme de notification READY=1 lorsque le systeme a fini l'amorcage. Voir sd_notify(3) pour plus d'informations. A noter que dans le cas ou l'hyperviseur ne gere pas SOCK_DGRAM sur AF_VSOCK, SOCK_SEQPACKET sera essaye a la place. La charge utile de l'information d'identification pour AF_VSOCK doit etre de la forme << vsock:CID:PORT >>. Cette fonctionnalite est utile pour les hyperviseurs/VMM ou autres processus de l'hote pour recevoir une notification a travers VSOCK lorsqu'une machine virtuelle a fini son amorcage. 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. 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-reboot Redemarrer automatiquement le systeme en cas de plantage. Cela n'a aucun effet si lance comme instance utilisateur. Voir systemd.crash_reboot ci-dessus. Ajoute dans la version 227. --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. SOCKETS ET FIFOS /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. /dev/initctl Prise en charge limitee de l'interface cliente SysV, comme implementee par l'unite systemd-initctl.service. C'est un tube nomme (pipe) dans le systeme de fichiers. Cette interface est obsolete et ne doit pas etre utilisee pour de nouvelles applications. 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. Ajoute dans la version 252. 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) NOTES 1. Groupes de controle version 2 https://docs.kernel.org/admin-guide/cgroup-v2.html 2. Document de conception originel https://0pointer.de/blog/projects/systemd.html 3. Portabilite d'interface et promesse de stabilite https://systemd.io/PORTABILITY_AND_STABILITY/ 4. Interface conteneur https://systemd.io/CONTAINER_INTERFACE 5. Interface initrd https://systemd.io/INITRD_INTERFACE/ 6. Specification du repertoire de base XDG https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html 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/ 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 255 SYSTEMD(1)