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

Introduction

De plus en plus, les distributions Linux adoptent le système d'initialisation systemd. Cette puissante suite de logiciels 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, une unité fait référence à toute ressource que le système sait 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 unitaires.

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

Que vous apportent les unités Systemd ?

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

On peut dire que les unités sont similaires aux services ou aux travaux dans d'autres systèmes init. Cependant, une unité a une définition beaucoup plus large, car elle peut être utilisée pour abstraire des services, des ressources réseau, des périphériques, des montages de systèmes de fichiers et des pools de ressources isolés.

Les idées qui, dans d'autres systèmes d'initialisation, 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 les 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 séparé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 retarder le démarrage d'un service jusqu'à ce que le socket associé soit accédé pour la première fois. 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 basée sur le chemin : une unité peut être démarrée en fonction de l'activité ou de la disponibilité de certains chemins de système de fichiers. Cela utilise inotify.
activation basée sur l'appareil : les unités peuvent également être démarrées dès la première disponibilité du matériel associé en tirant parti des événements udev.
cartographie implicite des dépendances : la majeure partie de l'arborescence des dépendances pour les unités peut être construite par systemd lui-même. Vous pouvez toujours ajouter des informations de dépendance et de commande, mais la plupart des gros travaux sont pris 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 fournissent toutes la même fonction générale.
renforcement facile de la sécurité : les unités peuvent implémenter des fonctionnalités de sécurité assez bonnes en ajoutant des directives simples. Par exemple, vous pouvez spécifier aucun accès ou un accès en lecture seule à une partie du système de fichiers, limiter les capacités du noyau et attribuer un accès privé /tmp et réseau.
drop-ins et extraits : les unités peuvent facilement être étendues en fournissant des extraits qui remplaceront certaines parties du fichier d'unité du système. Cela facilite le basculement entre les implémentations d'unités standard et personnalisées.

Les unités systemd présentent de nombreux autres avantages par rapport aux éléments de travail des autres systèmes init, mais cela devrait vous donner une idée de la puissance qui peut être exploitée à l'aide des directives de configuration natives.

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

Les fichiers qui définissent comment 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 du système des fichiers d'unité est généralement conservée dans le répertoire /lib/systemd/system. Lorsque le logiciel installe des fichiers unitaires sur le système, il s'agit de l'emplacement où ils sont placés par défaut.

Les fichiers unitaires stockés ici peuvent être démarrés et arrêtés à la demande pendant une session. Ce sera le fichier d'unité vanille générique, souvent écrit par les mainteneurs du projet en amont qui devrait fonctionner sur tout système qui déploie systemd dans son implémentation standard. Vous ne devez pas modifier les fichiers de 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 dans le répertoire /etc/systemd/system. Les fichiers d'unité trouvés dans cet emplacement de répertoire ont priorité sur tous les autres emplacements du système de fichiers. Si vous avez besoin de modifier la copie du système d'un fichier d'unité, placer un remplacement dans ce répertoire est le moyen le plus sûr et le plus flexible de le faire.

Si vous souhaitez remplacer uniquement des directives spécifiques du fichier d'unité du système, vous pouvez en fait fournir des extraits de fichier d'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 procéder 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 example.service, un sous-répertoire appelé example.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 d'unité du système.

Il existe également un emplacement pour les définitions d'unités d'exécution dans /run/systemd/system. Les fichiers d'unité trouvés dans ce répertoire ont un atterrissage prioritaire entre ceux de /etc/systemd/system et /lib/systemd/system. Les fichiers de cet emplacement ont moins de poids que l'ancien emplacement, mais plus de poids que le second.

Le processus systemd lui-même utilise cet emplacement pour les fichiers d'unité créés dynamiquement lors 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 apportées à ce répertoire seront perdues lors du redémarrage du serveur.

Types d'unités

Systemd classe les unités selon le type de ressource qu'elles décrivent. Le moyen le plus simple de déterminer le type d'une unité consiste à 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 doit être démarré automatiquement, et les informations de dépendance et de commande pour les 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 basée sur le socket. Ceux-ci ont toujours un fichier associé .service qui sera lancé lorsqu'une activité sera détectée sur le socket défini par cette unité.

.device : une unité qui décrit un périphérique qui a été désigné comme nécessitant une gestion systemd par udev ou le sysfs système de fichiers. Tous les appareils n'auront pas de fichiers .device. Certains scénarios où les unités .device peuvent être nécessaires sont pour la commande, le montage et l'accès aux appareils.

.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 remplacées par des 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 automatiquement monté. Ceux-ci doivent être nommés d'après le point de montage auquel ils se réfèrent et doivent avoir une unité .mount correspondante pour définir les spécificités du montage.

.swap : cette unité décrit l'espace d'échange sur le système. Le nom de ces unités doit refléter le périphérique ou le chemin de fichier de l'espace.

.target : une unité cible est utilisée pour fournir des points de synchronisation pour d'autres unités lors du démarrage ou du changement d'état. Ils peuvent également être utilisés pour amener le système à un nouvel état. D'autres unités spécifient leur relation avec les cibles pour être liées aux opérations de la cible.

.path : cette unité définit un chemin qui peut être utilisé pour l'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 atteindra l'état spécifié. Cela utilise inotify pour surveiller le chemin des modifications.

.timer : une unité .timer définit un timer qui sera géré par systemd, similaire à une tâche cron pour une activation différée ou programmée. Une unité correspondante sera démarrée lorsque la minuterie sera atteinte.

.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 annuler des états temporaires.

.slice : une unité .slice est associée aux nœuds du groupe de contrôle Linux, permettant aux ressources d'être restreintes ou affectées à 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 de portée sont créées automatiquement par systemd à partir des informations reçues de ses interfaces de bus. Ceux-ci sont utilisés pour gérer des ensembles de processus système créés en externe.

Comme vous pouvez le voir, 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 fournir 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 d'unité

La structure interne des fichiers d'unité est organisée en sections. Les sections sont désigné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 unitaires

Les noms de section sont bien définis et sensibles à 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 ceci :

[Section]
Directive1=value
Directive2=value

. . .

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

Directive1=default_value

La default_value peut être éliminée dans un fichier de remplacement en référençant la Directive1 sans valeur, comme ceci :

Directive1=

En général, systemd permet une configuration simple et flexible. Par exemple, plusieurs expressions booléennes sont acceptées (1, yes, on et true pour affirmatif et 0, no off et false pour la réponse opposée). Les temps peuvent être analysés intelligemment, avec des secondes supposées pour les valeurs sans unité et en combinant plusieurs formats réalisés en interne.

[Unité] Directives de section

La première section trouvée dans la plupart des fichiers d'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 de l'unité avec d'autres unités.

Bien que l'ordre des sections n'ait pas d'importance pour systemd lors de l'analyse du fichier, cette section est souvent placée en haut 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 bon 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. Il peut s'agir de pages man disponibles en interne ou d'URL accessibles sur le Web. La commande systemctl status exposera ces informations, permettant une découverte facile.
Requires= : cette directive répertorie toutes les unités dont cette unité dépend essentiellement. Si l'unité actuelle est activée, les unités répertoriées ici doivent également s'activer avec succès, sinon cette unité échouera. Ces unités sont lancées en parallèle avec l'unité courante par défaut.
Wants= : cette directive est similaire à Requires=, mais moins stricte. Systemd tentera de démarrer toutes les unités répertorié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. Il s'agit de la méthode recommandée pour configurer la plupart des relations de dépendance. Encore une fois, cela implique une activation parallèle à moins qu'elle ne soit modifiée par d'autres directives.
BindsTo= : cette directive est similaire à Requires=, mais provoque également l'arrêt de l'unité en cours lorsque l'unité associée se termine.
Before= : les unités répertoriées dans cette directive ne seront pas démarrées tant que l'unité actuelle n'est pas marquée comme démarrée si elles sont activées en même temps. Cela n'implique pas de relation de dépendance et doit être utilisé conjointement avec l'une des directives ci-dessus si cela est souhaité.
After= : les unités répertoriées dans cette directive seront démarrées avant le démarrage de l'unité actuelle. Cela n'implique pas une relation de dépendance et une doit être établie via les directives ci-dessus si cela est nécessaire.
Conflicts= : cela peut être utilisé pour lister les unités qui ne peuvent pas être exécutées en même temps que l'unité actuelle. Démarrer une unité avec cette relation entraînera l'arrêt des autres unités.
Condition...= : il existe un certain nombre de directives commençant par Condition qui permettent à l'administrateur de tester certaines conditions avant de démarrer l'unité. Cela peut être utilisé pour fournir un fichier d'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...= : similaires aux directives qui commencent par Condition, ces directives vérifient différents aspects de l'environnement d'exécution pour décider si l'unité doit s'activer. Cependant, contrairement aux directives Condition, un résultat négatif provoque un échec avec cette directive.

En utilisant ces directives et quelques autres, des informations générales sur l'unité et sa relation avec d'autres unités et le système d'exploitation peuvent être établies.

[Installer] Directives de section

De l'autre côté du fichier unité, la dernière section est souvent la section [Install]. Cette section est facultative et permet de définir le comportement d'une unité si elle est activée ou désactivée. L'activation d'une unité marque son démarrage automatique au démarrage. Essentiellement, cela est accompli en verrouillant l'unité en question sur une autre unité qui se trouve quelque part dans la ligne d'unités à démarrer au démarrage.

Pour cette raison, seules les unités qui peuvent ê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= le fait 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. Lorsqu'une unité avec cette directive est activée, un répertoire sera créé dans /etc/systemd/system nommé d'après l'unité spécifiée avec .wants ajouté à la fin. Dans celui-ci, un lien symbolique vers l'unité actuelle sera créé, créant la dépendance. Par exemple, si l'unité actuelle a WantedBy=multi-user.target, un répertoire appelé 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 sera placé à l'intérieur. 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 satisfaite. Lorsqu'elle est activée, une unité avec cette directive créera un répertoire se terminant par .requires.
Alias= : cette directive permet à l'unité d'être également activée sous un autre nom. Entre 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 d'alias commun.
Also= : cette directive permet d'activer ou de désactiver les unités en tant qu'ensemble. Les unités de support qui doivent toujours être disponibles lorsque cette unité est active peuvent être répertoriées ici. Ils seront gérés comme un groupe pour les tâches d'installation.
DefaultInstance= : pour les unités de modèle (abordées plus tard) qui peuvent produire des instances d'unité avec des noms imprévisibles, cela peut être utilisé comme valeur de secours pour le nom si un nom approprié n'est pas fourni.

Directives de section spécifiques à l'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 des sections nommées d'après leur type. Nous les aborderons brièvement ici.

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

La rubrique [Services]

La section [Service] est utilisée pour fournir une configuration qui ne s'applique qu'aux services.

L'une des choses de base qui doivent être spécifiées 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émarrage. Il s'agit de la valeur par défaut si les directives Type= et Busname= ne sont pas définies, mais que ExecStart= est défini. Toute communication doit être gérée à l'extérieur de l'unité via une seconde unité du type approprié (comme via une unité .socket si cette unité doit communiquer à l'aide de sockets).
forking : ce type de service est utilisé lorsque le service bifurque un processus enfant, quittant le processus parent presque immédiatement. Cela indique à systemd que le processus est toujours en cours d'exécution même si le parent est sorti.
oneshot : ce type indique que le processus sera de courte durée et que systemd doit attendre que le processus se termine avant de continuer avec d'autres unités. C'est le Type= par défaut et ExecStart= ne sont pas définis. Il est utilisé pour des tâches ponctuelles.
dbus : Ceci indique que l'unité prendra un nom sur le bus D-Bus. Lorsque cela se produit, systemd continuera à traiter l'unité suivante.
notifier : cela indique que le service émettra une notification lorsqu'il aura fini de démarrer. Le processus systemd attendra que cela se produise avant de passer à d'autres unités.
inactif : cela indique que le service ne sera pas exécuté tant que tous les travaux n'auront pas été 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 est utilisée pour définir le chemin du fichier qui doit contenir le numéro d'identification du processus de l'enfant principal qui doit être surveillé.
BusName= : cette directive doit être définie sur le nom de 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 tout. La valeur par défaut, \none, ignore tous les messages d'état. L'option \main écoutera les messages du processus principal et l'option \all entraînera le traitement de tous les membres du groupe de contrôle du service.

Jusqu'à présent, nous avons discuté de certaines informations préalables, mais nous n'avons pas réellement défini comment gérer nos services. Les directives pour ce faire sont :

ExecStart= : Ceci spécifie le chemin 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 \oneshot). 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é.< /li>
ExecStartPre= : cela peut être utilisé pour fournir des commandes supplémentaires qui doivent être exécutées avant le démarrage du processus principal. Cela peut être utilisé plusieurs fois. Encore une fois, 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 est commencé.
ExecReload= : Cette directive facultative indique la commande nécessaire pour recharger la configuration du service si disponible.
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 sera arrêté.
ExecStopPost= : ceci peut être utilisé pour spécifier les commandes à exécuter après la commande d'arrêt.
RestartSec= : si le redémarrage automatique du service est activé, cela spécifie le temps 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 défini sur des valeurs telles que \always, \on-success, \on-failure, \on-abnormal, \on-abort, ou \on-watchdog. Ceux-ci déclencheront un redémarrage en fonction de la manière dont le service a été arrêté.
TimeoutSec= : cela configure le temps que systemd attendra 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 délais d'expiration distincts avec TimeoutStartSec= et TimeoutStopSec=.

La section [Prise]

Les unités de socket sont très courantes dans les configurations systemd car de nombreux services implémentent l'activation basée sur les sockets pour fournir une meilleure parallélisation et flexibilité. Chaque unité de socket doit avoir une unité de service correspondante qui sera activée lorsque la socket reçoit une activité.

En cassant le contrôle des sockets en dehors du service lui-même, les sockets peuvent être initialisés plus tôt et les services associés peuvent souvent être démarrés en parallèle. Par défaut, le nom de socket tentera de démarrer le service du même nom lors de la réception d'une connexion. Lorsque le service est initialisé, le socket lui sera transmis, ce qui lui permettra de commencer à traiter toutes les requêtes mises en mémoire tampon.

Pour spécifier le socket réel, ces directives sont courantes :

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

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

D'autres caractéristiques des sockets 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 groupe propriétaire du socket. Ce sera le groupe racine si ni ceci ni ce qui précède ne sont définis. Si seul SocketUser= est défini, systemd essaiera de trouver un groupe correspondant.
SocketMode= : pour les sockets Unix ou les tampons FIFO, cela 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 [Montage]

Les unités de montage permettent la gestion des points de montage depuis systemd. Les points de montage sont nommés d'après le répertoire qu'ils contrôlent, avec un algorithme de traduction appliqué.

Par exemple, la barre oblique de début est supprimée, toutes les autres barres obliques sont traduites en tirets \-, et tous les tirets et 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 d'unité de montage. les unités auront une dépendance implicite vis-à-vis d'autres montures au-dessus d'elle 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é créées automatiquement et celles que vous souhaitez définir dans un fichier unité, les directives suivantes sont utiles :

What= : le chemin absolu vers la ressource qui doit être montée.
Where= : le chemin absolu du point de montage où la ressource doit être montée. Il doit être le même que le nom du fichier d'unité, à l'exception de l'utilisation 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 qui doivent être appliquées. 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 parents doivent être créés pour le point de montage, cela détermine le mode d'autorisation de ces répertoires.
TimeoutSec= : configure la durée d'attente du système jusqu'à ce que l'opération de montage soit marquée comme ayant échoué.

La section [Montage automatique]

Cette unité permet à une unité .mount associée d'être automatiquement montée au démarrage. Comme pour l'unité .mount, ces unités doivent être nommées d'après le chemin du point de montage traduit.

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

Where= : le chemin absolu du point de montage automatique sur le système de fichiers. Cela correspondra 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 d'autorisations de ces composants de chemin.

La section [Echange]

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

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

La section [Swap] d'un fichier unité peut contenir les directives de configuration suivantes :

What= : le chemin absolu vers l'emplacement de l'espace d'échange, qu'il s'agisse d'un fichier ou d'un périphérique.
Priority= : cela prend un entier qui indique la priorité du swap en cours de configuration.
Options= : toutes les options qui sont généralement définies dans le fichier /etc/fstab peuvent être définies avec cette directive à la place. Une liste séparée par des virgules est utilisée.
TimeoutSec= : la durée pendant laquelle systemd attend que l'échange soit activé avant de marquer l'opération comme un échec.

La section [Chemin]

Une unité de chemin définit un chemin de système de fichiers que systmed peut surveiller pour les changements. Une autre unité doit exister qui sera activée lorsqu'une certaine activité est détectée à 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 permet de vérifier si le chemin en question existe. Si c'est le cas, l'unité associée est activée.
PathExistsGlob= : c'est la même chose que ci-dessus, mais prend en charge les expressions globales de fichier pour déterminer l'existence du chemin.
PathChanged= : cela surveille l'emplacement du chemin d'accès pour les modifications. L'unité associée est activée si un changement est détecté lors de la fermeture du fichier surveillé.
PathModified= : cela surveille les changements comme la directive ci-dessus, mais il s'active sur les écritures de fichiers ainsi que lorsque le fichier est fermé.
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= : Cela détermine si systemd créera la structure de répertoire 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 qui doivent être créés.

La section [Minuteur]

Les unités de temporisation sont utilisées pour programmer des tâches pour qu'elles fonctionnent à une heure précise ou après un certain délai. Ce type d'unité remplace ou complète certaines fonctionnalités des démons cron et at. Une unité associée doit être fournie qui sera activée lorsque la minuterie sera 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 est utilisée pour spécifier la durée après le démarrage du système lorsque l'unité associée doit être activée.
OnStartupSec= : cette directive est similaire à la minuterie ci-dessus, mais en relation avec le démarrage du processus systemd lui-même.
OnUnitActiveSec= : cela définit une minuterie en fonction de la dernière activation de l'unité associée.
OnUnitInactiveSec= : Cela définit le minuteur par rapport au moment où l'unité associée a été marquée pour la dernière fois comme inactive.
OnCalendar= : Cela vous permet d'activer l'unité associée en spécifiant un absolu au lieu d'un relatif à un événement.
AccuracySec= : cette unité est utilisée pour définir le niveau de précision avec lequel la minuterie doit être respectée. Par défaut, l'unité associée sera activée dans la minute suivant l'atteinte de la minuterie. 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 la minuterie s'est écoulée. S'il n'est pas défini, systemd recherchera 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 devient actif s'il aurait été déclenché pendant la période pendant laquelle le minuteur a été inactif.
WakeSystem= : la définition de cette directive vous permet de réveiller un système de la suspension si la minuterie est atteinte dans cet état.

La section [Tranche]

La section [Slice] d'un fichier d'unité n'a en fait aucune configuration spécifique à l'unité .slice. Au lieu de cela, il peut contenir certaines directives de gestion des ressources qui sont en fait disponibles pour un certain nombre d'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 spécifiques à l'unité suivantes :

[Tranche]
[Portée]
[Service]
[Socket]
[Monter]
[Échange]

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és modèles pour créer plusieurs instances d'unités. Dans cette section, nous pouvons revenir sur ce concept plus en détail.

Les fichiers d'unité de modèle ne sont, à bien des égards, pas différents des fichiers d'unité ordinaires. Cependant, ceux-ci 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.

Modèle et noms d'unité 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 du type d'unité. Un nom de fichier d'unité de modèle peut ressembler à ceci :

example@.service

Lorsqu'une instance est créée à partir d'un modèle, un identifiant d'instance est placé entre le symbole @ et le point signifiant 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 qui ressemble à ceci :

example@instance1.service

Un fichier d'instance est généralement créé sous la forme d'un lien symbolique vers le fichier modèle, le nom du lien comprenant l'identifiant de l'instance. De cette manière, plusieurs liens avec des identifiants uniques peuvent pointer vers un seul fichier de modèle. Lors de la gestion d'une unité d'instance, systemd recherchera un fichier avec le nom d'instance exact que vous spécifiez sur la ligne de commande à utiliser. S'il n'en trouve pas, il recherchera un fichier de modèle associé.

Spécificateurs de modèle

La puissance des fichiers d'unité de modèle est principalement perçue par sa capacité à remplacer dynamiquement les informations appropriées dans la définition de l'unité en fonction de l'environnement d'exploitation. Cela se fait en définissant les directives dans le fichier de modèle comme d'habitude, mais en remplaçant certaines valeurs ou parties de valeurs par des spécificateurs de variables.

Voici quelques-uns des spécificateurs les plus courants qui 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 de modèle, le nom complet de l'unité résultante sera inséré.
%N : c'est la même chose que ci-dessus, mais tout échappement, comme ceux présents dans les modèles de chemin de fichier, sera inversé.
%p : cela fait référence au préfixe du nom de l'unité. Il s'agit de 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 : cela fait référence au nom de l'instance, qui est l'identifiant suivant le @ dans l'unité de l'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 incite à utiliser des identifiants 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 du port.
%I : ce spécificateur est le même que ci-dessus, mais avec tout échappement inversé.
%f : il sera remplacé par le nom d'instance sans échappement ou le nom du préfixe, précédé d'un /.
%c : cela indiquera le groupe de contrôle de l'unité, avec la hiérarchie parente standard de /sys/fs/cgroup/systemd/ supprimée.
%u : le nom de l'utilisateur configuré pour exécuter l'unité.
%U : identique à ci-dessus, mais sous la forme d'un UID numérique au lieu d'un nom.
%H : le 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 de 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 faciliter l'administration. Contrairement à de nombreux autres systèmes init, vous n'avez pas besoin 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 en un coup d'œil le but et les effets d'une unité lors de son activation.

La séparation de fonctionnalités telles que la logique d'activation en unités séparées permet non seulement aux processus internes systemd d'optimiser l'initialisation parallèle, mais elle permet également de maintenir la configuration assez simple et vous permet de modifier et de redémarrer certaines unités sans démonter et reconstruire leur connexions associées. Tirer parti de ces capacités peut vous donner plus de flexibilité et de puissance lors de l'administration.