1. Anatomie d’un fichier d’unité systemd (.service)

Les services créés par l’administrateur doivent être placés dans /etc/systemd/system/ (prioritaire sur les unités système livrées par les paquets dans /lib/systemd/system/). Un fichier type se compose de trois sections obligatoires :

# Fichier : /etc/systemd/system/api-swiss-data.service
[Unit]
Description=API de synchronisation bancaire SwissData
Documentation=https://docs.educasuisse.ch/api-swissdata
After=network.target postgresql.service
Requires=postgresql.service

[Service]
Type=simple
User=appuser
Group=appgroup
WorkingDirectory=/opt/swissdata
ExecStart=/opt/swissdata/bin/api-server --port 8080 --config /etc/swissdata/config.yaml
ExecReload=/bin/kill -HUP 
Restart=on-failure
RestartSec=5s

# Durcissement de sécurité et isolation
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true
PrivateTmp=true

# Limitation des ressources via cgroups v2
MemoryMax=1G
CPUQuota=150%

[Install]
WantedBy=multi-user.target

2. Explication des directives critiques

  • After vs Requires : After définit uniquement l’ordre temporel de démarrage. Requires crée une dépendance forte : si postgresql échoue à démarrer, le service sera refusé.
  • Type=simple vs forking : simple est privilégié pour les applications modernes restant au premier plan. forking s’applique aux démons historiques qui effectuent un double-fork en arrière-plan.
  • Restart=on-failure : Garantit la reprise d’activité automatique en cas de crash (exit code non nul ou signal inattendu), avec temporisation de 5 secondes via RestartSec pour éviter les boucles infinies de crash.

3. Cycle de prise en compte et validation

Toute modification d’un fichier d’unité exige d’informer le démon systemd :

# Recharger la table interne des unités
sudo systemctl daemon-reload

# Activer et démarrer immédiatement le nouveau service
sudo systemctl enable --now api-swiss-data.service

# Valider la conformité de l'unité avec l'analyseur statique
systemd-analyze verify /etc/systemd/system/api-swiss-data.service

Sécurité système avancée : Les directives ProtectSystem=full montent /usr et /boot en lecture seule pour le processus, empêchant un pirate d’altérer les binaires système même en cas d’exploitation d’une faille dans le code applicatif.