Mise à niveau et migration de systemd avec exemples pratiques

Introduction

Mettre à niveau systemd est courant sur Linux moderne, mais cela touche PID 1, la supervision des services, la journalisation et l'ordonnancement du boot. Une modification mal préparée peut immobiliser une machine en mode emergency ou casser des services critiques (Docker, Nginx, etc.). Ce guide propose une voie concrète et sans drame pour réaliser une systemd upgrade ou une systemd migration, valider le comportement et récupérer rapidement si quelque chose se passe mal. Vous obtiendrez un workflow clair, un pilote local sécurisé, des commandes pratiques et des exemples concrets pour services et timers.

Pour la clarté, nous évoquons explicitement systemd upgrade, systemd migration, systemd version upgrade, ainsi qu'un chemin de systemd rollback soutenu par une systemd validation méthodique.

Aperçu du workflow

Rendez l'upgrade prédictible en suivant ces étapes :

Évaluer : inventorier services, timers, drop-ins et scripts custom. Repérer ce qui est non standard.
Sécuriser : capturer l'état OS/paquets, activer les journaux persistants, préparer des snapshots et les commandes de retour arrière.
Piloter : exécuter une petite action mesurable sur un hôte/VM non critique.
Mettre en scène et upgrader : mettre à jour systemd et les bibliothèques associées, planifier un créneau de redémarrage contrôlé.
Valider : confirmer cibles de boot, services, timers, et la critical-chain. Inspecter les logs pour détecter les régressions.
Migrer les unités : convertir des scripts hérités, affiner les types d'unités et le sandboxing (exemples ci-dessous).
Observer : surveiller 24-72 h. Revenir en arrière rapidement en cas de régression.

Checklist de préparation

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

Baseline et inventaire

Enregistrer les versions :
systemctl --version
cat /etc/os-release
Lister unités activées et surcharges :
systemctl list-unit-files --type=service --state=enabled
systemd-delta
Inventorier timers et crons :
systemctl list-timers --all
crontab -l; sudo ls -1 /etc/cron.*

Journaux et logging

Activer la journalisation persistante pour lire après reboot :
sudo mkdir -p /var/log/journal && sudo systemd-tmpfiles --create --prefix /var/log/journal

Console et accès

Prévoir un accès hors bande (serial/IPMI/tty) si SSH ne revient pas.
Garder un shell root ouvert sur la console ou dans tmux ; éviter toute déconnexion en plein upgrade.

Snapshots et voie de downgrade

Snapshot du système de fichiers :
LVM : sudo lvcreate -s -n root-pre-sd -L 10G /dev/vg/root
Btrfs : sudo btrfs subvolume snapshot -r / @ /@snapshots/@pre-systemd
Préparer le rollback paquets :
Debian/Ubuntu : sudo apt-cache policy systemd; noter la candidate et la version 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 un reboot même s'il n'est pas strictement requis. Les redémarrages exposent des soucis d'ordonnancement qu'il faut valider.

Pilotage local

Démarrer sur une machine ou VM et un objectif mesurable. Exemple : mettre à niveau systemd, convertir un cron en timer, puis vérifier le boot et la santé des services.

Périmètre du pilote

Hôte : VM non critique qui reflète les unités de prod.
Changement 1 : effectuer la mise à niveau systemd vers la version cible.
Changement 2 : convertir un petit cron quotidien en timer systemd.
Critères de succès :
L'hôte redémarre proprement sur la cible par défaut.
0 unité en échec (systemctl --failed).
Le timer se déclenche et termine une fois avec code 0.
Aucun nouveau message niveau err ou supérieur 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 reboot, relancer les mêmes vérifications et comparer.

Exécution de la mise à niveau

Debian/Ubuntu (apt)

Mettre à jour l'index et revoir les versions :
sudo apt-get update
apt-cache policy systemd
Limiter le périmètre en mettant à jour systemd en premier :
sudo apt-get install --yes systemd libsystemd0
Planifier et exécuter un reboot contrôlé :
sudo systemctl reboot

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

Rafraîchir les métadonnées et voir les versions :
sudo dnf --refresh info systemd
Mettre à jour systemd et ses 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 unités pour prendre les changements de packaging :
sudo systemctl daemon-reload
Purger un état d'unité obsolète si besoin :
sudo systemctl reset-failed

Validation après upgrade

Boot et cibles

Confirmer la cible par défaut et l'état global :
systemctl get-default
systemctl is-system-running
Inspecter la critical-chain pour repérer lenteurs et blocages :
systemd-analyze critical-chain

Services et sockets

Rechercher des échecs et l'état degraded :
systemctl --failed
Valider les services clés (exemple : Nginx) :
systemctl status nginx
sudo journalctl -u nginx -b --no-pager | tail -50

Journaux et erreurs

Balayer les messages haute priorité depuis le boot :
journalctl -b -p err..alert --no-pager

Timers et tâches

Lister et vérifier les timers :
systemctl list-timers
Déclencher un timer pour test :
sudo systemctl start mybackup.timer; sudo systemctl status mybackup.service

Vérification des unités

Vérifier statiquement les unités :
sudo systemd-analyze verify /etc/systemd/system/*.service

Réseau et accès distant

Confirmer network-online et la cible multi-user :
systemctl status NetworkManager.service | head -20
systemctl status systemd-networkd.service | head -20

En cas d'anomalie, capturer les logs et enclencher un rollback ou une remédiation avant d'élargir le déploiement.

Exemples de migration

Exemple A : Convertir une appli SysV en service natif

Supposons /etc/init.d/myapp qui pilote un binaire simple. Remplacez par /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

Exemple B : Drop-in pour ajuster un service (nginx)

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

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

Exemple C : Convertir un cron en timer

Cron d'origine (quotidien à 02:15) : sauvegarde de /srv vers /backups.

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

[Unit]
Description=Nightly backup

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

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

[Unit]
Description=Run nightly backup at 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

Exemple D : Vérifier et resserrer après upgrade

Chercher les deltas et directives dépréciées :
systemd-delta
sudo systemd-analyze verify /etc/systemd/system/*.service
Envisager Type=notify pour les services signalant leur disponibilité, ou ajouter des ExecStartPre qui échouent vite.

Retour arrière et récupération

Décisions de rollback rapides

Si l'hôte boote mais que des services clés échouent : downgrader les paquets et rétablir les unités.
Si l'hôte n'atteint pas multi-user : booter en rescue, restaurer un snapshot ou downgrader systemd.

Boot en mode rescue ou emergency

Au bootloader, éditer la ligne du kernel et ajouter :

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

Une fois en shell de secours, inspecter les journaux :

journalctl -xb --no-pager | less

Downgrade des 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 agencement.

Rollback des unités

Supprimer ou renommer les drop-ins sous /etc/systemd/system/*.d
Restaurer les unités depuis sauvegarde, puis :

sudo systemctl daemon-reload
sudo systemctl restart affected.service

Après rollback

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

Conclusion

Considérez la mise à niveau et la migration de systemd comme un changement incrémental et testable, pas un saut de foi. Inventoriez d'abord, préparez un retour arrière, pilotez localement, puis mettez à niveau, validez et observez avant un déploiement large. Utilisez des unités natives et des timers ainsi que des drop-ins pour amener vos services sous une supervision fiable. Prochaine étape : lancez un pilote sur un hôte non critique cette semaine, convertissez un cron en timer et rédigez un court runbook pour votre fenêtre de changement.