SYSTEMD-NOTIFY(1) systemd-notify SYSTEMD-NOTIFY(1) NOM systemd-notify - Gestionnaire de service de notifications sur le deroulement de l'amorcage et d'autres modifications d'etat de demon SYNOPSIS systemd-notify [OPTIONS...] [VARIABLE=VALEUR...] systemd-notify --exec [OPTIONS...] [VARIABLE=VALUE...] ; -- {LIGNE_COMMANDE...} systemd-notify --fork [OPTIONS...] -- {LIGNE_COMMANDE...} DESCRIPTION systemd-notify peut etre appele par des scripts de service pour notifier le gestionnaire de service appelant de modifications d'etat. Il peut etre utilise pour envoyer des informations arbitraires, encodees dans une liste de chaines de type bloc d'environnement. Plus important, il peut etre utilise pour des notifications de l'avancement de l'amorcage. C'est en grande partie une enveloppe de sd_notify() et procure cette fonctionnalite aux scripts d'interpreteur de commandes. Pour plus de details, consulter sd_notify(3). La ligne de commande peut comporter une liste de variables d'environnement a envoyer comme composante de la mise a jour d'etats. Notez que systemd refuse la reception de mises a jour de cette commande a moins que NotifyAccess= ne soit regle de facon appropriee pour l'unite de service a partir de laquelle la commande est appelee. Consulter systemd.service(5) pour plus de details. Notez que les notifications sd_notify() ne peuvent etre attribuees correctement aux unites que si le processus emetteur est toujours present au moment ou le gestionnaire de service traite le message ou si le processus emetteur fait explicitement l'objet d'un suivi d'execution par le gestionnaire de service. Ce dernier cas est celui ou le gestionnaire de service fourche initialement le processus, c'est-a-dire pour tous les processus qui correspondent a NotifyAccess=main ou NotifyAccess=exec. Inversement, si un programme auxiliaire de l'unite envoie un message sd_notify() et quitte immediatement, le gestionnaire de service peut ne pas pouvoir attribuer correctement le message a l'unite et, par consequent, l'ignorer meme si NotifyAccess=all est regle pour elle. Pour corriger cela, systemd-notify attend jusqu'a ce que le message de notification soit traite par le gestionnaire de service. Lorsque l'option --no-block est utilisee, cette synchronisation pour la reception de notification est desactivee, et ainsi la situation de competition susmentionnee peut se produire si le processus appelant n'est pas le gestionnaire de service ou n'est pas engendre par le gestionnaire de service. systemd-notify essaie d'abord d'invoquer sd_notify() en pretendant detenir le PID du processus parent de systemd-notify (c'est-a-dire le processus appelant). Cela ne fonctionne que si cela est invoque avec les privileges suffisants. En cas d'echec, il se rabat sur une invocation sous son propre PID. Ce comportement est utile afin que, lorsque l'outil est invoque par un script d'interpreteur de commandes, ce processus d'interpreteur -- et pas le processus systemd-notify -- apparaisse comme l'emetteur du message, ce qui est ensuite utile si le processus d'interpreteur est le processus principal d'un service, a cause des limitations de NotifyAccess=all. Utilisez le commutateur --pid= pour ajuster ce comportement. OPTIONS Les options suivantes sont comprises : --ready Informer le gestionnaire de service appelant du demarrage du service ou de l'achevement du rechargement de configuration. Cela est equivalent a systemd-notify READY=1. Pour plus de details sur la semantique de cette option, consulter sd_notify(3). --reloading Informer le gestionnaire de service appelant du debut du cycle de rechargement de configuration. Cela est equivalent a systemd-notify RELOADING=1 (mais implicitement definit le champ MONOTONIC_USEC= de la maniere requise pour les services Type=notify-reload, consulter systemd.service(5) pour plus de details). Pour plus de details sur la semantique de cette option, consulter sd_notify(3). Ajoute dans la version 253. --stopping Informer le gestionnaire de service appelant du debut de la phase d'extinction du service. Cela est equivalent a systemd-notify STOPPING=1. Pour plus de details sur la semantique de cette option, consulter sd_notify(3). Ajoute dans la version 253. --pid= Informer le gestionnaire de service sur le PID principal du service. Cette option prend un PID comme argument. Si l'argument indique est << auto >> ou s'il est omis, le PID du processus invoquant systemd-notify est utilise, sauf si c'est le gestionnaire de service. Si l'argument indique est << self >>, le PID de la commande systemd-notify elle-meme est utilise et si << parent >> est indique, le PID du processus appelant est utilise -- meme si c'est le gestionnaire de service. --pid=auto est equivalent a systemd-notify --pid=$PID. Pour plus de details sur la semantique de cette option, consulter sd_notify(3). systemd-notify essaie d'abord d'invoquer sd_notify() en pretendant detenir le PID indique avec l'option --pid=. Cela ne fonctionne que si cela est invoque avec les privileges suffisants. En cas d'echec, il se rabat sur une invocation sous son propre PID. En realite, cela signifie qu'une invocation avec privileges de systemd-notify --pid= peut contourner les restrictions NotifyAccess=main ou NotifyAccess=exec appliquees a un service. Si cette option est utilisee par une invocation sans privileges de systemd-notify par un processus qui devient le nouveau processus principal d'un service -- et qui n'est pas le processus fourche par le gestionnaire de service (ou le processus principal actuel) --, alors il est essentiel de regler NotifyAccess=all dans le fichier d'unite de service, sinon la notification est ignoree pour des raisons de securite. Consulter systemd.service(5) pour plus de details. --uid=UTILISATEUR Definir l'ID d'utilisateur a partir duquel envoyer une notification. L'argument est un nom d'utilisateur UNIX ou un UID numerique. Si cette option est indiquee, le message de notification est envoye avec l'UID specifie comme expediteur a la place de l'utilisateur sous lequel la commande a ete invoquee. Cette option necessite des privileges suffisants pour pouvoir manipuler l'identite d'utilisateur du processus. Ajoute dans la version 237. --status= Envoyer une chaine de forme libre et humainement lisible a partir du demon a destination du gestionnaire de service. Cette option prend une chaine comme argument. C'est equivalent a systemd-notify STATUS=.... Pour plus de details sur la semantique de cette option, consulter sd_notify(3). Cette information est affichee dans la sortie status de systemctl(1), entre autres endroits. --booted Renvoyer 0 si le systeme a ete amorce avec systemd, une valeur differente de zero autrement. Si cette option est passee, aucun message n'est envoye. Cette option ne concerne donc pas les autres options. Pour plus de details sur la semantique de cette option, consulter sd_booted(3). Une autre facon de verifier cet etat est d'appeler systemctl(1) avec la commande is-system-running. Elle affiche << offline >> si le systeme n'a pas ete amorce avec systemd, bien que la valeur de retour ait une signification differente. --no-block Ne pas attendre de maniere synchrone la fin de l'operation demandee. L'utilisation de cette option n'est recommandee seulement que lorsque systemd-notify est engendre par le gestionnaire de service ou quand le processus invoquant est engendre directement par le gestionnaire de service et possede suffisamment de privileges pour permettre a systemd-notify d'envoyer la notification a son nom. L'envoi de notifications avec cette option peut provoquer des situations de competition dans tous les autres cas. Ajoute dans la version 246. --exec Si cette option est indiquee, systemd-notify execute une autre ligne de commande apres avoir termine son operation, en remplacant son propre processus. Si utilisee, la liste des affectations a inclure dans le message envoye doit etre suivie par un caractere << ; >> (comme element de separation), suivi de la ligne de commande a executer. Cela permet le << chainage >> de commandes, c'est-a-dire lancer une operation suivie immediatement par une autre sans changer les PID. Remarquez que de nombreux interpreteurs de commandes interpretent << ; >> comme leur propre separateur de ligne de commande, par consequent, quand systemd-notify est invoque a partir d'un interpreteur, le point-virgule doit etre protege par << \; >>. Ajoute dans la version 254. --fd= Envoyer un descripteur de fichier avec le message de notification. Cela est utile lors d'une invocation dans des services qui ont le reglage FileDescriptorStoreMax= active ; consulter systemd.service(5) pour plus de details. Le descripteur de fichier specifie doit etre passe a systemd-notify lors de l'invocation. Cette option peut etre utilisee plusieurs fois pour passer plusieurs descripteurs de fichier dans un seul message de notification. Pour se servir de cette fonctionnalite dans un interpreteur bash(1), utilisez une expression telle que la suivante : systemd-notify --fd=4 --fd=5 4>. Ce reglage peut etre specifie une seule fois et s'applique a tous les descripteurs de fichier passes. Invoquez cet outil plusieurs fois dans le cas ou plusieurs descripteurs de fichier ayant des noms differents doivent etre passes. Ajoute dans la version 254. --fork Au lieu d'envoyer un message de notification, fourcher une ligne de commande et attendre qu'un message << READY=1 >> soit recu d'elle. En d'autres termes : cela fait de systemd-notify le recepteur d'un message de notification a la place de l'emetteur, echangeant ainsi les roles. Cela est utile pour fourcher rapidement un processus qui met en oeuvre un protocole sd_notify() a partir d'un script d'interpreteur de commandes. La ligne de commande invoquee aura l'entree standard et la sortie standard connectees a /dev/null, mais la sortie standard d'erreur sera heritee du processus invoque. L'ID numerique de processus est ecrit sur la sortie standard par systemd-notify (a moins que l'option --quiet ne soit specifiee) et peut etre utilise pour terminer plus tard le processus fourche. Remarquez que les processus fourches continueront probablement a s'executer apres l'arret de systemd-notify, ce qui aboutira a ce qu'ils soient reapparentes au processus moissonneur le plus proche, c'est-a-dire generalement le gestionnaire de service propre a l'utilisateur ou du systeme. Remarquez que cette option ne doit pas etre utilisee pour lancer des services complets ponctuellement ; utilisez plutot systemd-run(1) dans ce cas. Remarquez aussi qu'invoque avec cette option, systemd-notify termine avec succes sous deux conditions distinctes : 1. systemd-notify a recu une notification << READY=1 >> d'un processus enfant qu'il vient de fourcher. 2. Le processus enfant s'est termine proprement (avec comme code de retour zero) avant d'envoyer un << READY=1 >>. Exemple d'utilisation : # PID=$(systemd-notify --fork -- ma_commande) ... kill "$PID" unset PID Ajoute dans la version 258. --quiet, -q Ne pas indiquer l'ID numerique de processus quand l'option --fork est utilisee. Ajoute dans la version 258. -h, --help Afficher un aide-memoire succinct et quitter. --version Afficher une information de version courte et quitter. CODE DE RETOUR En cas de succes, 0 est renvoye, autrement, un code d'echec different de zero est renvoye. EXEMPLE Exemple 1. Notification d'amorcage et mises a jour d'etat Simple demon d'interpreteur de commandes envoyant des notifications d'amorcage apres avoir configurer son canal de communication. Pendant l'execution, envoi de mises a jour d'etat au systeme init : #!/bin/sh mkfifo /tmp/teleoperateur systemd-notify --ready --status="Attente de donnees..." while : ; do read -r a < /tmp/teleoperateur systemd-notify --status="Traitement de $a" # Faire quelque chose avec $a ... systemd-notify --status="Attente de donnees..." done VOIR AUSSI systemd(1), systemctl(1), systemd.unit(5), systemd.service(5), sd_notify(3), sd_booted(3) TRADUCTION La traduction francaise de cette page de manuel a ete creee par Jean- Paul Guillonneau 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-NOTIFY(1)