Comment créer un service systemd sous Linux

Depuis son introduction en mars 2010, les gens ont eu diverses opinions sur systemd. Mais une chose que vous ne pouvez pas nier, c’est que systemd est maintenant présent dans presque tout Les distributions Linux !

Bien sûr, il existe des distributions Linux qui annoncent explicitement l’utilisation d’un système d’initialisation différent de systemd, mais celles-ci sont très rares. Ubuntu, Fedora, RHEL, Debian, Pop!_OS, openSUSE, Arch, tous sont livrés avec systemd par défaut.

Étant donné que systemd est si largement utilisé, il vaut la peine d’y jeter un coup d’œil et d’apprendre à créer des services systemd.

Qu’est-ce qu’un service systemd ?

En termes simples, un service est un processus “d’arrière-plan” qui est démarré ou arrêté en fonction de certaines circonstances. Vous n’êtes pas obligé de le démarrer et/ou de l’arrêter manuellement. Un «service systemd» est un fichier écrit dans un format tel que systemd est capable de l’analyser et de le comprendre, puis de faire ce que vous lui avez dit de faire.

Techniquement, ce que j’appelle le fichier “systemd service” s’appelle en fait un fichier “systemd unit”, mais puisque ce tutoriel concerne la création d’un service, je continuerai à l’appeler fichier “systemd service”.

Comprendre la structure de base d’un fichier de service systemd

Le fichier de service systemd comporte trois sections importantes et nécessaires. Elles sont [Unit], [Service] et [Install] sections. L’extension du fichier de service systemd est .service et nous utilisons le symbole dièse/dièse (#) pour commentaires.

Vous trouverez ci-dessous un exemple de fichier de service systemd. Veuillez noter qu’il s’agit NE PAS un fichier de service systemd réel. Je l’ai modifié pour qu’il vous aide à comprendre.

[Unit]
Description=Apache web server
After=network.target
Before=nextcloud-web.service

[Service]
ExecStart=/usr/local/apache2/bin/httpd -D FOREGROUND -k start
ExecReload=/usr/local/apache2/bin/httpd -k graceful
Type=notify
Restart=always


[Install]
WantedBy=default.target
RequiredBy=network.target

C’est le le plus fondamental structure d’un fichier de service systemd. Comprenons ce que chacun de ces mots veut dire.

La [Unit] section

La section Unité contient des détails et une description sur l’unité elle-même. Dans notre cas, il contient des détails sur le service. Des détails comme « quelle est sa description », « quelles sont ses dépendances » et plus encore.

Vous trouverez ci-dessous les champs de la section Unité :

  • Description:- Titre lisible par l’homme du service systemd.
  • After:- Définir la dépendance à un service. Par exemple, si vous configurez le serveur Web Apache, vous souhaitez que le serveur démarre une fois le réseau en ligne. Cela inclut généralement des cibles ou d’autres services.
  • Before:- Démarrer le service en cours avant le service spécifié. Dans cet exemple, je dis que “Je veux que le serveur Web Apache s’exécute avant le démarrage du service pour Nextcloud”. En effet, dans mon cas, le serveur Nextcloud dépend du serveur Web Apache. Cela aussi, comme Afterinclut des cibles ou d’autres services.

La [Service] section

La section Service contient des détails sur l’exécution et la résiliation du service.

Vous trouverez ci-dessous les champs de la section Service :

  • ExecStart:- La commande qui doit être exécutée au démarrage du service. Dans notre cas, nous voulons que le serveur Apache démarre.
  • ExecReload:- Ce champ n’est pas obligatoire. Il spécifie comment un service est redémarré. Pour les services qui effectuent des E/S de disque (en particulier l’écriture sur le disque, comme une base de données), il est préférable de les arrêter gracieusement et de recommencer. Utilisez ce champ si vous souhaitez disposer d’un mécanisme de redémarrage spécifique.
  • Type:- Le type de démarrage du processus pour ce service systemd. Les options sont simple, exec, forking, oneshot, dbus, notify et idle. (Plus d’informations ici)
  • Restart:- Ceci est un autre champ facultatif mais que vous utiliserez très probablement. Cela spécifie si un service doit être redémarré – selon les circonstances – ou non. Les options disponibles sont no, on-success, on-failure, on-abnormal, on-watchdog, on-abort et always.

La [Install] section

La section Install, comme son nom l’indique, gère l’installation d’un fichier service/unité systemd. Ceci est utilisé lorsque vous exécutez soit systemctl enable et systemctl disable commande pour activer/désactiver un service.

Vous trouverez ci-dessous les champs de la section Installer :

  • WantedBy:- Ceci est similaire au After et Before champs, mais la principale différence est que cela est utilisé pour spécifier des “niveaux d’exécution” équivalents à systemd. La default.target est lorsque toute l’initialisation du système est terminée – lorsque l’utilisateur est invité à se connecter. La plupart des services destinés aux utilisateurs (comme Apache, cron, GNOME-stuff, etc.) utilisent cette cible.
  • RequiredBy:- Ce champ peut sembler très similaire à WantedBymais la principale différence est que ce champ spécifie dépendances dures. Cela signifie que s’il s’agit d’une dépendance, ce service échouera.

Ce que j’ai énuméré ci-dessus n’est qu’un minimal Exemple. Il existe de nombreux boutons que vous pouvez tourner pour personnaliser votre service en fonction de votre environnement et de vos besoins.

Pour une documentation complète sur systemd, veuillez se référer à cette page. C’est littéralement a tout documenté!

Créer votre propre service systemd

Maintenant que vous connaissez la structure d’un fichier de service systemd de base, laissez-nous plonger dans la création de votre propre service systemd.

Pour cet exemple, je vais créer un service systemd simple qui exécute un script bash au démarrage. Voici mon script bash, nommé check-file-system.shplacé dans le ~/.scripts/ annuaire.

#!/usr/bin/env bash

ROOT_PARTITION=$(mount | grep '/ ' | awk '{print $1}')
PHYSICAL_DISK=$(lsblk -no pkname ${ROOT_PARTITION} | head -n 1)

if [ ${EUID} -ne 0 ]
then
	exit 1 # this is meant to be run as root
fi

fsck /dev/${PHYSICAL_DISK}

⚠️

Ce script bash échouera immédiatement puisque le périphérique que nous sommes en train de fscker est monté en tant que rootfs. Ce script est destiné à des fins de démonstration uniquement 😉

Laissez-moi vous expliquer ce que je fais dans ce script. Je trouve quelle partition de disque est montée en tant que root (/). Cela peut être /dev/sda1 ou /dev/sdb2, ou quoi que ce soit d’autre. En utilisant cela, je découvre le nom réel du lecteur (sda).

Avec ces informations, j’exécute une vérification du système de fichiers avec la commande fsck sur ce lecteur. Je souhaite exécuter ce script à chaque démarrage.

Pour cela, je vais créer un fichier de service systemd, comme ceci :

[Unit]
Description=Checking filesytems on boot
After=multi-user.target

[Service]
ExecStart=/usr/bin/bash /home/pratham/.scripts/check-file-system.sh
Type=simple

[Install]
WantedBy=multi-user.target

Excellent! Notre fichier de service systemd est maintenant prêt.

Choisir un emplacement pour notre fichier de service systemd

Maintenant que notre script de démarrage et les fichiers de service systemd sont prêts… Où puis-je enregistrer le fichier de service systemd et comment l’activer ?

Avant de répondre à cette question, je dois d’abord poser une autre question. “Ce service systemd qui va être exécuté, qui va l’exécuter ? A-t-il besoin de privilèges de superutilisateur ? Doit-il être exécuté en tant qu’utilisateur spécifique ?”

Vous trouverez ci-dessous les emplacements dans lesquels vous pouvez placer un fichier de service systemd, en fonction de l’utilisateur qui va l’exécuter.

  • root: /etc/systemd/system/
  • pratham: /home/pratham/.config/systemd/user/

Pour cet exemple, mon utilisateur s’appelle prathammais le vôtre sera très certainement différent du mien.

Ainsi, si un service a besoin de privilèges de superutilisateur, comme générer une base de données de système de fichiers toutes les 6 heures, il doit avoir des privilèges de superutilisateur. Celle-ci doit donc être placée dans /etc/systemd/system/ annuaire.

💡

Les services systemd qui sont exécutés par l’utilisateur normal auront besoin du --user option à passer explicitement. Disons que seul utilisateur pratham a un service appelé greet-pratham.servicepour le redémarrer, je vais utiliser la commande systemctl --user restart greet-pratham.service

Pour un service qui n’a pas de privilèges particuliers, il est préférable qu’il soit exécuté par un utilisateur normal, comme pratham. Cela doit donc être placé dans le ~/.config/systemd/user/ annuaire.

Dans notre exemple, nous effectuons une vérification du système de fichiers, qui nécessite des privilèges de superutilisateur. Donc, je placerai mon fichier de service systemd dans le /etc/systemd/system/ annuaire. Le chemin absolu de mon fichier de service systemd est /etc/systemd/system/fsck-on-boot.service

Étapes finales

Maintenant qu’un fichier de service systemd a été créé et placé au bon emplacement, vous devez indiquer à systemd de recharger les fichiers d’unité. En effet, vous avez créé un nouveau service et les services sont détectés au démarrage. Vous avez déjà démarré, vous devez donc le faire manuellement.

Pour indiquer à systemd de recharger les fichiers unitaires, utilisez la commande suivante (pour un service nécessitant des privilèges de superutilisateur) :

sudo systemctl daemon-reload

Sinon, si vous avez créé un service utilisateur, utilisez la commande suivante :

systemctl --user daemon-reload

Une fois cela fait, vous pouvez activer le service. Je vais activer mon service fsck-on-boot.service ainsi:

sudo systemctl enable fsck-on-boot.service

Une fois que vous avez activé le service, vérifiez son état à l’aide de la systemctl status commande.

$ sudo systemctl status fsck-on-boot.service
× fsck-on-boot.service - Checking filesytems on boot
     Loaded: loaded (/etc/systemd/system/fsck-on-boot.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Tue 2022-09-06 09:57:04 IST; 8s ago
   Main PID: 130145 (code=exited, status=8)
        CPU: 82ms

Sep 06 09:57:04 vidhyaa systemd[1]: Started Checking filesytems on boot.
Sep 06 09:57:04 vidhyaa bash[130153]: fsck from util-linux 2.37.2
Sep 06 09:57:04 vidhyaa bash[130155]: e2fsck 1.46.5 (30-Dec-2021)
Sep 06 09:57:04 vidhyaa bash[130155]: /dev/sda is in use.
Sep 06 09:57:04 vidhyaa bash[130155]: e2fsck: Cannot continue, aborting.
Sep 06 09:57:04 vidhyaa systemd[1]: fsck-on-boot.service: Main process exited, code=exited, status=8/n/a
Sep 06 09:57:04 vidhyaa systemd[1]: fsck-on-boot.service: Failed with result 'exit-code'.

Comme je l’ai mentionné précédemment, le script a échoué. Mais, plus important encore, la le service est activé. C’est ce qui compte le plus.

Maintenant, vous pouvez traiter ce service comme n’importe quel service régulier en l’arrêtant, en le démarrant, en le redémarrant, en le désactivant, en le réactivant, etc…

Conclusion

Cet article traite de certains aspects clés de la création de votre propre service systemd. L’anatomie d’un fichier de service systemd, où le placer, recharger systemd pour l’informer de votre service nouvellement créé, activer le service et enfin, vérifier son statut.

5/5 - (1 vote)
SAKHRI Mohamed
SAKHRI Mohamed

Le blog d'un passionné d'informatique qui partage des actualités, des tutoriels, des astuces, des outils en ligne et des logiciels pour Windows, macOS, Linux, Web designer et jeux vidéo.

Publications: 3764

Laisser un commentaire

Your email address will not be published.