Comment créer unité de service Systemd dans Linux

Bien que Systemd ait été l'objet de nombreuses controverses, au point que certaines distributions ont été fourchues juste pour s'en débarrasser (voir Devuan, une fourche de Debian qui, par défaut, remplace Systemd par Sysvinit), à la fin, il est devenu le Système d'initial standard de facto dans le monde Linux.

Dans ce tutoriel, nous verrons comment un service systemd est structuré, et nous apprendrons à en créer un.

Dans ce tutoriel, vous apprendrez:

• Qu'est-ce qu'une unité de service…
• Quelles sont les sections d'une unité de service.
• Quelles sont les options les plus courantes qui peuvent être utilisées dans chaque section.
• Quels sont les différents types de service qui peuvent être définis.

Exigences et conventions logicielles utilisées

Le système Init Systemd

Toutes les principales distributions, telles que Rhel, Centos, Fedora, Ubuntu, Debian et Archlinux, ont adopté Systemd comme système d'initial. Systemd, en fait, est plus qu'un simple système d'initial, et c'est l'une des raisons pour lesquelles certaines personnes sont fortement contre sa conception, ce qui va à l'encontre de la devise UNIX bien établie: «Faites une chose et faites-le bien». Lorsque d'autres systèmes init utilisent un script de shell simple pour gérer les services, Systemd utilise son propre .service fichiers (unités avec le .Suffix de service): Dans ce tutoriel, nous verrons comment ils sont structurés et comment en créer et en installer un.

Anatomie d'une unité de service

Qu'est-ce qu'une unité de service? Un fichier avec le .service Le suffixe contient des informations sur un processus géré par Systemd. Il est composé par trois sections principales:

• [Unité]: Cette section contient des informations non spécifiquement liées au type de l'unité, comme la description du service
• [Service]: contient des informations sur le type spécifique de l'unité, un service dans ce cas
• [Installation]: Cette section contient des informations sur l'installation de l'unité

Analysons chacun d'eux en détail.

La section [unité]

Le [Unité] Section d'un .service Le fichier contient la description de l'unité elle-même et les informations sur son comportement et ses dépendances: (pour travailler correctement, un service peut dépendre d'un autre). Nous discutons ici certaines des options les plus pertinentes qui peuvent être utilisées dans cette section

L'option «Description»

Tout d'abord, nous avons le Description option. En utilisant cette option, nous pouvons fournir une description de l'unité. La description apparaîtra alors, par exemple, lors de l'appel du systemctl Commande, qui renvoie un aperçu de l'état de SystemD. Ici est, par exemple, comment la description de httpd Le service est défini sur un système Fedora:

[Unité] Description = le serveur http Apache 

L'option «After»

En utilisant le Après Option, nous pouvons indiquer que notre unité devrait être démarrée après les unités que nous fournissons sous la forme d'une liste séparée dans l'espace. Par exemple, observant à nouveau le fichier de service où le service Web Apache est défini, nous pouvons voir ce qui suit:

After = réseau.Target Remote-FS.cibler NSS-Lookup.cible httpd-init.service

La ligne au-dessus demande à Systemd de démarrer l'unité de service httpd.service seulement après le réseau, supprimer, NSS-Lookup cibles et le service httpd-init.

Spécification des dépendances dures avec «Requier»

Comme nous l'avons brièvement mentionné ci-dessus, une unité (un service dans notre cas) peut dépendre d'autres unités (pas nécessairement des unités de «service») pour fonctionner correctement: de telles dépendances peuvent être déclarées en utilisant le A besoin option.

Si l'une des unités sur lesquelles un service dépend ne parvient pas, l'activation du service qu'elle est arrêtée: c'est pourquoi ceux-ci sont appelés dépendances difficiles. Dans cette ligne, extrait du fichier de service de l'Avahi-Daemon, nous pouvons voir comment il est déclaré dépendant de l'Avahi-Daemon.unité de douille:

Nécessite = avahi-daemon.prise

Déclarer les dépendances «douces» avec des «désirs»

Nous venons de voir comment déclarer les dépendances dites «dures» pour le service en utilisant le A besoin option; Nous pouvons également répertorier les dépendances «douces» en utilisant le Veut option.

Quelle est la différence? Comme nous l'avons dit ci-dessus, si une dépendance «dure» échoue, le service échouera lui-même; Une défaillance de toute dépendance «douce», cependant, n'influence pas ce qui arrive à l'unité dépendante. Dans l'exemple fourni, nous pouvons voir comment le docker.service L'unité a une douce dépendance à la Docker-Storage-Settup.service un:

[Unité] veut = Docker-Storage-Settup.service 

La section [Service]

Dans le [Service] Section d'un service unité, nous pouvons spécifier des choses comme la commande à exécuter lorsque le service est démarré, ou le type de service lui-même. Jetons un coup d'œil à certains d'entre eux.

Démarrer, arrêter et recharger un service

Un service peut être démarré, arrêté, redémarré ou rechargé. Les commandes à exécuter lors de l'exécution de chacune de ces actions peuvent être spécifiées en utilisant les options connexes dans le [Service] section.

La commande à exécuter lorsqu'un service démarre, est déclaré en utilisant le Exercice option. L'argument transmis à l'option peut également être le chemin vers un script. Facultativement, nous pouvons déclarer les commandes à exécuter avant et après le démarrage du service, en utilisant le Execstartpre et Execstartpost Options respectivement. Voici la commande utilisée pour démarrer le service NetworkManager:

[Service] ExecStart = / USR / SBIN / NetworkManager --no-daemon 

De la même manière, nous pouvons spécifier la commande à exécuter lorsqu'un service est rechargé ou arrêté, en utilisant le Execstop et Exaspérage options. Similaire à ce qui se passe avec Execstartpost, Une commande ou plusieurs commandes à lancer après l'arrêt d'un processus peuvent être spécifiées avec le Execstoppost option.

Le type de service

SystemD définit et distingue un autre type de services en fonction de leur comportement attendu. Le type de service peut être défini en utilisant le Taper Option, fournir l'une de ces valeurs:

• simple
• farding
• un tir
• dbus
• aviser

Le type par défaut d'un service, si le Taper et Nom de bus Les options ne sont pas définies, mais une commande est fournie via le Exercice L'option, c'est simple. Lorsque ce type de service est défini, la commande a déclaré Exercice est considéré comme le principal processus / service.

Le farding le type fonctionne différemment: la commande fournie avec Exercice devrait se nourrir et lancer un processus enfant, qui deviendra le processus / service principal. Le processus parent qu'il devrait mourir une fois le processus de démarrage terminé.

Le un tir le type est utilisé comme défaut si le Taper et Exercice Les options ne sont pas définies. Ça fonctionne à peu près comme simple: La différence est que le processus devrait terminer son travail avant le lancement d'autres unités. L'unité, cependant, elle est toujours considérée comme «active» même après la sortie de la commande, si le ResteafterExit L'option est définie sur «Oui» (la valeur par défaut est «non»).

Le prochain type de service est dbus. Si ce type de service est utilisé, le démon devrait obtenir un nom de Dbus, comme spécifié dans le Nom de bus L'option qui, dans ce cas, devient obligatoire. Pour le reste, cela fonctionne comme le simple taper. Cependant, les unités conséquentes ne sont lancées qu'après l'acquisition du nom DBU.

Un autre processus fonctionne de manière similaire à simple, et c'est aviser: la différence est que le démon devrait envoyer une notification via le sd_notify fonction. Seulement une fois cette notification envoyée, les unités conséquentes sont lancées.

Définir les délais d'expiration du processus

En utilisant des options spécifiques, il est possible de définir des délais pour le service. Commençons avec Redémarrer: En utilisant cette option, nous pouvons configurer la durée (par défaut en secondes) Systemd devrait attendre avant de redémarrer un service. Un temps de temps peut également être utilisé comme valeur pour cette option, comme «5 minutes 20». La valeur par défaut est 100 ms.

Le TimeoutStartSec et Timeoutstopsec Les options peuvent être utilisées pour spécifier, respectivement, le délai d'expiration pour un start-up et un arrêt de service, en quelques secondes. Dans le premier cas, si après le délai d'expiration spécifié, le processus de démarrage du démon n'est pas terminé, il sera considéré comme échoué.

Dans le deuxième cas, si un service doit être arrêté mais n'est pas terminé après le délai d'expiration spécifié, d'abord un Sigterm Et puis, après le même temps, un Sigkill le signal y est envoyé. Les deux options acceptent également un timepan comme valeur et peuvent être configurées immédiatement, avec un raccourci: Timeoutsc. Si infini est fourni en valeur, les délais d'expiration sont désactivés.

Enfin, nous pouvons configurer la limite pour le temps qu'un service peut exécuter, en utilisant le RuntimeMaxSec. Si un service dépasse ce délai d'expiration, il est terminé et considéré comme échoué.

La section [d'installation]

Dans le [installer] Section, nous pouvons utiliser des options liées à l'installation du service. Par exemple, en utilisant le Alias Option, nous pouvons spécifier une liste d'alias séparée d'espace à utiliser pour le service lors de l'utilisation des commandes SystemCTL (sauf activer).

Similaire à ce qui se passe avec le A besoin et Veut Options dans le [Unité] section, pour établir des dépendances, dans le [installer] Section, nous pouvons utiliser Requis par et Recherché par. Dans les deux cas, nous déclarons une liste d'unités qui dépendent de celle que nous configurons: avec la première option, ils seront dépendant durement, avec les seconds, ils ne seront considérés que comme faibles. Par exemple:

[Installer] WantedBy = Multi-utilisateur.cible 

Avec la ligne au-dessus, nous avons déclaré que le multi-utilisateurs La cible a une douce dépendance à notre unité. Dans la terminologie systemd, les unités se terminant avec le .cible suffixe, peut être associé à ce qu'on appelait temps de course dans d'autres systèmes d'initiation comme Sysvinit. Dans notre cas, donc, la cible multi-utilisateurs, une fois atteinte, devrait inclure notre service.

Création et installation d'une unité de service

Il y a essentiellement deux endroits dans le système de fichiers où les unités de service SystemD sont installées: / usr / lib / systemd / système et / etc / systemd / système. Le premier chemin est utilisé pour les services fournis par les packages installés, tandis que le second peut être utilisé par l'administrateur système pour ses propres services qui peuvent remplacer les défauts par défaut.

Créons un exemple de service personnalisé. Supposons que nous voulons créer un service qui désactive la fonction Wake-on-LAN sur une interface Ethernet spécifique (ENS5F5 dans notre cas) lors de son démarrage, et la réévalue lorsqu'elle est arrêtée. Nous pouvons utiliser le ethtool commander pour accomplir la tâche principale. Voici à quoi pourrait ressembler notre fichier de service:

[Unité] Description = Force Interface Ethernet ENS5F5 à 100 Mbps Nécessite = réseau.cible après = réseau.Target [Service] type = ONESHOT RESTAFTEREXIT = Oui ExecStart = / USR / SBIN / ETHTOOL -S ENS5F5 WOL D EXECTOP = / USR / SBIN / ETHTOOL -S ENS5F5 WOL G [INSTALLATION] WANDBY = Multi-User.cible 

Nous définissons une description d'unité simple et avons déclaré que le service dépend du réseau.cible unité et doit être lancé une fois qu'il est atteint. Dans le [Service] Section Nous définissons le type de service en tant que un tir, et a demandé à Systemd de considérer le service comme actif après l'exécution de la commande, en utilisant le ResteafterExit option. Nous avons également défini les commandes à exécuter lorsque le service est démarré et arrêté. Enfin, dans le [Installer] Section Nous avons essentiellement déclaré que notre service devrait être inclus dans le multi-utilisateurs cible.

Pour installer le service, nous copierons le fichier dans le / etc / systemd / système répertoire comme wol.service, que nous le démarrerons:

$ sudo cp wol.Service / etc / Systemd / System && sudo systemctl start wol.service

Nous pouvons vérifier que le service est actif, avec la commande suivante:

$ systemctl is-active wol.service actif 

La sortie de la commande, comme prévu, est actif. Maintenant, pour vérifier que «Wake on Lan» a été réglé pour d, Et donc il est maintenant désactivé, nous pouvons courir:

$ sudo ethtool ENS5f5 | Grep Wake-on prend en charge Wake-on: PG Wake-on: D 

Maintenant, l'arrêt du service devrait produire le résultat inverse et réactiver WOL:

$ sudo systemctl stop wol.Service && sudo ethtool ENS5f5 | Grep Wake-on prend en charge Wake-on: PG Wake-on: G 

Conclusions

Dans ce tutoriel, nous avons vu comment un fichier de service Systemd est composé, quelles sont ses sections et certaines des options qui peuvent être utilisées dans chacun d'elles. Nous avons appris à configurer une description de service, à définir ses dépendances et à déclarer les commandes qui devraient être exécutées lors de son démarrage, arrêté ou rechargé.

Étant donné que Systemd, comme il est devenu le système d'initial standard dans le monde Linux, il est important de se familiariser à sa façon de faire les choses. La documentation officielle des services Systemd se trouve sur le site Web de Freedesktop. Vous pourriez également être intéressé à lire notre article sur la gestion des services avec Systemd.

Tutoriels Linux connexes:

• Choses à installer sur Ubuntu 20.04
• Choses à faire après l'installation d'Ubuntu 20.04 Focal Fossa Linux
• Comment planter Linux
• Mint 20: Mieux que Ubuntu et Microsoft Windows?
• Téléchargement Linux
• Système linux hung? Comment s'échapper vers la ligne de commande et…
• Choses à faire après l'installation d'Ubuntu 22.04 Jammy Jellyfish…
• Une introduction à l'automatisation Linux, des outils et des techniques
• Commandes Linux: les 20 meilleures commandes les plus importantes que vous devez…
• Commandes Linux de base