Fiche de référence : principales options d’un fichier .service

Exemple commenté par les tableaux ci-dessous

Exemple documentaire : l’utilisateur et l’exécutable doivent exister avant utilisation.

[Unit]
Description=Mon application
After=network.target

[Service]
Type=simple
User=monapp
WorkingDirectory=/opt/monapp
ExecStart=/opt/monapp/bin/serveur
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Section [Unit] : description et dépendances

Option	Rôle
Description=	Description lisible
After= / Before=	Ordre relatif si les unités concernées sont démarrées ; ne les démarre pas à lui seul
Wants=	Demande une autre unité ; son échec n’empêche généralement pas ce service de démarrer
Requires=	Dépendance forte, généralement combinée à un ordre comme After=
StartLimitIntervalSec=	Fenêtre de contrôle de la fréquence des démarrages
StartLimitBurst=	Nombre de démarrages autorisés dans cette fenêtre

Avec Requires= et After=, l’échec d’activation de la dépendance peut empêcher ce service de démarrer. Ce n’est pas une vérification continue de la santé applicative ; des relations plus strictes existent, comme BindsTo=.

After=network.target ne garantit pas une connexion réseau opérationnelle. Même une attente de network-online.target ne garantit pas qu’un serveur distant soit accessible : l’application doit gérer les interruptions.

Section [Service] : exécution

Option	Rôle
Type=	Modèle de démarrage du programme
ExecStart=	Exécutable et arguments
ExecStartPre=	Préparation avant le programme principal
ExecStop=	Procédure d’arrêt spécifique, si nécessaire
ExecReload=	Commande de rechargement de la configuration applicative
User= / Group=	Identité d’exécution
WorkingDirectory=	Répertoire de travail
Environment=	Variables, par exemple Environment=APP_MODE=lab
EnvironmentFile=	Fichier de variables ; ce n’est pas un script shell
Restart=	Politique de relance
RestartSec=	Délai avant relance
TimeoutStartSec= / TimeoutStopSec=	Limites temporelles de démarrage et d’arrêt, selon le type de service
StandardOutput= / StandardError=	Destination des sorties, notamment journal
RemainAfterExit=	Avec une tâche terminée, conserve éventuellement l’état actif ; utile dans certains services oneshot

Types à connaître :

• simple : processus au premier plan ; considéré démarré très tôt, sans garantie de disponibilité applicative.
• exec : attend que l’exécution du programme réussisse avant de considérer le démarrage effectué ; ne garantit pas non plus sa disponibilité applicative.
• oneshot : tâche qui se termine ; systemd attend son achèvement.
• notify : programme qui signale explicitement qu’il est prêt.
• forking : programme se détachant en arrière-plan ; fréquent dans des services plus anciens.

Politiques de relance :

• Restart=no : pas de relance automatique.
• Restart=on-failure : relance sur les échecs reconnus par systemd.
• Restart=always : relance aussi après une sortie normale, pour les types compatibles.
• Un arrêt demandé avec systemctl stop ne déclenche pas une relance, même avec always.
• Les limites de démarrage peuvent interrompre des relances trop fréquentes.

Points d’attention :

• Dans une unité système, sans User=, le programme s’exécute généralement en root. Le programme sleep de démonstration est volontairement minimal ; une application réelle doit utiliser une identité adaptée.
• ExecStart= n’est pas interprété par un shell : |, > et && n’y fonctionnent pas comme dans un terminal.
• Les variables d’environnement ne constituent pas un stockage approprié pour tous les secrets ; les mécanismes de credentials systemd seront étudiés plus tard.

Section [Install] : activation

WantedBy=multi-user.target indique à enable les liens à créer pour rattacher le service à cette cible. Cette section ne démarre pas elle-même le programme.

Routine de vérification après modification

sudo systemd-analyze verify /etc/systemd/system/lab-demo.service
sudo systemctl daemon-reload
sudo systemctl restart lab-demo.service
systemctl status lab-demo.service --no-pager --full
sudo journalctl -u lab-demo.service -b -n 20 --no-pager --full

verify contrôle la définition ; ce n’est pas une garantie que l’application fonctionnera correctement.

Questions et réponses

1. Pourquoi daemon-reload après une modification ? Pour actualiser la définition conservée par systemd.
2. stop retire-t-il l’activation au démarrage ? Non.
3. disable arrête-t-il le processus ? Non, sauf avec --now.
4. After= démarre-t-il une dépendance ? Non ; il exprime un ordre.
5. Restart=always annule-t-il un stop volontaire ? Non.
6. active prouve-t-il qu’une application répond correctement ? Non : vérifier également son fonctionnement réel.