Traduction japonaise du manuel affiché par `` man systemd.service ''.
configuration de l'unité systemd.service-service
service.service
Les fichiers de configuration d'unité dont les noms se terminent par `` .service '' encodent des informations sur les processus contrôlés et surveillés par systemd.
Cette page de manuel répertorie les options de configuration spécifiques à ce type d'unité.
Voir systemd.unit (5) pour les options communes à tous les fichiers de configuration de l'unité.
Les composants communs se composent généralement des sections [Unit] '' et [Install] ''.
Les options de configuration spécifiques au service sont configurées dans la section `` [Service] ''.
Les options supplémentaires sont systemd.exec (5), qui définit l'environnement d'exécution dans lequel la commande est exécutée, systemd.kill (5), qui définit la manière dont le processus de service se termine, et systemd, qui configure les paramètres de contrôle des ressources pour le processus de service. Il est répertorié dans .resource-control (5).
Si le service est demandé avec un nom spécifique mais que le fichier de configuration de l'unité est introuvable, systemd recherche un script d'initialisation SysV avec le même nom (avec l'extension .service supprimée) et exécute l'unité de service à partir de ce script. Créer
Ceci est utile pour la compatibilité avec SysV.
Cette compatibilité est très complète mais pas à 100%.
Pour plus d'informations sur les incompatibilités, consultez Incompatibilités avec SysV (https://www.freedesktop.org/wiki/Software/systemd/Incompatibilités).
Le service systemd peut prendre un seul argument via la syntaxe service @ argument.service ''. Ces services sont appelés services instanciés '', et les définitions d'unité sans paramètres d'argument sont appelées modèle ''. Par exemple, le modèle de service dhcpcd @ .service`` utilise une interface réseau comme paramètre pour former un service instancié.
Dans le fichier de service, vous pouvez accéder à ce paramètre ou au «nom de l'instance» en utilisant le spécificateur «%».
Voir systemd.unit (5) pour plus d'informations.
Les dépendances suivantes sont ajoutées implicitement:
Type = dbus défini obtiendront automatiquement des dépendances de types Requis et `ʻAprès séquentiellement sur` `dbus.socket. .socket via la dépendance séquentielle `ʻAfter. Le service prend également automatiquement toutes les unités .socket répertoriées dans Sockets = via les dépendances Veut éventuellement et Après de manière appropriée. Appel.Des dépendances implicites peuvent être ajoutées à la suite des paramètres d'exécution et de contrôle des ressources, comme décrit dans systemd.exec (5) et systemd.resource-control (5).
Les dépendances suivantes sont ajoutées sauf si DefaultDependencies = no est défini:
L'unité de service a une dépendance de type Requis et '' Après notamment pour sysinit.target '', une dépendance de type Après simplement pour basic.target '', Il existe une dépendance de type Conflits de manière appropriée et Avant en particulier à shutdown.target. Cela permet à une unité de service normale de capturer l'initialisation de base du système et de l'arrêter complètement avant l'arrêt du système. Cette option ne peut être désactivée que pour les services liés aux délais de démarrage précoce ou d'arrêt du système.
Par défaut, les unités de service instanciées (c'est-à-dire les unités de service avec @ '' dans leurs noms) sont des tranches par modèle nommées d'après l'unité de modèle, y compris toutes les instances d'un modèle particulier. Affecté à une unité (voir systemd.slice (5)). Cette tranche s'arrête généralement avec toutes les instances de modèle à l'arrêt. Si cela n'est pas souhaitable, définissez votre propre fichier d'unité de tranche par modèle qui définit DefaultDependencies = nodans l'unité de modèle et également DefaultDependencies = noou Slice dans l'unité de modèle. Set = system.slice '' (ou une autre tranche appropriée). Voir systemd.resource-control (5) pour plus d'informations.
Le fichier de service doit inclure une section [Service] ''. Cette section contient des informations sur le service et les processus qu'il surveille. Certaines des options disponibles dans cette section sont partagées avec d'autres types d'unités. Ces options sont décrites dans systemd.exec (5), systemd.kill (5), systemd.resource-control (5). Les options spécifiques à la section [Service] '' de l'unité de service sont:
Type= Définit le type de démarrage du processus pour cette unité de service.
simple (par défaut lorsque ExecStart = est spécifié et que ni Type = ni BusName = ne sont spécifiés)
Le gestionnaire de service considère que l'unité est démarrée immédiatement après la fourche du processus de service principal.
Il est prévu que le processus configuré avec ExecStart = sera le processus principal du service.
Dans ce mode, le gestionnaire de service démarre immédiatement après la création du processus de service principal, car le gestionnaire de service procède immédiatement au démarrage des unités suivantes avant d'exécuter les binaires de service.
Si un processus fournit des fonctionnalités à d'autres processus sur le système, il doit installer son canal de communication avant de démarrer le service. (Exemple: socket configuré par systemd via l'activation du socket)
Il s'agit de la ligne de commande systemctl start du service simple, même si le binaire du service ne peut pas être appelé avec succès (par exemple, si l'utilisateur sélectionné n'existe tout simplement pas ou si le binaire du service est introuvable). Moyens de signaler le succès.
exec
Le type exec est similaire à simple.
Cependant, le gestionnaire de service considère que l'unité est démarrée immédiatement après l'exécution du binaire de service principal.
Le gestionnaire de service retarde le démarrage des unités suivantes jusqu'à ce que le binaire de service principal soit exécuté.
(Ou en d'autres termes, simple '' continuera le travail immédiatement après le retour de fork () '',
```Execne continue pas tant que le processus de service n'a pas réussi. Notez que cela signifie la commande systemctl start '' pour le service exec.
Si le binaire de service ne peut pas être appelé avec succès (par exemple, l'utilisateur sélectionné n'existe tout simplement pas ou le binaire de service est introuvable), il signale un échec.
forking Les processus configurés avec ExecStart = sont censés appeler `` fork () '' dans le cadre du processus de démarrage. Le processus parent doit se terminer lorsque le démarrage est terminé et que tous les canaux de communication sont configurés. Le processus enfant continue de s'exécuter en tant que processus de service principal et le gestionnaire de services considère que l'unité est démarrée lorsque le processus parent se termine. C'est le comportement des services UNIX traditionnels. Nous vous recommandons d'utiliser également l'option PIDFile = pour vous assurer que systemd peut identifier le processus principal du service lors de l'utilisation de ce paramètre. systemd procède au démarrage des unités suivantes dès que le processus parent se termine.
oneshot
Le comportement de onehot est similaire à simple.
Cependant, le gestionnaire de service considère l'unité comme démarrée après la fin du processus principal et démarre les unités suivantes après la fin du processus principal.
RemainAfterExit = est particulièrement utile pour ce type de service.
Si ni Type = ni ExecStart = n'est spécifié, Type = oneshot est implicitement défini comme valeur par défaut.
dbus Le comportement de dbus est similaire à simple. Cependant, le service devrait obtenir le nom du bus sur le D-Bus, tel que défini par BusName =. systemd procède au démarrage des unités suivantes une fois le nom du bus D-Bus obtenu. Les unités de service avec cette option obtiennent implicitement une dépendance sur l'unité `` dbus.socket ''. Si BusName = est spécifié, dbus est le type par défaut.
notify
Le comportement de notify est similaire à celui de exec.
Cependant, une fois que le service a démarré, le service est censé envoyer un message de notification via sd_notify (3) ou un appel équivalent.
systemd procède au démarrage des unités suivantes après l'envoi de ce message de notification.
Si vous utilisez cette option, vous devez définir NotifyAccess = (#notifyaccess) pour ouvrir l'accès au socket de notification fourni par systemd.
Si NotifyAccess = est manquant ou défini sur aucun '', il sera forcé à main. Actuellement, Type = notify '' ne fonctionne pas lorsqu'il est utilisé en combinaison avec PrivateNetwork = yes.
idle Le comportement de ralenti est très similaire à simple. Cependant, l'exécution réelle du programme de service est retardée jusqu'à ce que tous les travaux actifs aient été distribués. Cela peut être utilisé pour éviter d'entrelacer la sortie du service shell et la sortie de l'état de la console. Notez que ce type n'est utile que pour améliorer la sortie de la console et non comme outil général d'exécution d'unité. L'effet de ce type de service est affecté par un délai d'expiration de 5 secondes, après quoi le programme de service est appelé.
`` Type = simple '' est l'option la plus simple et la plus rapide, nous vous recommandons donc de l'utiliser pour les services de longue durée autant que possible. Cependant, ce type de service ne propage pas les échecs de démarrage du service et ne permet pas à d'autres unités d'être commandées pour terminer l'initialisation du service.
Le canal IPC est établi uniquement par le service lui-même. (Par exemple, utile si le client doit se connecter au service via une forme d'IPC) Contrairement aux canaux préétablis, tels que l'activation par socket ou bus, cela peut souvent ne pas être suffisant. Dans ce cas, nous vous recommandons d'utiliser notify ou dbus (ce dernier uniquement si le service fournit une interface D-Bus). Cela permet au code du programme de service de planifier avec précision quand le service doit être considéré comme réussi et quand les unités suivantes doivent se poursuivre. Le type de service de notification nécessite une prise en charge explicite dans la base de code de service car `` sd_notify () '' ou une API équivalente doit être appelée par le service au bon moment. Utilisez plutôt forking s'il n'est pas pris en charge: forking prend en charge les protocoles de démarrage de service UNIX traditionnels.
Enfin, exec est suffisant pour garantir que le binaire de service est appelé, et est une option si le binaire de service lui-même n'effectue pas ou peu d'initialisation (s'il est peu probable que l'initialisation échoue). Tu pourrais. Sachez que l'utilisation d'un type autre que simple peut retarder le processus de démarrage en attendant que le gestionnaire de services termine l'initialisation du service. Par conséquent, nous vous recommandons de ne pas utiliser négligemment des types autres que simples. (Gardez également à l'esprit qu'il n'est généralement pas recommandé d'utiliser idle ou onehot pour les services de longue durée.)
RemainAfterExit= Il prend une valeur booléenne qui spécifie si le service est considéré comme actif, même si tous les processus sont terminés. La valeur par défaut est `` non ''.
GuessMainPID=
Prend une valeur booléenne qui spécifie si systemd déduit le PID principal du service s'il ne peut pas être déterminé de manière fiable.
Cette option est ignorée sauf si Type = forking est défini et PIDFile = n'est pas défini.
Pour les autres types, ou pour le PIDFile explicitement configuré (#pidfile), le PID principal est toujours connu.
Si le démon se compose de plusieurs processus, l'algorithme de devinettes peut conduire à des conclusions incorrectes.
Si le PID principal ne peut pas être déterminé, la détection des échecs de démarrage du service et le redémarrage automatique ne fonctionneront pas correctement.
La valeur par défaut est `` oui ''.
PIDFile=
Obtient le chemin qui référence le fichier PID du service.
Nous vous recommandons d'utiliser cette option pour les services définis sur Type = fork ''. Le chemin spécifié pointe généralement vers les fichiers sous / run / ''.
Si un chemin relatif est spécifié, `` / run / '' est implicitement ajouté au chemin.
Après le démarrage du service, le gestionnaire de services lit le PID du processus principal du service à partir du fichier spécifié dans PIDFile.
Le gestionnaire de services n'écrit pas dans les fichiers configurés ici, mais supprime les fichiers après l'arrêt si le service existe toujours.
Le fichier PID ne doit pas nécessairement appartenir à un utilisateur privilégié, mais s'il appartient à un utilisateur non privilégié, des restrictions de sécurité supplémentaires s'appliquent.
Le fichier ne peut pas être un lien symbolique (directement ou indirectement) vers un fichier appartenant à un autre utilisateur.
Le fichier PID doit faire référence au processus qui appartient au service.
BusName= Obtient le nom du bus D-Bus qui peut atteindre ce service. Cette option est requise pour les services avec `` Type = dbus '' réglé.
ExecStart= Spécifie une commande avec des arguments à exécuter au démarrage du service. La valeur est divisée en lignes de commande selon les règles décrites ci-dessous (voir la section Ligne de commande (#Command Line) ci-dessous).
Une seule commande doit être spécifiée à moins que Type = onehot ''. Vous pouvez spécifier zéro ou plusieurs commandes lorsque vous utilisez Type = onehot ''.
Une commande peut spécifier plusieurs lignes de commande avec la même directive.
Vous pouvez également spécifier cette directive plusieurs fois pour obtenir le même effet.
Si une chaîne vide est attribuée à cette option, la liste des commandes à démarrer sera réinitialisée.
L'affectation de cette option avant une chaîne vide n'a aucun effet.
Si ExecStart = n'est pas spécifié, le service doit avoir RemainAfterExit = yes et au moins une ligne ExecStop =.
(Les services sans ExecStart = et ExecStop = ne sont pas valides)
Le premier argument de chaque commande spécifiée doit être un chemin absolu vers un fichier exécutable ou un nom de fichier simple sans barres obliques. Vous pouvez éventuellement préfixer le nom du fichier avec des caractères spéciaux.
** Tableau 1. Préfixe exécutable spécial **
| préfixe | effet |
|---|---|
@ |
Au début du chemin de l'exécutable@Si vous ajoutez, le deuxième jeton spécifié seraargv[0]Comme(Pas le nom de fichier réel)Passé au processus exécuté, le deuxième jeton est suivi de l'argument spécifié. |
- |
Au début du chemin de l'exécutable-Code de fin pour les commandes qui sont normalement considérées comme échouant si(Autrement dit, une fin anormale avec un état ou un signal de terminaison non nul)Est enregistré, mais n'a pas d'impact supplémentaire et est considéré comme équivalent au succès. |
+ |
Au début du chemin de l'exécutable+Si c'est le cas, le processus s'exécute avec tous les privilèges. Dans ce modeUser= , Group= , CapabilityBoundingSet=Ou options d'espace de noms du système de fichiers( PrivateDevices= , PrivateTmp=Tel)Les restrictions de privilège configurées avec ne s'appliquent pas à la ligne de commande appelée.(Cependant, d'autresExecStart=,ExecStop=Affecteleslignesdecommandetellesque) |
! |
au dessus de+Comme les caractères, vous pouvez appeler des lignes de commande avec des privilèges élevés. pourtant+Contrairement à,!PersonnageUser= , Group= , SupplementaryGroups=Changez uniquement l'effet de. Autrement dit, seules les strophes qui affectent les informations d'identification des utilisateurs et des groupes. Ce paramètre estDynamicUser=Peut être combiné avec. Dans ce cas, l'utilisateur avant l'appel de la commande/Les paires de groupes sont attribuées dynamiquement, mais les modifications des informations d'identification sont laissées au processus en cours d'exécution lui-même. |
!! |
Ce préfixe est!Similaire à, mais sans prise en charge des capacités de traitement ambiant, c.-à-d.AmbientCapabilities=N'affecte que les systèmes qui ne prennent pas en charge. Il est destiné à être utilisé pour les fichiers d'unité qui utilisent la fonction ambiante pour exécuter des processus avec le moins de privilèges possible tout en maintenant la compatibilité avec les systèmes qui ne prennent pas en charge la fonction ambiante.!!Pour permettre au processus généré de révoquer les informations d'identification et les fonctionnalités, même s'il est configuré pour interdireSystemCallFilter=QuandCapabilityBoundingSet=La strophe est implicitement modifiée. En outre, si un système détecté utilise ce préfixe mais ne prend pas en charge la fonctionnalité ambianteAmbientCapabilities=Est ignoré et ne s'applique pas. Pour les systèmes prenant en charge la fonction ambiante!!Puisqu'il n'y a aucun effet de, la description est redondante. |
Vous pouvez utiliser @ '', - '' et + '' /! / !! '', et vous pouvez les spécifier dans n'importe quel ordre.
Cependant, + '',! '', `` !! '' ne peut être utilisé qu'une seule fois.
Ces préfixes concernent d'autres paramètres de ligne de commande ([ExecStartPre =](# execstartpre-execstartpost), [ExecStartPost =](# execstartpre-execstartpost), ExecReload =, ExecStop = ), ExecStopPost =) est également pris en charge.
Si plus d'une commande est spécifiée, les commandes seront appelées séquentiellement dans l'ordre dans lequel elles apparaissent dans le fichier d'unité. Si l'une des commandes échoue (et n'est pas précédée de `` - ''), l'autre ligne n'est pas exécutée et l'unité est considérée comme ayant échoué.
À moins que `` Type = forking '' ne soit défini, le processus lancé à partir de cette ligne de commande est considéré comme le processus principal du démon.
ExecStartPre=, ExecStartPost= Spécifie des commandes supplémentaires à exécuter avant ou après la commande ExecStart =. La syntaxe est la même que pour ExecStart =, sauf que plusieurs lignes de commande sont autorisées et que les commandes sont exécutées en séquence. Si l'une de ces commandes échoue (et n'est pas précédée de `` - ''), la ligne de commande post-échec n'est pas exécutée et l'unité est considérée comme ayant échoué.
La commande ExecStart = est exécutée uniquement après que toutes les commandes [ExecStartPre =](# execstartpre-execstartpost) sans le préfixe - se sont terminées avec succès.
La commande [ExecStartPost =](# execstartpre-execstartpost) est exécutée uniquement après que la commande spécifiée par ExecStart = a été appelée avec succès.
Ceci est déterminé par Type =.
Exemple:
Type = simple ou Type = idle et que le dernier processus ExecStart = se termine normalement par Type = onehot Type = forkingREADY = 1 '' est envoyé avec Type = notifier '' Type = dbusNotez que [ExecStartPre =](# execstartpre-execstartpost) peut ne pas être disponible pour démarrer un processus de longue durée. Tous les processus branchés par le processus appelé via [ExecStartPre =](# execstartpre-execstartpost) seront tués avant l'exécution du processus de service suivant.
L'une des commandes spécifiées par [ExecStartPre =](# execstartpre-execstartpost), ExecStart = ou [ExecStartPost =](# execstartpre-execstartpost) échoue (et est précédée de -. Notez que si le service expire avant d'être complètement démarré, la commande spécifiée par ExecStopPost = continuera à s'exécuter.
La commande ExecStop = est ignorée.
ExecReload= Spécifie la commande à exécuter pour déclencher le service afin de recharger la configuration. L'argument prend plusieurs lignes de commande selon le même schéma décrit dans ExecStart = ci-dessus. L'utilisation de ce paramètre est facultative. La substitution de spécificateurs et de variables d'environnement est prise en charge selon le même schéma que ExecStart =.
Une variable d'environnement spéciale supplémentaire est définie. S'il est connu, `` $ MAINPID '' est défini sur le processus principal du démon. Il peut être utilisé sur des lignes de commande telles que:
/bin/kill -HUP $MAINPID
Cependant, signaler et recharger le démon comme dans l'exemple ci-dessus n'est généralement pas un bon choix, car il s'agit d'une opération asynchrone et ne convient pas pour commander des rechargements de plusieurs services les uns des autres. .. Il est fortement recommandé de définir une commande qui non seulement déclenche le rechargement de la configuration du démon avec ExecReload =, mais attend également que le démon se termine de manière synchrone.
ExecStop=
Spécifie la commande à exécuter pour arrêter les services démarrés avec ExecStart =.
L'argument prend plusieurs lignes de commande selon le même schéma décrit dans ExecStart = ci-dessus.
L'utilisation de ce paramètre est facultative.
Une fois la commande configurée avec cette option exécutée, le service sera arrêté et tous les processus restants seront arrêtés selon le paramètre KillMode approprié (voir systemd.kill (5)). Si cette option n'est pas spécifiée, le processus se termine en envoyant le signal spécifié par KillSignal de manière appropriée lorsqu'un arrêt de service est demandé.
La substitution de spécificateurs et de variables d'environnement, y compris `` $ MAINPID '' est prise en charge.
Notez que demander simplement au service de se terminer (par exemple, mettre en file d'attente une forme de signal de terminaison) ne suffit pas et n'attend pas la fin du service. Le reste du processus de service peut ne pas s'arrêter correctement car il est tué immédiatement après la fin de la commande selon les états `` KillMode et KillSignal de manière appropriée comme décrit ci-dessus. Par conséquent, la commande spécifiée doit être une opération synchrone et non une opération asynchrone.
Notez que la commande spécifiée par ExecStop = ne sera exécutée que lors du premier démarrage du service.
Si le service n'a jamais démarré ou s'il ne démarre pas
Par exemple, si l'une des commandes spécifiées dans ExecStart =, [ExecStartPre =](# execstartpre-execstartpost) ou [ExecStartPost =](# execstartpre-execstartpost) échoue (et commence par - (Si n'est pas joint)
Ou il ne sera pas appelé s'il expire.
Si le service ne démarre pas correctement et s'arrête à nouveau, utilisez ExecStopPost = pour appeler la commande. Notez également que la demande de redémarrage du service est implémentée comme une opération d'arrêt suivie d'une opération de démarrage. Autrement dit, ExecStop = et ExecStopPost = sont exécutés pendant l'opération de redémarrage du service.
Nous vous recommandons d'utiliser ce paramètre pour les commandes qui communiquent avec les services qui demandent une nouvelle terminaison. Lorsque la commande spécifiée avec cette option est exécutée, vous devez supposer que le service est toujours pleinement opérationnel et répondra correctement à toutes les commandes.
Pour les étapes de post-nettoyage, utilisez plutôt ExecStopPost =.
ExecStopPost= Spécifie des commandes supplémentaires à exécuter après l'arrêt du service. Cela inclut lorsqu'une commande configurée avec ExecStop = est utilisée, ExecStop = n'est pas définie pour le service ou le service se termine de manière inattendue. Sera. L'argument prend plusieurs lignes de commande selon le même schéma décrit dans ExecStart =. L'utilisation de ces paramètres est facultative. Prend en charge la substitution de spécificateur et de variable d'environnement.
Contrairement à ExecStop =, la commande spécifiée dans ce paramètre sera appelée lorsque le service ne démarre pas correctement et est de nouveau arrêté.
Nous vous recommandons d'utiliser ce paramètre pour les opérations de nettoyage qui se produisent même si le service ne démarre pas correctement. Les commandes configurées avec ce paramètre doivent pouvoir fonctionner même si le service ne démarre pas prématurément et que les données incomplètement initialisées restent. Le processus de service est déjà terminé lorsque les commandes spécifiées dans ce paramètre sont exécutées et ne doit pas tenter de communiquer avec elles.
Toutes les commandes configurées avec ce paramètre sont le résultat du service, ainsi que le code de fin de processus principal et le statut définis dans les variables d'environnement $ SERVICE_RESULT, $ EXIT_CODE, $ EXIT_STATUS. Notez qu'il est appelé dans le code.
Voir systemd.exec (5) pour plus d'informations.
RestartSec=
Définit la durée de mise en veille avant de redémarrer le service défini par Restart =.
Prend une valeur sans unités en secondes ou une valeur de durée telle que 5min 20s ''. La valeur par défaut est 100ms ''.
TimeoutStartSec=
Réglez le temps d'attente pour le démarrage.
Si le service démon ne notifie pas la fin du démarrage dans le délai configuré, le service est considéré comme ayant échoué et sera de nouveau arrêté.
Prend une valeur sans unités en secondes ou une valeur de durée telle que 5min 20s ''. Passer «infini» désactive la logique de temporisation. À moins que Type = onehot '' soit utilisé, la valeur par défaut est `` DefaultTimeoutStartSec représente dans le fichier de configuration du gestionnaire.
Dans ce cas, le délai d'expiration est désactivé par défaut (voir systemd-system.conf (5)).
Si un service avec Type = notify envoie ```EXTEND_TIMEOUT_USEC = ... ``, cela peut prolonger l'heure de début au-delà de [TimeoutStartSec =](# timeoutstartsec).
La première réception de ce message doit avoir lieu avant que le TimeoutStartSec = ne soit dépassé.
Une fois que l'heure de début dépasse TimeoutStartSec =, le gestionnaire de service répète «EXTEND_TIMEOUT_USEC = ...» pour démarrer le service jusqu'à ce que l'état de démarrage du service se termine par «READY = 1». Vous permet de continuer.
(Voir sd_notify (3))
TimeoutStopSec=
Cette option a deux objectifs.
Tout d'abord, configurez le temps d'attente pour chaque commande ExecStop =.
Si l'un d'eux expire, la commande suivante ExecStop = sera ignorée et le service sera interrompu par SIGTERM ''. Si la commande [ExecStop =](#execstop) n'est pas spécifiée, le service recevra immédiatement un SIGTERM ''.
Configurez ensuite le temps d'attente pour l'arrêt du service lui-même.
S'il ne se termine pas dans le délai spécifié, il sera tué par SIGKILL '' (voir Causes de KillMode dans systemd.kill (5)).
Prend une valeur sans unités en secondes ou une valeur de durée telle que 5min 20s ''. Passer «infini» désactive la logique de temporisation. La valeur par défaut est DefaultTimeoutStopSec s'ouvre) dans le fichier de configuration du gestionnaire (voir systemd-system.conf (5)).
Lorsqu'un service avec Type = notify envoie ```EXTEND_TIMEOUT_USEC = ... ``, le temps d'arrêt peut être prolongé au-delà de [TimeoutStopSec =](# timeoutstopsec).
La première réception de ce message doit avoir lieu avant que TimeoutStopSec = ne soit dépassé, et après que l'heure d'arrêt dépasse TimeoutStopSec =, ʻEXTEND_TIMEOUT_USEC = ... ` Répétez pour permettre au service de s'arrêter.
(Voir sd_notify (3))
TimeoutSec= Abréviation pour définir à la fois TimeoutStartSec = et TimeoutStopSec = aux valeurs spécifiées.
RuntimeMaxSec=
Configurez la durée maximale d'exécution du service.
Si cela est utilisé et que le service a été actif pendant plus longtemps que la durée spécifiée, le service sera interrompu et sera en état d'échec.
Ce paramètre n'affecte pas le service Type = oneshot '' car il se termine immédiatement après l'activation. Passer `ʻinfinity (par défaut) ne configure pas les limites d'exécution.
Si un service avec Type = notify envoie ʻEXTEND_TIMEOUT_USEC = ... `, le temps d'exécution peut être prolongé au-delà de RuntimeMaxSec =.
La première réception de ce message doit avoir lieu avant que RuntimeMaxSec = ne soit dépassé, et si le temps d'exécution est prolongé au-delà de RuntimeMaxSec =, le gestionnaire de services exécutera le service. Autoriser.
Si le service répète "EXTEND_TIMEOUT_USEC = ..." pendant l'intervalle, il est spécifié jusqu'à ce que `` STOPPING = 1 '' (ou la terminaison) réalise l'arrêt du service.
(Voir sd_notify (3))
WatchdogSec=
Définissez le délai d'expiration du chien de garde pour le service.
Le chien de garde devient actif lorsque le lancement est terminé.
Le service doit appeler sd_notify (3) régulièrement avec WATCHDOG = 1 '' (c'est-à-dire keep-alive ping '').
Si le temps entre ces deux appels est plus long que le temps configuré, le service passe dans un état d'échec et se termine par SIGABRT '' (ou le signal spécifié par WatchdogSignal représente).
Si vous définissez Restart = sur ʻon-failure``, ʻon-watchdog, `ʻon-an-anormal ou` ʻalways, le service sera redémarré automatiquement. Je vais. L'heure définie ici est transmise au processus de service exécuté avec la WATCHDOG_USEC = variable d'environnement ''.
Cela permet au démon d'activer automatiquement la logique `` keep-alive ping '' lorsque la prise en charge du chien de garde est activée sur le service.
Si vous utilisez cette option, vous devez définir NotifyAccess = (#notifyaccess) pour ouvrir l'accès au socket de notification fourni par systemd.
Si NotifyAccess = n'est pas défini, il est implicitement défini sur main.
La valeur par défaut est 0, ce qui désactive cette fonctionnalité.
Le service peut voir si le gestionnaire de service s'attend à ce que le chien de garde garde des notifications actives.
Voir sd_watchdog_enabled (3) pour plus d'informations.
Vous pouvez utiliser sd_event_set_watchdog (3) pour activer la prise en charge automatique des notifications de surveillance.
Restart= Configurez si le processus de service est arrêté, tué ou redémarré lorsque le délai d'expiration est atteint. Le processus de service peut être le processus de service principal, mais [ExecStartPre =](# execstartpre-execstartpost), [ExecStartPost =](# execstartpre-execstartpost), ExecStop =, [ExecStopPost =](# Il peut également s'agir de l'un des processus spécifiés par execstoppost) ou ExecReload =. Si l'arrêt du processus est le résultat d'une opération systemd (telle que l'arrêt ou le redémarrage du service), le service ne sera pas redémarré. Les délais incluent les expirations manquantes du chien de garde `` keep-alive ping '', le démarrage du service, le rechargement et l'arrêt des opérations.
Prenez l'une des choses suivantes:
aucun défaut) Le service ne sera pas redémarré.
on-success Il ne sera redémarré que si le processus de service se termine avec succès. Dans ce contexte, une résiliation réussie est:
0 code de fin
Soit le signal SIGHUP '', SIGINT '', SIGTERM '' ou SIGPIPE ''
Statut de sortie et signal spécifié par SuccessExitStatus =
on-failure Un timeout de chien de garde configuré avec un timeout a été déclenché lorsque le processus s'est terminé avec un code de terminaison différent de zéro et l'opération s'est terminée par un signal (incluant un vidage de mémoire, mais excluant les quatre signaux mentionnés ci-dessus) (par exemple, recharger). Parfois, le service est redémarré.
on-abnormal Le service est redémarré lorsque le processus est terminé par un signal (y compris un vidage de mémoire autre que les quatre signaux ci-dessus), lorsque l'opération expire ou lorsqu'un délai de surveillance est déclenché.
on-watchdog Le service ne sera redémarré que si le délai de surveillance du service a expiré (soit terminé anormalement en raison d'un signal, soit le délai d'expiration a été atteint).
on-abort Le service ne sera redémarré que si le processus de service se termine car un signal non intercepté n'a pas été spécifié comme état de fin propre.
always Le service sera redémarré indépendamment du fait qu'il se soit terminé avec succès.
** Tableau 2. Causes d'arrêt et impact du paramètre `` Redémarrer séquentiellement sur eux **
| Redémarrer les paramètres/Cause de résiliation | no | always | on-success | on-failure | on-abnormal | on-abort | on-watchdog |
|---|---|---|---|---|---|---|---|
| Clean exit code or signal | X | X | |||||
| Unclean exit code | X | X | |||||
| Unclean signal | X | X | X | X | |||
| Timeout | X | X | X | ||||
| Watchdog | X | X | X | X |
Par exception aux paramètres ci-dessus, le service redémarrera si un code ou un signal de terminaison est spécifié dans RestartPreventExitStatus =, ou si le service est arrêté par `` systemctl stop '' ou une opération équivalente. ça ne commencera pas. De plus, si un code ou un signal de terminaison est spécifié dans RestartForceExitStatus =, le service sera toujours redémarré.
Notez que le redémarrage du service est affecté par la limite de taux de démarrage de l'unité, qui se compose de StartLimitIntervalSec ouvre et StartLimitBurst séquentiellement.
Voir systemd.unit (5) pour plus d'informations.
Le service redémarré échouera uniquement une fois la limite de départ atteinte.
Définir ceci sur «en cas de panne» est le choix recommandé pour les services de longue durée afin de tenter une récupération automatique des erreurs et d'améliorer la fiabilité. Pour les services qui peuvent être interrompus (et non redémarrés immédiatement) à votre gré, vous pouvez remplacer «non anormal».
SuccessExitStatus=
Code de terminaison 0 et signaux SIGHUP '', SIGINT '', SIGTERM '', SIGPIPE '' lorsqu'ils sont renvoyés du processus de service principal, plus l'état de terminaison considéré comme réussi Obtenez une liste de définitions.
La définition de l'état de fin est soit un code de fin numérique séparé par des espaces, soit un nom de signal de fin.
Exemple de description
SuccessExitStatus = 1 2 8 SIGKILL
Dans cet exemple, le code de fin 1, 2, 8 et le signal de fin `` SIGKILL '' sont considérés comme la fin du service propre.
Cette option peut apparaître plusieurs fois. Dans ce cas, la liste des statuts d'achèvement réussi sera fusionnée. Si une chaîne vide est attribuée à cette option, la liste sera réinitialisée et toutes les affectations antérieures à la chaîne vide seront invalides.
RestartPreventExitStatus= Obtient une liste de définitions d'état d'arrêt qui empêchent le redémarrage automatique des services, quels que soient les paramètres de redémarrage configurés avec Restart =](#restart) lorsqu'ils sont renvoyés par le processus de service principal. La définition de l'état de fin est soit un code de fin numérique, soit un nom de signal de fin, séparé par un espace. Par défaut, la liste est vide, donc l'état de sortie n'est pas exclu de la logique de redémarrage configurée.
Exemple de description
RestartPreventExitStatus = 1 6 SIGABRT
Cet exemple évite que le service soit automatiquement redémarré par les codes de terminaison 1 et 6 et le signal de terminaison `` SIGABRT ''. Cette option peut apparaître plusieurs fois. Dans ce cas, la liste des états de prévention de redémarrage sera fusionnée. Si une chaîne vide est attribuée à cette option, la liste sera réinitialisée et toutes les affectations antérieures à la chaîne vide seront invalides.
RestartForceExitStatus= Obtient une liste de définitions d'état de fin qui forcent un redémarrage automatique du service, quel que soit le paramètre de redémarrage configuré avec Restart = lorsqu'il est renvoyé par le processus de service principal. Le format de l'argument est similaire à RestartPreventExitStatus =.
RootDirectoryStartOnly=
Prend un argument booléen.
Pour true les répertoires racine configurés avec RootDirectory = option (voir systemd.exec (5) pour plus de détails) ne sont que pour les processus démarrés avec ExecStart =. Applicable à d'autres [ExecStartPre =](# execstartpre-execstartpost), [ExecStartPost =](# execstartpre-execstartpost), ExecReload =, ExecStop =, [ExecStopPost =]( Cela ne s'applique pas à la commande #execstoppost).
Si false '', le paramètre sera appliqué à toutes les commandes configurées de la même manière. La valeur par défaut est false ''.
NonBlocking=
Définissez l'indicateur O_NONBLOCK sur tous les descripteurs de fichier transmis via l'activation basée sur le socket.
Si vrai, tous les descripteurs de fichier> = 3 (c'est-à-dire stdin, ) sauf ceux passés par la logique de stockage des descripteurs de fichiers (voir [FileDescriptorStoreMax =](#filedescriptorstoremax) pour plus de détails). stdout, sauf` `stderr) est en mode non bloquant car le drapeau O_NONBLOCK est défini.
Cette option n'est utile que lorsqu'elle est combinée avec une unité de socket, comme décrit dans systemd.socket (5), et n'affecte pas les descripteurs de fichiers précédemment stockés dans le magasin de descripteurs de fichiers, etc.
Le défaut est faux.
NotifyAccess= Contrôle l'accès au socket de notification de l'état du service afin qu'il soit accessible avec l'appel sd_notify (3). Prenez l'une des choses suivantes:
aucun (par défaut) Les mises à jour d'état de démolition des processus de service ne sont pas acceptées et tous les messages de mise à jour d'état sont ignorés.
main Seules les mises à jour de service envoyées depuis le processus principal du service sont acceptées.
exec Seules les mises à jour de service envoyées soit par le processus principal soit par le processus de contrôle provenant de l'une des «commandes Exec * =» sont acceptées.
all Toutes les mises à jour de service sont acceptées de tous les membres du groupe de contrôle de service.
Cette option doit être définie pour ouvrir l'accès à la prise de notification lors de l'utilisation de Type = notify ou WatchdogSec = (voir ci-dessus).
Si ces options sont utilisées mais que NotifyAccess = (#notifyaccess) n'est pas configuré, il est implicitement défini sur main.
Notez que les notifications sd_notify () ne sont correctement associées à une unité que si le processus d'envoi existe toujours lorsque le PID 1 traite le message, ou si le processus d'envoi est explicitement suivi à l'exécution par le gestionnaire de services. S'il vous plaît. Ce dernier cas est le cas lorsque le gestionnaire de services branche d'abord le processus, c'est-à-dire tous les processus qui correspondent à main ou exec. Inversement, si le processus auxiliaire de l'unité envoie un message sd_notify () et quitte immédiatement, le gestionnaire de service ne pourra pas associer correctement le message avec l'unité même si `` NotifyAccess = all '' est défini. Ignorez le message.
Sockets= Spécifie le nom de l'unité de socket qui hérite du descripteur de fichier de socket au démarrage du service. Normalement, vous n'avez pas besoin d'utiliser ce paramètre. Tous les descripteurs de fichier de socket (avec différentes extensions de nom d'unité) dont l'unité partage le même nom que le service sont passés au processus généré.
Notez que le même descripteur de fichier de socket peut être passé à plusieurs processus en même temps.
Notez également que le trafic de socket entrant peut éventuellement activer un service différent de celui qui est configuré pour hériter du descripteur de fichier de socket.
En d'autres termes, le paramètre Service approprié de l'unité .socketn'a pas à correspondre à l'inverse du paramètre [Sockets =](#sockets) du .service`` auquel il fait référence.
Cette option peut apparaître plusieurs fois. Dans ce cas, la liste des unités de prise sera fusionnée. Si une chaîne vide est assignée à cette option, la liste des sockets sera réinitialisée et les paramètres spécifiés avant la chaîne vide n'auront aucun effet.
FileDescriptorStoreMax=
Utilisez le message FDSTORE = 1 '' dans sd_pid_notify_with_fds (3) pour configurer le nombre de descripteurs de fichiers pouvant être stockés dans le gestionnaire de services du service. Cela permet d'implémenter des services qui peuvent être redémarrés sans perte d'état après une demande explicite ou une panne. Les sockets ouverts et autres descripteurs de fichiers qui ne doivent pas être fermés lors d'un redémarrage peuvent être enregistrés de cette manière. L'état de l'application peut être sérialisé dans un fichier dans / runou sauvegardé dans le descripteur de fichier mémoire memfd_create (2). La valeur par défaut est 0. Autrement dit, vous ne pouvez pas enregistrer un descripteur de fichier dans un descripteur de service. Tous les descripteurs de fichiers passés d'un service particulier au gestionnaire de services seront renvoyés au processus principal du service lors du prochain redémarrage du service. Le descripteur de fichier transmis au gestionnaire de services est lorsque POLLHUP '' ou `` POLLERR '' est affiché, ou le service est complètement arrêté et le travail n'est pas mis en file d'attente ou en cours d'exécution. Quand il se ferme automatiquement.
Si vous utilisez cette option, vous devez définir NotifyAccess = (#notifyaccess) pour ouvrir l'accès au socket de notification fourni par systemd.
Si NotifyAccess = n'est pas défini, il est implicitement défini sur main.
USBFunctionDescriptors=
Définissez l'emplacement du fichier contenant le descripteur USB FunctionFS pour implémenter la fonction de gadget USB.
Ceci n'est utilisé qu'en combinaison avec des prises avec ListenUSBFunction correctement réglé. Le contenu de ce fichier sera écrit dans le fichier `ʻep0 après ouverture.
USBFunctionStrings= USB FunctionFS Configure l'emplacement des fichiers contenant des chaînes. Le comportement est similaire à USBFunctionDescriptors = ci-dessus.
Vérifiez systemd.exec (5) et systemd.kill (5) pour d'autres paramètres.
Cette section décrit l'analyse de ligne de commande facultative et le remplacement des variables et des spécificateurs suivants.
Vous pouvez concaténer plusieurs lignes de commande en une seule directive en les séparant par des points-virgules (ces points-virgules doivent être passés en tant que mots séparés).
Un seul point-virgule peut être échappé sous la forme \;.
Chaque ligne de commande est séparée par un espace.
Le premier élément est la commande à exécuter et les seconds éléments sont les arguments.
Des guillemets doubles ("...") et des guillemets simples ('...') peuvent être utilisés pour envelopper l'élément entier.
(Les guillemets de début ne peuvent être affichés qu'au début ou après un espace qui n'est pas entre guillemets, et les guillemets de fin sont suivis d'un espace ou de fin de ligne)
Dans ce cas, tout jusqu'au prochain devis correspondant fera partie du même argument et le devis lui-même sera supprimé.
L'échappement de style C est également pris en charge.
Le tableau suivant répertorie les modèles d'échappement connus.
Seuls les modèles d'échappement qui correspondent à la syntaxe de la table sont autorisés.
D'autres modèles peuvent être ajoutés à l'avenir, et les modèles inconnus sont un avertissement.
En particulier, la barre oblique inverse doit être doublée.
Vous pouvez utiliser des barres obliques inverses (`` \ '') à la fin des lignes pour fusionner les lignes.
Cette syntaxe est influencée par la syntaxe du shell, mais seuls les métacaractères et les expansions décrits ci-dessous sont interprétés, et les expansions de variables sont différentes.
Plus précisément, redirigez en utilisant <, <<, > , >>, pipe en utilisant |, & L'exécution du programme en arrière-plan utilisé et les autres éléments de la syntaxe du shell ne sont pas pris en charge.
La commande que vous exécutez peut contenir des espaces, mais vous ne pouvez pas utiliser de caractères de contrôle.
La ligne de commande accepte le spécificateur ``% '', comme décrit dans systemd.unit (5).
La substitution des variables d'environnement de base est prise en charge.
Si vous utilisez $ {FOO} '' sur la ligne de commande comme partie d'un mot ou comme un seul mot $ {FOO} '' est remplacé par la valeur de la variable d'environnement (y compris les blancs), remplacé par la valeur de la variable d'environnement séparée par des blancs, zéro ou plusieurs arguments sont générés et convertis en un seul argument. Sera fait.
Si vous utilisez `` $ FOO '' comme un autre mot sur la ligne de commande
Les citations ont la priorité lors de la division en mots, puis supprimées.
Si la commande n'est pas un chemin complet (absolu), elle sera résolue en un chemin complet en utilisant un chemin de recherche fixe déterminé au moment de la compilation.
Les répertoires recherchés sont / usr / bin / '' et / usr / local / bin / '', / usr / bin / '' pour les systèmes qui utilisent le répertoire / bin / ''. , / bin / '' et le sbin / '' correspondant pour les systèmes qui utilisent bin / '', sbin / ''.
Par conséquent, il est prudent d'utiliser uniquement le nom de fichier exécutable pour les exécutables situés dans l'un des répertoires "standard", et le chemin absolu doit être utilisé s'il ne se trouve pas dans le répertoire standard.
Il est recommandé d'utiliser des chemins absolus pour éviter toute ambiguïté.
Astuce: Vous pouvez interroger ce chemin de recherche en utilisant le `` systemd-path search-binaries-default ''.
Exemple de description
Environment="ONE=one" 'TWO=two two'
ExecStart=echo $ONE $TWO ${TWO}
Dans cet exemple, / bin / echo est exécuté avec 4 arguments.
Exemple de description
Environment=ONE='one' "TWO='two two' too" THREE=
ExecStart=/bin/echo ${ONE} ${TWO} ${THREE}
ExecStart=/bin/echo $ONE $TWO $THREE
Cela appellera / bin / echo deux fois, d'abord avec les arguments 'one' '', 'two two' too, "" ``, puis
La deuxième fois, il est appelé avec les arguments «« un »,« deux deux »,« aussi ».
Utilisez `` $$ '' pour passer le signe dollar littéral. Les variables dont la valeur est inconnue lorsqu'elles sont développées sont traitées comme des chaînes vides. Notez que le premier argument (c'est-à-dire le programme à exécuter) peut ne pas être une variable.
Les variables utilisées de cette manière peuvent être définies par ʻEnvironment convenablement et ʻEnvironmentFile séparément.
Vous pouvez également utiliser les variables considérées comme "configuration statique" répertoriées dans la section "Variables d'environnement pour les processus générés" de systemd.exec (5) (cela inclut $ USER. N'inclut pas `` $ TERM '').
Veuillez noter que les lignes de commande shell ne sont pas directement prises en charge. Si vous utilisez la ligne de commande shell, vous devez la transmettre explicitement à une implémentation shell.
Exemple de description
ExecStart=sh -c 'dmesg | tac'
Exemple de description
ExecStart=echo one ; echo "two two"
Cela fait que l'écho s'exécute deux fois, chacun avec un argument, respectivement «un» et «deux deux». Vous devez utiliser `` Type = onehot '' car deux commandes sont spécifiées.
Exemple de description
ExecStart=echo / >/dev/null & \; \
ls
Dans cet exemple, echo est exécuté avec 5 arguments.
/>/dev/null&;ls** Tableau 3. Échappements C pris en charge sur les lignes de commande et les variables d'environnement **
| littéral | Valeur actuelle |
|---|---|
\a |
bell |
\b |
backspace |
\f |
form feed |
\n |
newline |
\r |
carriage return |
\t |
tab |
\v |
vertical tab |
\\ |
backslash |
\" |
double citation |
\' |
Guillemets |
\s |
space |
\xxx |
Numéro de caractère codé hexagonal xx |
\nnn |
Huitième numéro de caractère d'encodage nnn |
Le fichier d'unité suivant crée un service qui exécute / usr / sbin / foo-daemon ''. La valeur par défaut Type = simple`` est utilisée car Type = n'est pas spécifié.
systemd s'attend à ce que l'unité démarre peu de temps après le démarrage du programme.
[Unit]
Description=Foo
[Service]
ExecStart=/usr/sbin/foo-daemon
[Install]
WantedBy=multi-user.target
Notez que dans cet exemple, systemd suppose que le processus démarré par systemd continuera d'exister jusqu'à la fin du service. Si votre programme se démonise (comme un fork), utilisez plutôt `` Type = forking ''.
Puisque ExecStop = n'est pas spécifié, systemd envoie SIGTERM à tous les processus démarrés à partir de ce service et SIGKILL même après l'expiration du délai.
Ce comportement peut être modifié.
Voir systemd.kill (5) pour plus d'informations.
Ce type d'unité n'inclut pas de notification lorsque l'initialisation du service est terminée.
Type = notify si le service comprend le protocole de notification systemd, Type = forking si le service peut se gérer en arrière-plan, et l'unité donnera le nom DBus une fois l'initialisation terminée. Vous devez utiliser un autre type d'unité, tel que `` Type = dbus '', pour l'obtenir.
Veuillez vous référer à ce qui suit.
Les unités peuvent avoir besoin de prendre des mesures sans maintenir un processus actif, telles que les vérifications du système de fichiers et les actions de nettoyage au démarrage.
Type = onehot existe pour de tels cas.
Ce type d'unité attend que le processus spécifié se termine avant de redevenir inactif.
Les unités suivantes effectuent des actions de nettoyage:
[Unit]
Description=Cleanup old Foo data
[Service]
Type=oneshot
ExecStart=/usr/sbin/foo-cleanup
[Install]
WantedBy=multi-user.target
systemd considère que l'unité est dans l'état `` de départ '' jusqu'à la fin du programme. Par conséquent, les dépendances ordonnées démarrent une fois le programme terminé. L'unité retournera à l'état «inactif» une fois l'exécution terminée et ne sera jamais à l'état «actif». Autrement dit, une autre demande de démarrage de l'unité reprend l'action.
Type = oneshot est la seule unité de service qui peut avoir plusieurs ExecStart = spécifiés.
Ils s'exécutent en séquence jusqu'à ce que tous réussissent ou qu'un échoue.
Comme le service OneShot, il existe des unités qui doivent exécuter un programme pour configurer quelque chose, puis exécuter un autre programme pour s'arrêter, mais le processus est actif alors qu'il est considéré comme `` démarré ''. Il reste. Les configurations réseau peuvent entrer dans cette catégorie. Un autre cas d'utilisation est lorsque le service onehot n'est pas exécuté lorsqu'il est appelé en tant que dépendance, mais uniquement pour la première fois.
Par conséquent, systemd connaît le paramètre RemainAfterExit = yes ''. Cela permet à systemd de supposer que l'unité est active si l'action de démarrage se termine avec succès. Cette directive peut être utilisée avec tous les types, mais est plus utile avec Type = onehot '' et Type = simple ''. Si Type = onehot '', systemd attend la fin de l'action de démarrage avant de considérer l'unité comme active, de sorte que la dépendance ne démarrera qu'une fois l'action de démarrage réussie.
Si `` Type = simple '', la dépendance démarrera immédiatement après l'envoi de l'action de démarrage.
Voici un exemple de pare-feu statique simple.
[Unit]
Description=Simple firewall
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/simple-firewall-start
ExecStop=/usr/local/sbin/simple-firewall-stop
[Install]
WantedBy=multi-user.target
Une fois l'action de démarrage terminée, l'unité est considérée comme en cours d'exécution, donc appeler à nouveau `` systemctl start '' sur cette unité ne prendra aucune action.
De nombreux arrière-plans de démons / services traditionnels (c'est-à-dire fork '', daemonize '') se mettent en arrière-plan au démarrage.
Pour prendre en charge ce mode de fonctionnement, définissez Type = fourchette '' dans le fichier d'unité du service. systemd considère que le service est en cours d'initialisation alors que le programme d'origine est toujours en cours d'exécution. Le service est considéré comme démarré s'il se termine avec succès et au moins le processus reste (ou RemainAfterExit = no '').
Les démons traditionnels consistent souvent en un seul processus.
Par conséquent, s'il ne reste qu'un seul processus après la fin du processus d'origine, systemd considère que ce processus est le processus principal du service.
Dans ce cas, la variable $ MAINPID peut être utilisée avec ExecReload =, ExecStop =, etc.
S'il reste plus d'un processus, systemd ne peut pas déterminer le processus principal et ne le suppose pas.
Dans ce cas, $ MAINPID ne sera pas développé.
Cependant, si le processus décide d'écrire un fichier PID traditionnel, systemd peut y lire le PID principal.
Définissez PIDFile = comme il convient.
Notez que le démon doit écrire le fichier PID avant de pouvoir terminer l'initialisation.
Sinon, systemd peut essayer de lire le fichier PID avant qu'il ne soit généré.
L'exemple suivant montre un démon simple qui se branche et démarre un processus en arrière-plan:
[Unit]
Description=Some simple daemon
[Service]
Type=forking
ExecStart=/usr/sbin/my-simple-daemon -d
[Install]
WantedBy=multi-user.target
Voir systemd.kill (5) pour plus d'informations sur la façon dont systemd affecte la façon dont il met fin au service.
Pour les services qui obtiennent leur nom sur le bus système DBus, utilisez Type = dbus et définissez le BusName = correspondant.
Les services ne doivent pas être fourchus (diabolisés).
systemd considère le service initialisé lorsque le nom est récupéré sur le bus système.
L'exemple suivant montre un service DBus typique.
[Unit]
Description=Simple DBus service
[Service]
Type=dbus
BusName=org.example.simple-dbus-service
ExecStart=/usr/sbin/simple-dbus-service
[Install]
WantedBy=multi-user.target
Pour les services qui peuvent être activés sur le bus, n'incluez pas la section [Install] '' dans le fichier de service systemd. À la place, utilisez l'option SystemdService de manière appropriée dans le fichier de service DBus correspondant.
Par exemple (/usr/share/dbus-1/system-services/org.example.simple-dbus-service.service):
[D-BUS Service]
Name=org.example.simple-dbus-service
Exec=/usr/sbin/simple-dbus-service
User=root
SystemdService=simple-dbus-service.service
Voir systemd.kill (5) pour plus d'informations sur la façon dont systemd affecte la façon dont il met fin au service.
Les services avec Type = simple '' sont très faciles à écrire, mais ils présentent l'inconvénient majeur de ne pas pouvoir notifier à systemd que l'initialisation d'un service particulier est terminée. Pour cette raison, systemd prend en charge un protocole de notification simple qui permet au démon de faire savoir à systemd que l'initialisation est terminée. Utilisez Type = notifier '' pour cela.
Un fichier de service typique pour un tel démon ressemble à ceci:
[Unit]
Description=Simple notifying service
[Service]
Type=notify
ExecStart=/usr/sbin/simple-notifying-service
[Install]
WantedBy=multi-user.target
Notez que le démon doit prendre en charge le protocole de notification systemd. Sinon, systemd considère que le service n'est pas encore démarré et le tue après un délai d'expiration. Voir sd_notify (3) pour des informations sur la façon de mettre à jour le démon pour prendre en charge de manière transparente ce protocole. systemd considère que l'unité est à l'état `` de démarrage '' jusqu'à ce qu'une notification prête arrive.
Voir systemd.kill (5) pour plus d'informations sur la façon dont systemd affecte la façon dont il met fin au service.
SEE ALSO
NOTES
Recommended Posts