Mise à niveau et migration de systemd : guide pratique avec exemples

Intro

La mise à niveau de systemd est courante sur les Linux modernes, mais elle touche PID 1, la supervision des services, la journalisation et l'ordre de démarrage. Une modification mal préparée peut laisser un hôte en mode d'urgence ou casser des services critiques. Ce guide présente un parcours pratique, sans drame, pour upgrader ou migrer vers des versions plus récentes de systemd, valider le comportement et récupérer rapidement en cas de problème. Vous obtiendrez un workflow clair, un pilote local sûr, des commandes concrètes et des exemples pour services et timers.

Workflow Overview

Suivez ces étapes pour rendre les upgrades prévisibles :

Évaluer : inventorier services, timers, drop-ins et scripts personnalisés. Repérer tout élément non standard.
Préparer la sécurité : capturer les infos OS et paquets, activer les journaux persistants, préparer snapshots et commandes de rollback.
Piloter : exécuter une petite tâche d'upgrade mesurable sur un hôte ou VM non critique.
Stager et upgrader : mettre à jour les paquets systemd et bibliothèques associées, puis planifier une fenêtre de redémarrage contrôlée.
Valider : confirmer les cibles de démarrage, services, timers et le timing de la chaîne critique. Inspecter les logs pour détecter les régressions.
Migrer les unités : convertir les scripts legacy ou affiner les types d'unités et le sandboxing avec les exemples ci‑dessous.
Observer : surveiller pendant 24‑72 heures. Revenir en arrière rapidement si des régressions apparaissent.

Preparation Checklist

Exécutez les commandes sur un hôte de test d'abord, puis en production pendant une fenêtre avec accès console.

Baseline et inventaire

Enregistrer les versions actuelles :

systemctl --version
cat /etc/os-release

Lister les unités activées et les overrides :

systemctl list-unit-files --type=service --state=enabled
systemd-delta

Inventorier timers et jobs cron :

systemctl list-timers --all
crontab -l
sudo ls -1 /etc/cron.*

Journaux et journalisation

Assurer la journalisation persistante pour lire les logs après redémarrage :

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

Console et accès

S'assurer d'un accès out‑of‑band (série/IPMI/tty) au cas où SSH ne remonterait pas.
Garder un shell root ouvert sur la console ou une session tmux ; éviter de se déconnecter en plein upgrade.

Snapshots et chemin de downgrade

Snapshot système de fichiers recommandé :
LVM : sudo lvcreate -s -n root-pre-sd -L 10G /dev/vg/root
Btrfs : sudo btrfs subvolume snapshot -r / @ /@snapshots/@pre-systemd
Préparation rollback paquets :
Debian/Ubuntu : sudo apt-cache policy systemd ; noter la version candidate et celle installée. Optionnel apt download systemd systemd-sysv libsystemd0
RHEL/Fedora : sudo dnf history list systemd ; noter le dernier NVR connu bon

Fenêtre de changement

Planifier une fenêtre de redémarrage même si non strictement requis. Les redémarrages révèlent les problèmes d'ordre à valider.

Local Pilot Plan

Commencez avec un hôte ou VM unique et un objectif mesurable. Exemple de pilote : upgrader systemd, convertir un cron en timer, vérifier le démarrage et la santé des services.

Périmètre du pilote

Hôte : VM non critique qui reflète les unités de production.
Changement 1 : upgrader systemd vers la version cible.
Changement 2 : convertir un petit job cron quotidien en timer systemd.
Critères de succès :
Hôte redémarre proprement vers la cible par défaut.
0 unités en échec (systemctl --failed).
Timer se déclenche et se termine une fois avec code de sortie 0.
Aucune nouvelle erreur de priorité err ou supérieure dans journalctl -b -p err..alert.

Commandes du pilote

Valider la baseline :

systemctl --version
systemctl list-units --failed
journalctl -b -p warning..alert --no-pager | tail -n +1

Après upgrade et redémarrage, relancer les mêmes vérifications et comparer.

Upgrade Execution

Debian/Ubuntu (apt)

Mettre à jour les méta‑données et revoir les versions :

sudo apt-get update
apt-cache policy systemd

Upgrader seulement systemd d'abord pour limiter le blast radius :

sudo apt-get install --yes systemd libsystemd0

Planifier une fenêtre de redémarrage contrôlée :

sudo systemctl reboot

RHEL/CentOS/Alma/Rocky/Fedora (dnf)

Rafraîchir les méta‑données et revoir les versions :

sudo dnf --refresh info systemd

Upgrader systemd et bibliothèques :

sudo dnf upgrade -y systemd systemd-libs

Redémarrer pendant la fenêtre de changement :

sudo systemctl reboot

Hygiène post‑upgrade

Recharger les fichiers d'unité pour prendre en compte les changements d'empaquetage :

sudo systemctl daemon-reload

Nettoyer tout état d'unité obsolète si nécessaire :

sudo systemctl reset-failed

Validation

Démarrage et cibles

Confirmer la cible par défaut et l'accessibilité :

systemctl get-default
systemctl is-system-running

Inspecter la chaîne critique pour services lents ou bloqués :

systemd-analyze critical-chain

Services et sockets

Rechercher échecs et état dégradé :

systemctl --failed

Valider services clés (exemple nginx) :

systemctl status nginx
sudo journalctl -u nginx -b --no-pager | tail -50

Journaux et erreurs

Scanner les messages haute priorité depuis le boot :

journalctl -b -p err..alert --no-pager

Timers et tâches

Lister et vérifier timers :

systemctl list-timers

Déclencher un timer à l'avance pour test :

sudo systemctl start mybackup.timer
sudo systemctl status mybackup.service

Vérification d'unités

Vérifier statiquement les fichiers d'unité pour problèmes courants :

sudo systemd-analyze verify /etc/systemd/system/*.service

Réseau et accès distant

Confirmer la cible network-online et l'accessibilité multi‑user :

systemctl status NetworkManager.service | head -20
systemctl status systemd-networkd.service | head -20

Si quelque chose semble anormal, capturer les logs et passer au rollback ou à la remédiation avant d'élargir le déploiement.

Migration Examples

Example A : Convertir une application SysV en service natif

Supposons /etc/init.d/myapp gérait un binaire simple. Le remplacer par une unité native à /etc/systemd/system/myapp.service :

[Unit]
Description=MyApp REST API
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
EnvironmentFile=-/etc/myapp/env
ExecStart=/opt/myapp/bin/myapp --port=8080
Restart=on-failure
RestartSec=2s
# Durcissement ressources et sécurité
LimitNOFILE=65536
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true
AmbientCapabilities=

[Install]
WantedBy=multi-user.target

Activer et démarrer :

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service

Valider :

systemctl status myapp
journalctl -u myapp -b --no-pager | tail -100

Example B : Ajouter un drop-in pour tuner un service existant (nginx)

Créer un drop-in pour augmenter la limite de descripteurs sans modifier l'unité fournie :

sudo systemctl edit nginx

Cela crée /etc/systemd/system/nginx.service.d/override.conf avec :

[Service]
LimitNOFILE=131072

Appliquer et valider :

sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl show nginx -p LimitNOFILE

Example C : Convertir un job cron en timer

Cron original (quotidien à 02:15) : sauvegarde /srv vers /backups.

Créer service /etc/systemd/system/backup.service :

[Unit]
Description=Sauvegarde nocturne

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/backup.sh /srv /backups
Nice=10
IOSchedulingClass=best-effort
IOSchedulingPriority=6

Créer timer /etc/systemd/system/backup.timer :

[Unit]
Description=Lancer la sauvegarde nocturne à 02:15

[Timer]
OnCalendar=*-*-* 02:15:00
RandomizedDelaySec=5m
Persistent=true

[Install]
WantedBy=timers.target

Activer et tester :

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers | grep backup
sudo systemctl start backup.service
systemctl status backup.service

Example D : Vérifier et durcir les unités après upgrade

Chercher deltas et directives dépréciées :

systemd-delta
sudo systemd-analyze verify /etc/systemd/system/*.service

Envisager Type=notify pour services signalant leur prêts, ou ajouter ExecStartPre pour échouer vite.

Rollback and Recovery

Décisions de rollback rapides

Si l'hôte démarre mais services clés échouent : downgrader les paquets et rétablir les changements d'unités.
Si l'hôte n'atteint pas multi‑user : démarrer en rescue, restaurer depuis snapshot ou downgrader systemd.

Démarrer en rescue ou emergency

Au chargeur de démarrage, éditer la ligne de commande kernel pour inclure :

systemd.unit=rescue.target
systemd.unit=emergency.target

Une fois dans le shell rescue, inspecter les logs :

journalctl -xb --no-pager | less

Downgrade de paquets

Debian/Ubuntu :

apt-cache madison systemd
sudo apt-get install systemd=VERSION libsystemd0=VERSION
sudo apt-mark hold systemd libsystemd0 # optionnel

RHEL/Fedora :

sudo dnf history systemd
sudo dnf downgrade -y systemd systemd-libs

Restauration de snapshot

LVM :

sudo lvconvert --merge /dev/vg/root-pre-sd
sudo reboot

Btrfs :

Monter le snapshot et restaurer ou utiliser une stratégie de rollback de sous‑volume adaptée à votre layout.

Rollback des changements d'unités

Supprimer ou renommer les drop-ins sous /etc/systemd/system/*.d
Restaurer les fichiers d'unité précédents depuis la sauvegarde, puis :

sudo systemctl daemon-reload
sudo systemctl restart affected.service

Post‑rollback

Documenter la cause racine et ajuster la checklist de validation avant la prochaine tentative.

Conclusion

Traitez les upgrades et migrations systemd comme un changement incrémental et testable, pas comme un saut dans l'inconnu. Inventoriez d'abord, préparez un rollback, lancez un pilote étroit, puis upgrader, valider et surveiller avant déploiement large. Utilisez des unités et timers natifs avec drop-ins pour placer vos services personnalisés sous supervision fiable. Gardez vos chemins de rescue et downgrade documentés et testés. Prochaines étapes : exécuter le pilote sur un hôte non critique cette semaine, convertir un job cron en timer, et rédiger un runbook court pour votre fenêtre de changement production.