Maîtriser les fichiers de service Systemd : Un guide complet

Systemd est devenu la norme de facto pour la gestion des services et des processus système dans la plupart des distributions Linux modernes. Comprendre comment créer et gérer les fichiers d'unité de service systemd est crucial pour tout administrateur système ou développeur cherchant à déployer et maintenir des applications de manière fiable. Ce guide vous présentera les bases des fichiers de service systemd, de la syntaxe de base à la configuration avancée, vous permettant de gérer efficacement vos services Linux.

Cet article se concentre sur la création et la configuration de fichiers d'unité de service systemd à partir de zéro. Nous couvrirons la syntaxe fondamentale, explorerons les directives courantes et essentielles, et discuterons des meilleures pratiques pour une gestion robuste des services. À la fin de ce guide, vous serez équipé pour écrire vos propres fichiers de service systemd et garantir que vos applications fonctionnent de manière fluide et fiable.

Comprendre les fichiers d'unité Systemd

Systemd utilise des fichiers d'unité pour décrire diverses ressources système telles que les services, les sockets, les périphériques, les points de montage, et plus encore. Un fichier d'unité de service, se terminant généralement par l'extension .service, définit comment systemd doit gérer un démon ou une application spécifique.

Ces fichiers sont organisés en sections, chaque section contenant des paires clé-valeur représentant des directives de configuration. Les sections principales sur lesquelles nous nous concentrerons sont [Unit], [Service] et [Install].

Anatomie d'un fichier de service Systemd

Un fichier de service systemd typique a la structure suivante :

[Unit]
Description=Une brève description du service.
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/my_application --config /etc/my_app.conf
Restart=on-failure
User=myuser
Group=mygroup

[Install]
WantedBy=multi-user.target

Décortiquons chaque section et ses directives courantes :

La section `[Unit]`

Cette section fournit des métadonnées sur l'unité et définit sa relation avec d'autres unités. Elle est utilisée pour les dépendances et l'ordre.

Description= : Un nom lisible par l'homme pour le service. C'est ce que vous verrez dans la sortie de systemctl status.
Documentation= : URLs ou chemins vers la documentation du service.
Requires= : Définit des dépendances fortes. Si une unité listée ici échoue au démarrage, cette unité échouera également au démarrage.
Wants= : Définit des dépendances faibles. Si une unité listée ici échoue au démarrage, cette unité tentera quand même de démarrer.
Before= : Garantit que cette unité démarre avant les unités listées.
After= : Garantit que cette unité démarre après les unités listées. C'est très courant, par exemple, After=network.target garantit que le réseau est opérationnel avant le démarrage de votre service.
Conflicts= : Si une unité listée ici est démarrée, cette unité sera arrêtée, et vice-versa.

La section `[Service]`

Cette section configure le comportement du service lui-même. C'est là que vous définissez comment démarrer, arrêter et gérer le processus.

Type= : Spécifie le type de démarrage du processus. Les valeurs courantes incluent :
- simple (par défaut) : Le processus principal est celui spécifié dans ExecStart=. Systemd suppose que le service est démarré immédiatement après que le processus ExecStart= a été forké.
- forking : Le processus ExecStart= crée un processus enfant, et le parent se termine. Systemd considère le service comme démarré lorsque le parent se termine. Vous devez souvent spécifier PIDFile= avec ce type.
- oneshot : Similaire à simple, mais le processus est censé se terminer une fois son travail terminé. Utile pour les scripts de configuration.
- notify : Le démon envoie un message de notification à systemd lorsqu'il a démarré avec succès. C'est le type préféré pour les démons modernes qui le supportent.
- dbus : Le service acquiert un nom D-Bus.
ExecStart= : La commande à exécuter pour démarrer le service. C'est la directive la plus critique. Vous pouvez avoir plusieurs lignes ExecStart=, qui seront exécutées séquentiellement.
ExecStop= : La commande à exécuter pour arrêter le service.
ExecReload= : La commande à exécuter pour recharger la configuration du service sans le redémarrer.
Restart= : Définit quand le service doit être automatiquement redémarré. Valeurs courantes :
- no (par défaut) : Jamais redémarrer.
- on-success : Redémarrer uniquement si le service se termine proprement (code de sortie 0).
- on-failure : Redémarrer si le service se termine avec un code de sortie non nul, est terminé par un signal, ou expire.
- on-abnormal : Redémarrer s'il est terminé par un signal ou expire.
- on-abort : Redémarrer uniquement s'il est terminé anormalement par un signal.
- always : Toujours redémarrer, quel que soit le statut de sortie.
RestartSec= : Le temps de pause avant de redémarrer le service (par défaut 100 ms).
User= : L'utilisateur sous lequel exécuter le service.
Group= : Le groupe sous lequel exécuter le service.
WorkingDirectory= : Le répertoire vers lequel se déplacer avant d'exécuter les commandes.
Environment= : Définit les variables d'environnement pour le service.
EnvironmentFile= : Lit les variables d'environnement à partir d'un fichier.
PIDFile= : Chemin vers le fichier PID (souvent utilisé avec Type=forking).
StandardOutput= / StandardError= : Contrôle où vont stdout/stderr (par exemple, journal, syslog, null, inherit). journal est la valeur par défaut et est fortement recommandée pour la journalisation.

La section `[Install]`

Cette section définit comment l'unité doit être activée ou désactivée, généralement en créant des liens symboliques.

WantedBy= : Spécifie la cible qui doit "vouloir" ce service lorsqu'il est activé. Valeurs courantes :
- multi-user.target : Pour les services qui doivent démarrer lorsque le système atteint un état de ligne de commande multi-utilisateur.
- graphical.target : Pour les services qui doivent démarrer lorsque le système atteint un état de connexion graphique.

Créer votre premier fichier de service Systemd

Créons un fichier de service simple pour un script Python hypothétique nommé my_app.py situé à /opt/my_app/my_app.py.

1. Créez le fichier de service :

Les fichiers de service pour les applications personnalisées sont généralement placés dans /etc/systemd/system/. Nommons notre fichier my_app.service.

# Créez le répertoire s'il n'existe pas
sudo mkdir -p /etc/systemd/system/

# Créez le fichier de service à l'aide d'un éditeur de texte
sudo nano /etc/systemd/system/my_app.service

2. Ajoutez le contenu suivant à my_app.service :

[Unit]
Description=Mon application Python personnalisée
After=network.target

[Service]
Type=simple
User=appuser
Group=appgroup
WorkingDirectory=/opt/my_app/
ExecStart=/usr/bin/python3 /opt/my_app/my_app.py
Restart=on-failure

[Install]
WantedBy=multi-user.target

Explication de l'exemple :

Description : Identifie clairement notre application.
After=network.target : Garantit que le réseau est disponible avant le démarrage.
Type=simple : Suppose que my_app.py est le processus principal et qu'il ne crée pas de fork.
User=appuser, Group=appgroup : Spécifie l'utilisateur et le groupe sous lesquels l'application doit s'exécuter. Assurez-vous que ces utilisateurs et groupes existent sur votre système et ont les permissions appropriées. Vous pourriez avoir besoin de les créer :
bash sudo groupadd appgroup sudo useradd -r -g appgroup appuser sudo chown -R appuser:appgroup /opt/my_app/
WorkingDirectory : Définit le contexte du script.
ExecStart : La commande pour exécuter le script Python. Assurez-vous que /usr/bin/python3 est le chemin correct vers votre interpréteur Python et que le script est exécutable.
Restart=on-failure : Si le script plante, systemd essaiera de le redémarrer.
WantedBy=multi-user.target : Ce service sera démarré automatiquement lorsque le système démarre dans un environnement multi-utilisateur.

3. Rechargez la configuration du gestionnaire systemd :

Après avoir créé ou modifié un fichier de service, vous devez indiquer à systemd de recharger sa configuration.

sudo systemctl daemon-reload

4. Activez et démarrez le service :

Enable : Cela permet au service de démarrer automatiquement au démarrage.
bash sudo systemctl enable my_app.service
Start : Cela démarre le service immédiatement.
bash sudo systemctl start my_app.service

5. Vérifiez le statut du service :

Pour vérifier si votre service s'exécute et pour voir d'éventuelles erreurs :

sudo systemctl status my_app.service

En cas de problème, la commande status affichera souvent des messages d'erreur ou des journaux de journald.

6. Affichage des journaux :

Systemd s'intègre à journald pour la journalisation. Vous pouvez afficher les journaux de votre service en utilisant :

sudo journalctl -u my_app.service

Vous pouvez également suivre les journaux en temps réel :

sudo journalctl -f -u my_app.service

Autres commandes utiles :

Arrêter le service : sudo systemctl stop my_app.service
Redémarrer le service : sudo systemctl restart my_app.service
Recharger la configuration (si supporté par l'application) : sudo systemctl reload my_app.service
Désactiver le démarrage automatique au démarrage : sudo systemctl disable my_app.service

Configuration avancée et meilleures pratiques

Considérations de sécurité :

Exécutez les services sous des utilisateurs non root : Spécifiez toujours User= et Group= sauf si absolument nécessaire. Cela suit le principe du moindre privilège.
Isolez les services : Envisagez d'utiliser des fonctionnalités de sandboxing comme PrivateTmp=true, ProtectSystem=true, NoNewPrivileges=true pour une sécurité accrue.
- PrivateTmp=true : Donne au service ses propres répertoires /tmp et /var/tmp privés.
- ProtectSystem=true : Rend /usr, /boot, /etc en lecture seule.
- NoNewPrivileges=true : Empêche le service d'acquérir de nouveaux privilèges.

Gestion des démarrages complexes :

Type=forking avec PIDFile= : Pour les applications plus anciennes qui utilisent le fork, assurez-vous que PIDFile= pointe vers le bon fichier.
Type=notify : Si votre application le prend en charge, c'est le moyen le plus robuste pour systemd de savoir quand elle est réellement prête.
ExecStartPre= et ExecStartPost= : Commandes à exécuter avant et après ExecStart=. Utile pour les tâches de configuration ou de nettoyage.

Contrôle des ressources :

Systemd vous permet de limiter l'utilisation des ressources :

CPUShares= : Allocation relative du temps CPU.
MemoryLimit= : Mémoire maximale que le service peut utiliser.
IOWeight= : Bande passante I/O relative.

Exemple :

[Service]
# ... autres directives ...
MemoryLimit=512M
CPUShares=512 # Environ 50% du temps CPU par rapport à la valeur par défaut de 1024

Minuteurs vs Cron

Les minuteurs systemd offrent une alternative moderne aux tâches cron traditionnelles. Ils sont plus flexibles et s'intègrent mieux à la gestion des journaux et des dépendances de systemd.

Cron : Tâches planifiées définies dans les fichiers crontab.
Minuteurs Systemd (.timer units) : Ces unités planifient des unités .service. Vous définissez un fichier .timer qui spécifie quand un fichier .service correspondant doit s'exécuter.

Exemple :

Pour exécuter un script quotidiennement à 3h du matin :

my_script.service : Le service à exécuter.
```ini
[Unit]
Description=Mon script quotidien

[Service]
Type=oneshot
ExecStart=/opt/my_scripts/run_daily.sh
User=scriptuser
```
my_script.timer : Le minuteur qui planifie le service.
```ini
[Unit]
Description=Exécuter mon script quotidien une fois par jour

[Timer]

Exécuter tous les jours à 03:00:00

OnCalendar=--* 03:00:00
Persistent=true # Exécuter immédiatement si manqué en raison d'une interruption

[Install]
WantedBy=timers.target
```

Pour utiliser ceci :

Placez les deux fichiers dans /etc/systemd/system/.
Exécutez sudo systemctl daemon-reload.
Activez et démarrez le minuteur : sudo systemctl enable my_script.timer et sudo systemctl start my_script.timer.

Les minuteurs offrent des avantages tels que Persistent=true (exécute les travaux manqués au démarrage), les événements de calendrier (comme hourly, daily, weekly), et une meilleure intégration avec journalctl.

Dépannage des problèmes courants

Le service ne démarre pas : Vérifiez systemctl status <nom_du_service> et journalctl -u <nom_du_service>. Recherchez les fautes de frappe, les chemins incorrects, les dépendances manquantes ou les erreurs de permission.
Type= incorrect : Si un service échoue immédiatement ou se bloque, le Type= pourrait être erroné. Essayez simple ou forking et assurez-vous que PIDFile est correct si vous utilisez forking.
Permission refusée : Assurez-vous que l'utilisateur et le groupe spécifiés dans User= et Group= ont les droits de lecture/écriture sur les fichiers et répertoires nécessaires.
Variables d'environnement : Si votre application dépend de variables d'environnement spécifiques, assurez-vous qu'elles sont correctement définies en utilisant Environment= ou EnvironmentFile=.
Dépendances : Vérifiez que les directives After= et Requires= sont correctement définies pour garantir que les prérequis sont satisfaits avant le démarrage de votre service.

Conclusion

Les fichiers de service systemd sont un outil puissant pour gérer les applications sous Linux. En comprenant la structure des fichiers d'unité, le but des directives clés et les meilleures pratiques de configuration, vous pouvez améliorer considérablement la fiabilité, la sécurité et la facilité de gestion de vos services. Que vous déployiez un script simple ou une application complexe, maîtriser les fichiers de service systemd est une compétence essentielle pour l'administration système Linux moderne.

N'oubliez pas de toujours tester vos fichiers de service minutieusement, d'utiliser systemctl status et journalctl pour le débogage, et de tirer parti des fonctionnalités de sécurité que systemd fournit.