Maîtriser Systemd : Création de votre premier fichier d'unité de service personnalisé

Systemd est devenu le gestionnaire de services omniprésent sur les distributions Linux modernes, responsable de la gestion de tout, de l'initialisation du démarrage du système à la gestion des services en cours d'exécution dans l'espace utilisateur. Comprendre comment écrire des fichiers d'unité personnalisés est fondamental pour automatiser le déploiement des applications, assurer le redémarrage correct des services et intégrer les processus sur mesure de manière transparente dans le cycle de vie du système d'exploitation.

Ce guide complet vous expliquera la structure essentielle d'un fichier d'unité de service Systemd, couvrant les sections critiques [Unit], [Service] et [Install]. À la fin de ce tutoriel, vous serez en mesure de définir, d'activer et de gérer votre propre service personnalisé.

Prérequis

Avant de plonger dans la configuration, assurez-vous de disposer d'un accès administratif (sudo) et d'une compréhension de base du système de fichiers Linux. Ce guide suppose que vous travaillez sur une distribution moderne utilisant Systemd (par exemple, Debian, Ubuntu, Fedora, CentOS 7+/RHEL 7+).

Comprendre les fichiers d'unité Systemd

Un fichier d'unité Systemd est un fichier de configuration de style INI qui décrit une ressource gérée par Systemd. Pour les services, ces fichiers résident généralement dans /etc/systemd/system/ pour les services personnalisés ou définis par l'administrateur, ou dans /lib/systemd/system/ pour les services fournis par le fournisseur.

Les fichiers d'unité de service doivent se terminer par l'extension .service (par exemple, mydaemon.service). La structure est divisée en sections obligatoires et facultatives, les trois plus cruciales étant [Unit], [Service] et [Install].

Étape 1 : Création du script de service (l'exécutable)

Avant de créer le fichier d'unité, nous avons besoin d'un script ou d'une application simple que le service gérera. Pour cet exemple, nous allons créer un script de base qui enregistre un message toutes les 10 secondes.

Créer le répertoire et le fichier de script :

bash sudo mkdir -p /opt/my-custom-service sudo nano /opt/my-custom-service/reporter.sh
Ajouter le contenu suivant à reporter.sh :

```bash

!/bin/bash

LOG_FILE="/var/log/reporter.log"
while true; do
echo "$(date +'%Y-%m-%d %H:%M:%S') - Custom service heartbeat active." >> $LOG_FILE
sleep 10
done
```
Rendre le script exécutable :

bash sudo chmod +x /opt/my-custom-service/reporter.sh

Étape 2 : Définition du fichier d'unité de service personnalisé

Maintenant, nous créons le fichier d'unité Systemd qui indique à Systemd comment exécuter notre script.

Créer le fichier de service :

bash sudo nano /etc/systemd/system/my-reporter.service
Remplir le fichier avec les sections standard :

La section [Unit]

Cette section contient les métadonnées sur le service et définit ses relations avec d'autres unités (services, sockets, points de montage, etc.).

Description : Un nom lisible par l'homme pour le service.
After : Spécifie que ce service ne doit démarrer qu'après le démarrage réussi des unités listées.

[Unit]
Description=My Custom Reporter Daemon
# Démarrer uniquement après que les services de base de mise en réseau et de journalisation soient opérationnels
After=network.target

La section [Service]

C'est la section principale, qui définit quelle commande exécuter et comment Systemd doit gérer le processus.

Type : Définit le type de démarrage du processus. simple est standard pour les scripts qui s'exécutent en continu au premier plan.
User/Group : Spécifie sous quel contexte utilisateur exécuter le processus (fortement recommandé pour la sécurité).
ExecStart : Le chemin absolu de la commande ou du script à exécuter lors du démarrage du service.
Restart : Définit la politique de redémarrage automatique (par exemple, on-failure, always).

[Service]
Type=simple
User=your_username # IMPORTANT : Remplacez 'your_username' par un utilisateur non root si possible
Group=your_group # Facultatif, correspond généralement au groupe utilisateur

# La commande que Systemd exécute
ExecStart=/opt/my-custom-service/reporter.sh

# Politique de redémarrage
Restart=on-failure
RestartSec=5s # Attendre 5 secondes avant de tenter un redémarrage
StandardOutput=journal # Diriger la sortie vers le journal Systemd
StandardError=journal

Avertissement de sécurité : N'exécutez jamais de services personnalisés en tant qu'utilisateur root sauf si absolument nécessaire. Définissez un utilisateur dédié et disposant des privilèges minimum pour les processus d'application.

La section [Install]

Cette section spécifie comment le service doit être activé, en particulier, à quelle cible il doit être lié afin qu'il démarre automatiquement à l'heure de démarrage.

WantedBy : Spécifie la cible qui doit inclure ce service. Pour les services système standard qui doivent démarrer à l'heure de démarrage normale, multi-user.target est le choix standard.

[Install]
WantedBy=multi-user.target

Étape 3 : Rechargement, activation et démarrage du service

Après avoir créé ou modifié un fichier d'unité, vous devez indiquer à Systemd de recharger son démon de configuration, puis de gérer le nouveau service.

Recharger la configuration du gestionnaire Systemd :
Cette étape est obligatoire chaque fois qu'un fichier d'unité est ajouté ou modifié.

bash sudo systemctl daemon-reload
Activer le service (Démarrage automatique au démarrage) :
Ceci crée des liens symboliques à partir du répertoire cible approprié (par exemple, multi-user.target.wants/) pointant vers votre fichier de service, garantissant qu'il démarre automatiquement lors du démarrage du système.

bash sudo systemctl enable my-reporter.service
La sortie confirmera la création du lien symbolique.
Démarrer le service :
Ceci démarre immédiatement le processus défini dans ExecStart.

bash sudo systemctl start my-reporter.service

Étape 4 : Vérification du statut et des journaux du service

Il est crucial de vérifier que votre service a démarré correctement et fonctionne comme prévu.

Vérifier le statut :
La commande status fournit l'état actuel, les lignes de journal récentes et les détails d'exécution.

bash systemctl status my-reporter.service

Recherchez Active: active (running) dans la sortie.
Afficher les journaux (Journalctl) :
Puisque nous avons dirigé la sortie vers le journal dans la section [Service], nous pouvons utiliser journalctl pour voir les messages d'exécution.

bash journalctl -u my-reporter.service -f
Vérifier la sortie du fichier :
Vérifiez le fichier journal spécifié dans notre script :

bash tail -f /var/log/reporter.log

Commandes de gestion essentielles

Une fois défini, la gestion de votre service est simple à l'aide de la commande systemctl :

Action	Commande
Arrêter le service	`sudo systemctl stop my-reporter.service`
Redémarrer le service	`sudo systemctl restart my-reporter.service`
Désactiver le démarrage automatique	`sudo systemctl disable my-reporter.service`
Vérifier le statut	`systemctl status my-reporter.service`

Résumé et prochaines étapes

En maîtrisant les sections [Unit], [Service] et [Install], vous avez réussi à créer un service robuste et géré à l'aide de Systemd. Cette base vous permet de gérer des cycles de vie d'application complexes, garantissant un ordre de démarrage fiable, des redémarrages automatisés en cas d'échec et une journalisation centralisée via le journal Systemd.

Pour des cas d'utilisation plus avancés, explorez les options dans la section [Service] telles que EnvironmentFile pour le chargement de configuration, ou modifiez Type en forking pour la gestion traditionnelle des démons.