Comprendre les unités et les fichiers d’unités Systemd

introduction

De plus en plus, les distributions Linux adoptent ou prévoient d’adopter le système init + systemd +. Cette suite logicielle puissante peut gérer de nombreux aspects de votre serveur, des services aux périphériques montés et aux états du système.

Dans + systemd +, un + unit + fait référence à toute ressource que le système sait comment utiliser et gérer. C’est l’objet principal que les outils + systemd + savent traiter. Ces ressources sont définies à l’aide de fichiers de configuration appelés fichiers d’unités.

Dans ce guide, nous vous présenterons les différentes unités que + systemd + peut gérer. Nous aborderons également certaines des nombreuses directives pouvant être utilisées dans les fichiers unité afin de définir la manière dont ces ressources sont gérées sur votre système.

Que vous donnent les unités Systemd?

Les unités sont les objets que + systemd + sait gérer. Il s’agit essentiellement d’une représentation normalisée des ressources système pouvant être gérées par la suite de démons et manipulées par les utilitaires fournis.

À certains égards, les unités peuvent être assimilées à des services ou à des tâches d’autres systèmes init. Cependant, une unité a une définition beaucoup plus large car elle peut être utilisée pour résumer des services, des ressources réseau, des périphériques, des montages de système de fichiers et des pools de ressources isolés.

Les idées qui, dans d’autres systèmes init, peuvent être traitées avec une définition de service unifiée peuvent être divisées en unités de composants en fonction de leur objectif. Cela organise par fonction et vous permet d’activer, de désactiver ou d’étendre facilement des fonctionnalités sans modifier le comportement de base d’une unité.

Certaines fonctionnalités que les unités peuvent implémenter facilement sont:

* activation basée sur les sockets *: les sockets associés à un service sont mieux dissociés du démon lui-même afin d’être gérés séparément. Cela offre un certain nombre d’avantages, tels que le fait de retarder le début d’un service jusqu’à ce que le socket associé soit d’abord accédé. Cela permet également au système de créer tous les sockets au début du processus de démarrage, ce qui permet de démarrer les services associés en parallèle.
* activation basée sur le bus *: les unités peuvent également être activées sur l’interface de bus fournie par + D-Bus +. Une unité peut être démarrée lorsqu’un bus associé est publié.
* activation par chemin *: une unité peut être démarrée en fonction de l’activité ou de la disponibilité de certains chemins du système de fichiers. Ceci utilise + inotify +.
* activation par périphérique *: les unités peuvent également être démarrées dès la première disponibilité du matériel associé en exploitant les événements + udev +.
* mappage de dépendance implicite *: La plupart des arbres de dépendance pour les unités peuvent être construits par + systemd + lui-même. Vous pouvez toujours ajouter des informations sur les dépendances et les commandes, mais la plupart des tâches lourdes sont prises en charge pour vous.
* instances et modèles *: les fichiers d’unité de modèle peuvent être utilisés pour créer plusieurs instances de la même unité générale. Cela permet de légères variations ou des unités sœurs qui remplissent toutes la même fonction générale.
* Renforcement de la sécurité facile *: Les unités peuvent implémenter des fonctionnalités de sécurité relativement bonnes en ajoutant de simples directives. Par exemple, vous pouvez spécifier un accès non lu ou en lecture seule à une partie du système de fichiers, limiter les capacités du noyau et attribuer un accès privé + / tmp + et un accès réseau.
* Drop-ins et extraits *: Les unités peuvent facilement être étendues en fournissant des extraits qui remplaceront des parties du fichier d’unités du système. Cela facilite le basculement entre les implémentations vanilla et les unités personnalisées.

Les unités `+ systemd + 'ont de nombreux autres avantages sur les éléments de travail d’autres systèmes d’initialisation, mais cela devrait vous donner une idée de la puissance qui peut être exploitée à l’aide de directives de configuration natives.

Où se trouvent les fichiers d’unité Systemd?

Les fichiers qui définissent la manière dont + systemd + gérera une unité peuvent être trouvés dans de nombreux emplacements différents, chacun ayant des priorités et des implications différentes.

La copie système des fichiers d’unité est généralement conservée dans le répertoire + / lib / systemd / system +. Lorsqu’un logiciel installe des fichiers d’unité sur le système, il s’agit de l’emplacement où ils sont placés par défaut.

Les fichiers d’unité stockés ici peuvent être démarrés et arrêtés à la demande pendant une session. Il s’agit du fichier unité générique vanilla, souvent écrit par les responsables du projet en amont, qui doit fonctionner sur tout système déployant + systemd + dans son implémentation standard. Vous ne devriez pas éditer de fichiers dans ce répertoire. Au lieu de cela, vous devez remplacer le fichier, si nécessaire, en utilisant un autre emplacement de fichier d’unité qui remplacera le fichier à cet emplacement.

Si vous souhaitez modifier le fonctionnement d’une unité, le meilleur emplacement pour le faire est situé dans le répertoire + / etc / systemd / system +. Les fichiers d’unité trouvés dans cet emplacement de répertoire ont priorité sur les autres emplacements du système de fichiers. Si vous devez modifier la copie système d’un fichier d’unité, le remplacement de ce répertoire est la méthode la plus sûre et la plus flexible.

Si vous souhaitez remplacer uniquement des directives spécifiques du fichier unité du système, vous pouvez réellement fournir des extraits de fichier unité dans un sous-répertoire. Ceux-ci ajouteront ou modifieront les directives de la copie du système, vous permettant de spécifier uniquement les options que vous souhaitez modifier.

La bonne façon de faire est de créer un répertoire nommé d’après le fichier d’unité avec + .d + ajouté à la fin. Ainsi, pour une unité appelée + exemple.service +, un sous-répertoire appelé + exemple.service.d + pourrait être créé. Dans ce répertoire, un fichier se terminant par + .conf + peut être utilisé pour remplacer ou étendre les attributs du fichier unité du système.

Il existe également un emplacement pour les définitions d’unités d’exécution à l’emplacement + / run / systemd / system. Les fichiers d’unité trouvés dans ce répertoire ont une priorité d’atterrissage entre ceux de + / etc / systemd / system + et + / lib / systemd / system +. Les fichiers de cet emplacement ont moins de poids que le premier, mais plus que le dernier.

Le processus + systemd + lui-même utilise cet emplacement pour les fichiers unité créés de manière dynamique et créés au moment de l’exécution. Ce répertoire peut être utilisé pour modifier le comportement de l’unité du système pendant la durée de la session. Toutes les modifications effectuées dans ce répertoire seront perdues lors du redémarrage du serveur.

Types d’unités

+ Systemd + catégorise les unités en fonction du type de ressource décrit. Le moyen le plus simple de déterminer le type d’une unité est d’utiliser son suffixe de type, qui est ajouté à la fin du nom de la ressource. La liste suivante décrit les types d’unités disponibles pour + systemd +:

* + .service + *: une unité de service décrit comment gérer un service ou une application sur le serveur. Cela inclura comment démarrer ou arrêter le service, dans quelles circonstances il devrait être démarré automatiquement, ainsi que les informations de dépendance et de commande des logiciels associés.
* + .socket + *: un fichier d’unité de socket décrit un socket réseau ou IPC ou un tampon FIFO que + systemd + utilise pour l’activation par socket. Ceux-ci ont toujours un fichier + .service + associé qui sera démarré lorsque l’activité sera vue sur le socket défini par cette unité.
* + .device + *: Unité qui décrit un périphérique désigné comme nécessitant une gestion + systemd + par + udev + ou le système de fichiers + sysfs +. Tous les appareils n’auront pas les fichiers + .device +. Certains scénarios dans lesquels des unités + .device + peuvent être nécessaires concernent la commande, le montage et l’accès aux périphériques.
* + .mount + *: Cette unité définit un point de montage sur le système à gérer par + systemd +. Ceux-ci sont nommés d’après le chemin de montage, les barres obliques étant modifiées en tirets. Les entrées dans + / etc / fstab + peuvent avoir des unités créées automatiquement.
* + .automount + *: Une unité + .automount + configure un point de montage qui sera monté automatiquement. Ceux-ci doivent être nommés d’après le point de montage auquel ils font référence et doivent avoir une unité + .mount + correspondante pour définir les spécificités du montage.
* + .swap + *: Cette unité décrit l’espace de permutation sur le système. Le nom de ces unités doit refléter le chemin d’accès au périphérique ou au fichier de l’espace.
* + .target + *: une unité cible sert à fournir des points de synchronisation aux autres unités lors du démarrage ou de la modification d’états. Ils peuvent également être utilisés pour amener le système dans un nouvel état. D’autres unités précisent leur relation avec les cibles à lier aux opérations de la cible.
* + .path + *: Cette unité définit un chemin pouvant être utilisé pour une activation basée sur le chemin. Par défaut, une unité + .service + du même nom de base sera démarrée lorsque le chemin d’accès atteindra l’état spécifié. Ceci utilise + inotify + pour surveiller le chemin des modifications.
* + .timer + *: Une unité + .timer + définit un temporisateur qui sera géré par + systemd +, similaire à un travail + cron + pour une activation retardée ou planifiée. Une unité correspondante démarrera lorsque le chronomètre sera atteint.
* + .snapshot + *: Une unité + .snapshot + est créée automatiquement par la commande + systemctl snapshot +. Il vous permet de reconstruire l’état actuel du système après avoir apporté des modifications. Les instantanés ne survivent pas d’une session à l’autre et sont utilisés pour restaurer des états temporaires.
* + .slice + *: une unité + .slice + est associée aux nœuds du groupe de contrôle Linux, ce qui permet de restreindre les ressources ou d’attribuer des processus à tous les processus associés à la tranche. Le nom reflète sa position hiérarchique dans l’arborescence + cgroup +. Les unités sont placées dans certaines tranches par défaut en fonction de leur type.
* + .scope + *: Les unités d’étendue sont créées automatiquement par + systemd + à partir d’informations reçues de ses interfaces de bus. Ils permettent de gérer des ensembles de processus système créés en externe.

Comme vous pouvez le constater, il existe de nombreuses unités différentes que + systemd + sait gérer. De nombreux types d’unités fonctionnent ensemble pour ajouter des fonctionnalités. Par exemple, certaines unités sont utilisées pour déclencher d’autres unités et fournissent une fonctionnalité d’activation.

Nous nous concentrerons principalement sur les unités + .service + en raison de leur utilité et de la cohérence avec laquelle les administrateurs doivent gérer ces unités.

Anatomie d’un fichier unité

La structure interne des fichiers d’unité est organisée en sections. Les sections sont indiquées par une paire de crochets «` + [+ » et « +] + `» avec le nom de la section entre eux. Chaque section s’étend jusqu’au début de la section suivante ou jusqu’à la fin du fichier.

Caractéristiques générales des fichiers d’unité

Les noms de section sont bien définis et respectent la casse. Ainsi, la section + [Unité] + ne sera * pas * interprétée correctement si elle est orthographiée comme + [UNIT] +. Si vous devez ajouter des sections non standard à analyser par des applications autres que + systemd +, vous pouvez ajouter un préfixe + X- + au nom de la section.

Dans ces sections, le comportement de l’unité et les métadonnées sont définis à l’aide de directives simples utilisant un format clé-valeur avec une affectation indiquée par un signe égal, comme ci-dessous:

[]
=
=

. . .

En cas de fichier de substitution (tel que ceux contenus dans un répertoire + .. d +), les directives peuvent être réinitialisées en les affectant à une chaîne vide. Par exemple, la copie système d’un fichier unité peut contenir une directive définie sur une valeur comme celle-ci:

Le + default_value + peut être éliminé dans un fichier de substitution en référençant ++ sans valeur, comme ceci:

En général, + systemd + permet une configuration simple et flexible. Par exemple, plusieurs expressions booléennes sont acceptées ("+ 1 ", " oui ", " sur " et " vrai " pour affirmatif et " 0 ", " non +", + off + "et" + faux + `pour la réponse opposée). Les temps peuvent être intelligemment analysés, les secondes étant supposées pour les valeurs sans unité et combinant plusieurs formats réalisés en interne.

Directives de section [Unité]

La première section présente dans la plupart des fichiers unité est la section + [Unité] +. Ceci est généralement utilisé pour définir les métadonnées de l’unité et configurer la relation entre l’unité et les autres unités.

Bien que l’ordre des sections ne soit pas important pour + systemd + lors de l’analyse du fichier, cette section est souvent placée en haut de la liste car elle fournit une vue d’ensemble de l’unité. Certaines directives courantes que vous trouverez dans la section + [Unit] + sont:

* + Description = + *: Cette directive peut être utilisée pour décrire le nom et les fonctionnalités de base de l’unité. Il est renvoyé par divers outils + systemd +, il est donc judicieux de le définir sur quelque chose de court, spécifique et informatif.
* + Documentation = + *: Cette directive fournit un emplacement pour une liste d’URI pour la documentation. Celles-ci peuvent être des pages + man + disponibles en interne ou des URL accessibles sur le Web. La commande + systemctl status exposera ces informations, ce qui facilitera la découverte.
* + Requiert = + *: Cette directive répertorie toutes les unités dont dépend essentiellement cette unité. Si l’unité actuelle est activée, les unités répertoriées ici doivent également être activées avec succès, sinon cette unité échouera. Ces unités sont démarrées en parallèle avec l’unité actuelle par défaut.
* + Wants = + *: Cette directive est similaire à + requiert = +, mais moins stricte. + Systemd + tentera de démarrer toutes les unités listées ici lorsque cette unité est activée. Si ces unités ne sont pas trouvées ou ne démarrent pas, l’unité actuelle continuera à fonctionner. C’est la méthode recommandée pour configurer la plupart des relations de dépendance. Là encore, cela implique une activation parallèle, sauf modification par d’autres directives.
* + BindsTo = + *: Cette directive est similaire à + requiert = +, mais provoque également l’arrêt de l’unité en cours à la fin de l’unité associée.
* + Before = + *: Les unités répertoriées dans cette directive ne seront pas démarrées tant que l’unité en cours ne sera pas démarquée si elles sont activées simultanément. Cela n’implique pas une relation de dépendance et doit être utilisé conjointement avec l’une des directives ci-dessus si cela est souhaité.
* + After = + *: Les unités listées dans cette directive seront démarrées avant de démarrer l’unité en cours. Cela n’implique pas une relation de dépendance et il faut en établir une au moyen des directives ci-dessus, le cas échéant.
* + Conflicts = + *: Ceci peut être utilisé pour lister les unités qui ne peuvent pas être exécutées en même temps que l’unité actuelle. Si vous démarrez une unité avec cette relation, les autres unités seront arrêtées.
* + Condition … = + *: Un certain nombre de directives commençant par + Condition + permettent à l’administrateur de tester certaines conditions avant de démarrer l’unité. Ceci peut être utilisé pour fournir un fichier unité générique qui ne sera exécuté que sur les systèmes appropriés. Si la condition n’est pas remplie, l’unité est gracieusement ignorée.
* + Assert … = + *: Semblables aux directives commençant par + Condition +, ces directives recherchent différents aspects de l’environnement en cours d’exécution pour décider si l’unité doit être activée. Cependant, contrairement aux directives + Condition +, un résultat négatif provoque un échec avec cette directive.

À l’aide de ces directives et d’une poignée d’autres, il est possible d’établir des informations générales sur l’unité et ses relations avec les autres unités et le système d’exploitation.

Directives de section [Installer]

Sur le côté opposé du fichier de l’unité, la dernière section est souvent la section + [Install] +. Cette section est facultative et permet de définir le comportement ou une unité s’il est activé ou désactivé. L’activation d’une unité marque son démarrage automatique au démarrage. Pour ce faire, l’unité en question est verrouillée sur une autre unité située quelque part dans la ligne des unités à démarrer au démarrage.

Pour cette raison, seules les unités pouvant être activées auront cette section. Les directives à l’intérieur dictent ce qui doit se passer lorsque l’unité est activée:

* + WantedBy = + *: La directive + WantedBy = + est le moyen le plus courant de spécifier comment une unité doit être activée. Cette directive vous permet de spécifier une relation de dépendance de la même manière que la directive + Wants = + dans la section + [Unit] +. La différence est que cette directive est incluse dans l’unité auxiliaire, ce qui permet à l’unité principale répertoriée de rester relativement propre. Quand une unité avec cette directive est activée, un répertoire sera créé dans + / etc / systemd / system + et porte le nom de l’unité spécifiée avec + .wants + ajouté à la fin. Dans ce cadre, un lien symbolique vers l’unité en cours sera créé, créant la dépendance. Par exemple, si l’unité en cours a + WantedBy = multi-user.target +, un répertoire nommé + multi-user.target.wants + sera créé dans + / etc / systemd / system + (s’il n’est pas déjà disponible). ) et un lien symbolique vers l’unité actuelle y sera placé. La désactivation de cette unité supprime le lien et supprime la relation de dépendance.
* + RequiredBy = + *: Cette directive est très similaire à la directive + WantedBy = +, mais spécifie à la place une dépendance requise qui entraînera l’échec de l’activation si elle n’est pas respectée. Lorsqu’elle est activée, une unité avec cette directive créera un répertoire se terminant par + .requires +.
* + Alias = + *: Cette directive permet également d’activer l’unité sous un autre nom. Parmi d’autres utilisations, cela permet à plusieurs fournisseurs d’une fonction d’être disponibles, de sorte que les unités associées puissent rechercher n’importe quel fournisseur du nom commun avec alias.
* + Also = + *: Cette directive permet d’activer ou de désactiver les unités en tant qu’ensemble. Les unités de support qui devraient toujours être disponibles lorsque cette unité est active peuvent être listées ici. Ils seront gérés en tant que groupe pour les tâches d’installation.
* + DefaultInstance = + *: Pour les unités de modèle (traitées ultérieurement) pouvant générer des instances d’unités avec des noms imprévisibles, cette valeur peut être utilisée comme valeur de secours pour le nom si aucun nom approprié n’est fourni.

Directives de section spécifiques à une unité

Pris en sandwich entre les deux sections précédentes, vous trouverez probablement des sections spécifiques au type d’unité. La plupart des types d’unités offrent des directives qui ne s’appliquent qu’à leur type spécifique. Ceux-ci sont disponibles dans les sections nommées d’après leur type. Nous allons couvrir ceux brièvement ici.

Les types d’unité + device,` + target`, + snapshot et` + scope of` n’ont pas de directives spécifiques à l’unité, et n’ont donc pas de sections associées pour leur type.

La section [Service]

La section + [Service] + sert à fournir une configuration qui ne s’applique qu’aux services.

L’un des éléments de base à spécifier dans la section + [Service] + est le + Type = + du service. Cela classe les services en fonction de leur processus et de leur comportement de démonisation. Ceci est important car il indique + systemd + comment gérer correctement le service et connaître son état.

La directive + Type = + peut être l’une des suivantes:

* simple *: le processus principal du service est spécifié dans la ligne de départ. Ceci est la valeur par défaut si les directives + Type = + et + Busname = + ne sont pas définies, alors que les commandes + ExecStart = + sont définies. Toute communication doit être gérée en dehors de l’unité via une seconde unité du type approprié (par exemple, via une unité + .socket + si cette unité doit communiquer à l’aide de sockets).
* forking *: ce type de service est utilisé lorsque le service divise un processus enfant en quittant le processus parent presque immédiatement. Ceci indique + systemd + que le processus est toujours en cours même si le parent est sorti.
* onehot *: Ce type indique que le processus sera de courte durée et que + systemd + devrait attendre que le processus se termine avant de continuer avec d’autres unités. Ceci est la valeur par défaut + Type = + et + ExecStart = + ne sont pas définis. Il est utilisé pour des tâches uniques.
* dbus *: Ceci indique que l’unité prendra un nom sur le bus D-Bus. Lorsque cela se produit, + systemd + continuera à traiter l’unité suivante.
* notify *: Cela indique que le service enverra une notification une fois son démarrage terminé. Le processus + systemd + attendra que cela se produise avant de passer aux autres unités.
* inactif *: Cela indique que le service ne sera pas exécuté tant que tous les travaux ne seront pas distribués.

Certaines directives supplémentaires peuvent être nécessaires lors de l’utilisation de certains types de services. Par exemple:

* + RemainAfterExit = + *: Cette directive est couramment utilisée avec le type + oneshot +. Cela indique que le service doit être considéré comme actif même après la fin du processus.
* + PIDFile = + *: Si le type de service est marqué comme «forking», cette directive permet de définir le chemin du fichier devant contenir le numéro d’ID de processus de l’enfant principal à surveiller.
* + BusName = + *: Cette directive doit être définie sur le nom du bus D-Bus que le service tentera d’acquérir lors de l’utilisation du type de service «dbus».
* + NotifyAccess = + *: Ceci spécifie l’accès au socket qui doit être utilisé pour écouter les notifications lorsque le type de service "notify" est sélectionné. Cela peut être "none", "main" ou "all". La valeur par défaut, "aucun", ignore tous les messages d’état. L’option «principale» écoute les messages du processus principal et l’option «tous» entraîne le traitement de tous les membres du groupe de contrôle du service.

Jusqu’ici, nous avons discuté de certaines informations préalables, mais nous n’avons pas encore défini comment gérer nos services. Les directives à suivre sont les suivantes:

* + ExecStart = + *: Ceci spécifie le chemin d’accès complet et les arguments de la commande à exécuter pour démarrer le processus. Cela ne peut être spécifié qu’une seule fois (sauf pour les services «one-shot»). Si le chemin d’accès à la commande est précédé d’un tiret «-», les états de sortie non nuls seront acceptés sans marquer l’activation de l’unité comme ayant échoué.
* + ExecStartPre = + *: Ceci peut être utilisé pour fournir des commandes supplémentaires à exécuter avant le démarrage du processus principal. Cela peut être utilisé plusieurs fois. De nouveau, les commandes doivent spécifier un chemin complet et elles peuvent être précédées de «-» pour indiquer que l’échec de la commande sera toléré.
* + ExecStartPost = + *: Cela a exactement les mêmes qualités que + ExecStartPre = + sauf qu’il spécifie les commandes qui seront exécutées _après le processus principal démarré.
* + ExecReload = + *: Cette directive facultative indique la commande nécessaire pour recharger la configuration du service, le cas échéant.
* + ExecStop = + *: Ceci indique la commande nécessaire pour arrêter le service. Si ce n’est pas donné, le processus sera tué immédiatement lorsque le service est arrêté.
* + ExecStopPost = + *: Ceci peut être utilisé pour spécifier les commandes à exécuter après la commande stop.
* + RestartSec = + *: si le redémarrage automatique du service est activé, cela indique le délai d’attente avant de tenter de redémarrer le service.
* + Restart = + *: Ceci indique les circonstances dans lesquelles + systemd + tentera de redémarrer automatiquement le service. Cela peut être réglé sur des valeurs telles que «toujours», «en cas de succès», «en cas d’échec», «en cas d’anormal», «en cas d’abandon» ou de «en surveillance». Celles-ci déclencheront un redémarrage en fonction de la manière dont le service a été arrêté.
* + TimeoutSec = + *: Ceci configure la durée pendant laquelle + systemd + attend lors de l’arrêt ou de l’arrêt du service avant de le marquer comme ayant échoué ou de le tuer de force. Vous pouvez également définir des timeouts séparés avec + TimeoutStartSec = + et + TimeoutStopSec = +.

La section [Socket]

Les unités de socket sont très courantes dans les configurations + systemd + car de nombreux services implémentent l’activation par socket pour améliorer la parallélisation et la flexibilité. Chaque socket doit avoir une unité de service correspondante qui sera activée lorsque le socket recevra une activité.

En coupant le contrôle de socket en dehors du service lui-même, les sockets peuvent être initialisés tôt et les services associés peuvent souvent être démarrés en parallèle. Par défaut, le nom du socket tentera de démarrer le service du même nom lors de la connexion. Une fois le service initialisé, le socket lui sera transmis, ce qui lui permettra de commencer à traiter les demandes mises en mémoire tampon.

Pour spécifier le socket actuel, ces directives sont communes:

* + ListenStream = + *: définit une adresse pour un socket de flux qui prend en charge une communication fiable et séquentielle. Les services utilisant TCP doivent utiliser ce type de socket.
* + ListenDatagram = + *: Ceci définit une adresse pour un socket de datagramme qui prend en charge des paquets de communication rapides et peu fiables. Les services qui utilisent UDP doivent définir ce type de socket.
* + ListenSequentialPacket = + *: définit une adresse pour une communication fiable et séquentielle avec des datagrammes de longueur maximale qui préserve les limites des messages. Ceci se trouve le plus souvent pour les sockets Unix.
* + ListenFIFO + *: Outre les autres types d’écoute, vous pouvez également spécifier un tampon FIFO au lieu d’une prise.

Il existe plus de types de directives d’écoute, mais celles ci-dessus sont les plus courantes.

D’autres caractéristiques des prises peuvent être contrôlées par des directives supplémentaires:

* + Accept = + *: Ceci détermine si une instance supplémentaire du service sera démarrée pour chaque connexion. Si la valeur est false (valeur par défaut), une instance gérera toutes les connexions.
* + SocketUser = + *: Avec un socket Unix, spécifie le propriétaire du socket. Ce sera l’utilisateur root s’il n’est pas défini.
* + SocketGroup = + *: Avec un socket Unix, spécifie le propriétaire du groupe du socket. Ce sera le groupe racine si ni ceci ni celui ci-dessus ne sont définis. Si seul le + SocketUser = + est défini, + systemd + essayera de trouver un groupe correspondant.
* + SocketMode = + *: Pour les sockets Unix ou les tampons FIFO, définit les autorisations sur l’entité créée.
* + Service = + *: Si le nom du service ne correspond pas au nom + .socket +, le service peut être spécifié avec cette directive.

La section [Mount]

Les unités de montage permettent la gestion des points de montage à partir de + systemd +. Les points de montage portent le nom du répertoire qu’ils contrôlent, avec un algorithme de traduction appliqué.

Par exemple, la barre oblique est supprimée, toutes les autres sont traduites en tirets “-”, et tous les tirets et les caractères non imprimables sont remplacés par des codes d’échappement de style C. Le résultat de cette traduction est utilisé comme nom de l’unité de montage. Les unités de montage auront une dépendance implicite par rapport aux autres montages situés au-dessus dans la hiérarchie.

Les unités de montage sont souvent traduites directement à partir des fichiers + / etc / fstab + pendant le processus de démarrage. Pour les définitions d’unités créées automatiquement et celles que vous souhaitez définir dans un fichier d’unités, les directives suivantes sont utiles:

* + What = + *: chemin absolu de la ressource à monter.
* + Where = + *: chemin absolu du point de montage sur lequel la ressource doit être montée. Ce nom devrait être identique au nom de fichier de l’unité, à l’exception de la notation conventionnelle du système de fichiers.
* + Type = + *: Le type de système de fichiers du montage.
* + Options = + *: Toutes les options de montage à appliquer. Ceci est une liste séparée par des virgules.
* + SloppyOptions = + *: Un booléen qui détermine si le montage échouera s’il existe une option de montage non reconnue.
* + DirectoryMode = + *: Si des répertoires parent doivent être créés pour le point de montage, cela détermine le mode de permission de ces répertoires.
* + TimeoutSec = + *: Configure la durée pendant laquelle le système attendra que l’opération de montage soit marquée comme ayant échoué.

La section [Automount]

Cette unité permet à une unité + .mount + associée d’être automatiquement montée au démarrage. Comme pour les unités + .mount +, ces unités doivent être nommées en fonction du chemin du point de montage traduit.

La section + [Automount] + est assez simple, avec seulement les deux options suivantes autorisées:

* + Where = + *: chemin absolu du point de montage automatique sur le système de fichiers. Cela correspond au nom de fichier, sauf qu’il utilise la notation de chemin conventionnelle au lieu de la traduction.
* + DirectoryMode = + *: Si le point de montage automatique ou des répertoires parents doivent être créés, cela déterminera les paramètres de permissions de ces composants de chemin.

La section [Swap]

Les unités d’échange sont utilisées pour configurer l’espace d’échange sur le système. Les unités doivent porter le nom du fichier d’échange ou du périphérique d’échange, en utilisant la même traduction de système de fichiers que celle décrite ci-dessus.

À l’instar des options de montage, les unités de swap peuvent être créées automatiquement à partir d’entrées + / etc / fstab + ou configurées via un fichier d’unité dédié.

La section + [Swap] + d’un fichier unité peut contenir les directives suivantes pour la configuration:

* + What = + *: chemin absolu vers l’emplacement de l’espace de permutation, qu’il s’agisse d’un fichier ou d’un périphérique.
* + Priority = + *: Ceci prend un entier qui indique la priorité de l’échange en cours de configuration.
* + Options = + *: Toutes les options généralement définies dans le fichier + / etc / fstab + peuvent être définies avec cette directive. Une liste séparée par des virgules est utilisée.
* + TimeoutSec = + *: Délai pendant lequel + systemd + attend l’activation du swap avant de marquer l’opération comme un échec.

La section [Path]

Une unité de chemin définit un chemin de système de fichiers que + systmed + peut surveiller les modifications. Il doit exister une autre unité qui sera activée lorsque certaines activités sont détectées à l’emplacement du chemin. L’activité du chemin est déterminée par les événements + inotify.

La section + [Path] + d’un fichier unité peut contenir les directives suivantes:

* + PathExists = + *: Cette directive est utilisée pour vérifier si le chemin en question existe. Si c’est le cas, l’unité associée est activée.
* + PathExistsGlob = + *: Il s’agit de la même chose que ci-dessus, mais prend en charge les expressions de fichier globales pour déterminer l’existence d’un chemin.
* + PathChanged = + *: Ceci surveille l’emplacement du chemin pour les modifications. L’unité associée est activée si une modification est détectée lors de la fermeture du fichier surveillé.
* + PathModified = + *: Ceci surveille les modifications comme la directive ci-dessus, mais il s’active lors des écritures de fichiers ainsi que lors de la fermeture du fichier.
* + DirectoryNotEmpty = + *: Cette directive permet à + systemd + d’activer l’unité associée lorsque le répertoire n’est plus vide.
* + Unit = + *: Ceci spécifie l’unité à activer lorsque les conditions de chemin spécifiées ci-dessus sont remplies. Si ceci est omis, + systemd + recherchera un fichier + .service + qui partage le même nom d’unité de base que cette unité.
* + MakeDirectory = + *: Ceci détermine si + systemd + créera la structure de répertoires du chemin en question avant de regarder.
* + DirectoryMode = + *: Si ce qui précède est activé, cela définira le mode d’autorisation de tous les composants de chemin devant être créés.

La section [minuterie]

Les unités de minuterie sont utilisées pour planifier des tâches à exécuter à une heure précise ou après un certain délai. Ce type d’unité remplace ou complète certaines des fonctionnalités des démons + cron + et + at +. Une unité associée doit être fournie et sera activée lorsque la minuterie est atteinte.

La section + [Timer] + d’un fichier unité peut contenir certaines des directives suivantes:

* + OnActiveSec = + *: Cette directive permet d’activer l’unité associée par rapport à l’activation de l’unité + .timer +.
* + OnBootSec = + *: Cette directive permet de spécifier la durée après le démarrage du système pour l’activation de l’unité associée.
* + OnStartupSec = + *: Cette directive est similaire à la minuterie ci-dessus, mais en relation avec le moment où le processus + systemd + a été démarré.
* + OnUnitActiveSec = + *: Ceci définit une minuterie en fonction de la dernière activation de l’unité associée.
* + OnUnitInactiveSec = + *: Ceci définit la minuterie par rapport au moment où l’unité associée a été marquée comme inactive.
* + OnCalendar = + *: Cela vous permet d’activer l’unité associée en spécifiant un absolu plutôt que par rapport à un événement.
* + AccuracySec = + *: Cet appareil permet de définir le niveau de précision avec lequel le minuteur doit être respecté. Par défaut, l’unité associée sera activée dans la minute qui suit l’atteinte du minuteur. La valeur de cette directive déterminera les limites supérieures de la fenêtre dans laquelle + systemd + planifie l’activation.
* + Unit = + *: Cette directive est utilisée pour spécifier l’unité qui doit être activée lorsque le délai est écoulé. Si non défini, + systemd + cherchera une unité + .service + avec un nom qui correspond à cette unité.
* + Persistent = + * * Si cette option est définie, + systemd + `déclenchera l’unité associée lorsque le minuteur deviendra actif s’il aurait été déclenché pendant la période où il était inactif.
* + WakeSystem = + *: la définition de cette directive vous permet de sortir un système d’une suspension si le minuteur est atteint dans cet état.

La section [tranche]

La section + [Slice] + d’un fichier d’unité n’a en réalité aucune configuration spécifique + .slice +. Au lieu de cela, il peut contenir des directives de gestion des ressources qui sont réellement disponibles pour un certain nombre des unités répertoriées ci-dessus.

Certaines directives courantes de la section + [Slice] +, qui peuvent également être utilisées dans d’autres unités, se trouvent dans la page de manuel + systemd.resource-control +. Ceux-ci sont valables dans les sections suivantes spécifiques à l’unité:

+ [Slice] +
+ [Portée] +
+ [Service] +
+ [Socket] +
+ [Mount] +
+ [Swap] +

Création d’unités d’instance à partir de fichiers d’unité de modèle

Nous avons mentionné précédemment dans ce guide l’idée d’utiliser des fichiers d’unité modèles pour créer plusieurs instances d’unités. Dans cette section, nous pouvons examiner ce concept plus en détail.

Les fichiers unités modèles ne sont, dans la plupart des cas, pas différents des fichiers unités ordinaires. Cependant, ils offrent une flexibilité dans la configuration des unités en permettant à certaines parties du fichier d’utiliser des informations dynamiques qui seront disponibles au moment de l’exécution.

Noms d’unité de modèle et d’instance

Les fichiers d’unité de modèle peuvent être identifiés car ils contiennent un symbole + @ + après le nom de l’unité de base et avant le suffixe de type d’unité. Un nom de fichier d’unité de modèle peut ressembler à ceci:

[email protected]

Lorsqu’une instance est créée à partir d’un modèle, un identificateur d’instance est placé entre le symbole + @ + et la période indiquant le début du type d’unité. Par exemple, le fichier d’unité de modèle ci-dessus peut être utilisé pour créer une unité d’instance ressemblant à ceci:

[email protected]

Un fichier d’instance est généralement créé en tant que lien symbolique vers le fichier de modèle, avec le nom du lien, y compris l’identificateur de l’instance. De cette manière, plusieurs liens avec des identificateurs uniques peuvent renvoyer à un seul fichier de modèle. Lors de la gestion d’une unité d’instance, + systemd + cherchera un fichier avec le nom exact de l’instance que vous spécifiez sur la ligne de commande à utiliser. S’il ne parvient pas à en trouver un, il recherchera un fichier de modèle associé.

Spécificateurs de modèles

La puissance des fichiers d’unités modèles s’exprime principalement par leur capacité à substituer de manière dynamique les informations appropriées dans la définition de l’unité en fonction de l’environnement d’exploitation. Pour ce faire, définissez les directives du fichier de modèle comme d’habitude, mais remplacez certaines valeurs ou parties de valeurs par des spécificateurs de variable.

Certains des spécificateurs les plus courants seront remplacés lorsqu’une unité d’instance est interprétée avec les informations pertinentes:

* +% n + *: partout où cela apparaît dans un fichier modèle, le nom complet de l’unité résultant sera inséré.
* +% N + *: il s’agit de la même chose que ci-dessus, mais tous les caractères d’échappement, tels que ceux présents dans les modèles de chemin de fichier, seront inversés.
* +% p + *: Ceci fait référence au préfixe du nom d’unité. C’est la partie du nom de l’unité qui précède le symbole + @ +.
* +% P + *: C’est la même chose que ci-dessus, mais avec tout échappement inversé.
* +% i + *: Ceci fait référence au nom de l’instance, qui est l’identifiant suivant le + @ + de l’unité d’instance. C’est l’un des spécificateurs les plus couramment utilisés car il sera garanti d’être dynamique. L’utilisation de cet identifiant encourage l’utilisation d’identificateurs significatifs de configuration. Par exemple, le port sur lequel le service sera exécuté peut être utilisé comme identifiant d’instance et le modèle peut utiliser ce spécificateur pour configurer la spécification de port.
* +% I + *: Ce spécificateur est le même que ci-dessus, mais avec tout échappement inversé.
* +% f + *: Ceci sera remplacé par le nom d’occurrence non échappé ou le nom de préfixe, précédé du préfixe + / +.
* +% c + *: Ceci indiquera le groupe de contrôle de l’unité, avec la hiérarchie parent standard + / sys / fs / cgroup / ssytemd / + supprimée.
* +% u + *: nom de l’utilisateur configuré pour exécuter l’unité.
* +% U + *: Comme ci-dessus, mais sous forme numérique + UID + au lieu de nom.
* +% H + *: nom d’hôte du système qui exécute l’unité.
* + %% + *: Ceci est utilisé pour insérer un signe de pourcentage littéral.

En utilisant les identifiants ci-dessus dans un fichier modèle, + systemd + remplira les valeurs correctes lors de l’interprétation du modèle pour créer une unité d’instance.

Conclusion

Lorsque vous travaillez avec + systemd +, la compréhension des unités et des fichiers d’unité peut simplifier l’administration. Contrairement à beaucoup d’autres systèmes init, il n’est pas nécessaire de connaître un langage de script pour interpréter les fichiers init utilisés pour démarrer les services ou le système. Les fichiers d’unité utilisent une syntaxe déclarative assez simple qui vous permet de voir d’un coup d’œil l’objectif et les effets d’une unité lors de son activation.

Casser des fonctionnalités telles que la logique d’activation en unités distinctes permet non seulement aux processus internes + systemd + d’optimiser l’initialisation parallèle, mais simplifie également la configuration et vous permet de modifier et de redémarrer certaines unités sans détruire ni reconstruire leurs connexions associées. Tirer parti de ces capacités peut vous donner plus de flexibilité et de puissance lors de l’administration.

TOC