Ubuntu 24.04 : Redémarrage requis… mais impossible de redémarrer — planifier la maintenance intelligemment

octobre 30, 2025 • février 3, 2026 • Lecture : 28 min • Views: 7

Cet article vous a aidé ?

Vous avez patché une CVE. Vous avez exécuté les mises à jour. Maintenant Ubuntu vous indique poliment qu’un redémarrage est requis, comme s’il vous demandait d’arroser une plante d’intérieur.
Pendant ce temps, vous regardez une machine de production qui est en train de générer le chiffre d’affaires de l’entreprise, gérer l’identité, ou servir de tête de stockage.

C’est là que beaucoup d’équipes font l’un des deux mauvais choix : redémarrer impulsivement et provoquer une interruption, ou reporter indéfiniment en l’appelant une « acceptation du risque ».
La bonne réponse est généralement ni l’un ni l’autre. C’est un report contrôlé avec un plan, un rayon d’action réduit, et des décisions basées sur des preuves.

Ce que « redémarrage requis » signifie réellement sur Ubuntu 24.04

Sur Ubuntu, « redémarrage requis » n’est pas une condition unique. C’est un ensemble de signaux qui sont souvent compressés en un seul badge rouge dans un tableau de bord.
Votre travail consiste à les retrancher en catégories et décider de ce qui bloque vraiment et de ce qui est gérable.

« Redémarrage requis » signifie généralement une des choses suivantes

Noyau mis à jour : Un nouveau paquet kernel est installé mais vous exécutez l’ancien noyau. Les correctifs de sécurité peuvent ne pas être actifs tant que vous n’avez pas redémarré.
libc ou chargeur cœur mis à jour : glibc, le chargeur dynamique ou des bibliothèques fondamentales similaires ont été mises à jour. Les processus longue durée conservent d’anciennes mappings.
Firmware/microcode mis à jour : Les microcodes Intel/AMD peuvent nécessiter un redémarrage pour être chargés au démarrage.
Bibliothèques système mises à jour : Des services peuvent nécessiter un redémarrage ; le reboot est l’outil brutal qui le garantit.
Mises à jour de la pile filesystem/stockage : Modules ZFS, multipath, particularités NVMe ou changements de pilotes peuvent nécessiter un redémarrage pour charger proprement les nouveaux modules.

Ubuntu 24.04 (Noble) est assez moderne pour que l’approche « redémarrer tout » soit à la fois plus possible et plus dangereuse.
Plus possible, parce que systemd et needrestart peuvent identifier les processus affectés. Plus dangereuse, parce que les charges sont plus stateful,
plus distribuées et plus couplées qu’à l’époque où « fenêtre de maintenance » voulait dire « dimanche à 2h du matin, personne ne s’en soucie ».

Si vous ne pouvez pas redémarrer maintenant, votre objectif est de répondre à trois questions avec des preuves :

Qu’est-ce qui a changé ? Le noyau, la libc, OpenSSL, systemd, les pilotes de stockage—soyez précis.
Qu’est-ce qui est actuellement vulnérable ou incohérent ? Version du noyau en cours d’exécution, modules chargés, démons de longue durée.
Quelle est votre action intérimaire la plus sûre ? Redémarrer des services sélectionnés, vider des nœuds, basculer, ou appliquer des live patches.

Si cela ressemble à du travail, oui. C’est le job. L’uptime n’est pas gratuit ; c’est un abonnement que vous payez avec de la planification et de la discipline.

Faits et contexte historique qui modifient la planification des redémarrages

Quelques petits faits valent la peine d’être gardés en tête parce qu’ils changent la décision par défaut de « redémarrer à chaque fois » à « redémarrer délibérément ».
Ce ne sont pas des anecdotes ; ce sont les raisons pour lesquelles votre parc se comporte comme il le fait.

Le répertoire /var/run est maintenant /run (un tmpfs) sur les Linux modernes. Les redémarrages et même certains redémarrages de services effacent l’état runtime.
unattended-upgrades existe depuis des années et est bon pour installer des correctifs de sécurité, mais il ne fait pas recharger automatiquement les processus en mémoire.
Le live patching du noyau est devenu courant dans les années 2010 à mesure que les flottes grandissaient ; il réduit le risque pour certaines CVE mais pas pour tous les changements.
L’essor de systemd a changé le comportement des redémarrages : les graphes de dépendances et l’activation par socket peuvent masquer ou révéler des indisponibilités selon la configuration des services.
« Redémarrage requis » est souvent un contrôle de fichier : sur Ubuntu, /var/run/reboot-required (ou /run/reboot-required) est créé par les paquets. C’est un indice, pas un oracle.
Les mises à jour de glibc sont célèbres parce que les processus longue durée peuvent garder d’anciennes versions en mémoire ; vous pouvez « patcher » le disque et exécuter encore de l’ancien code pendant des semaines.
Les mises à jour microcode sont devenues une opération normale après des vulnérabilités CPU à fort impact ; elles ne sont plus exotiques et doivent faire partie de la conception de la maintenance.
La containerisation n’a pas éliminé les redémarrages : vos conteneurs dépendent toujours du noyau hôte. Vous pouvez redéployer des pods toute la journée et continuer d’exécuter un noyau ancien.
ZFS sur Linux (OpenZFS) a beaucoup mûri la dernière décennie, mais l’accouplement module-noyau fait que les changements de noyau méritent toujours une attention particulière sur les têtes de stockage.

Feuille de route de diagnostic rapide : trouver le vrai blocage en quelques minutes

Quand la page s’affiche : « Le serveur indique redémarrage requis ; peut-on différer ? » vous ne commencez pas par un débat philosophique.
Vous commencez par un triage. Le but est d’identifier rapidement le goulot d’étranglement et la catégorie de risque.

Première étape : confirmer ce qui a déclenché le flag reboot-required

Est-ce le noyau, le microcode, ou seulement des redémarrages de services ?
Le nœud fait-il partie d’une paire HA ou est-il un singleton ?
Existe-t-il un exploit connu en circulation pour le composant mis à jour ?

Deuxième étape : déterminer si vous pouvez redémarrer des services au lieu de redémarrer la machine

Redémarrez les démons impactés dans l’ordre des dépendances.
Validez les checks de santé, la latence et les budgets d’erreur.
Confirmez qu’aucune charge stateful ne sera perturbée (bases de données, contrôleurs de stockage).

Troisième étape : planifier la route de redémarrage avec le plus petit rayon d’action

Videz/évacuez le trafic, basculez, cordonnez les nœuds, ou déplacez les VIP.
Confirmez que vous avez un accès console (out-of-band).
Définissez le rollback : noyau précédent dans GRUB, snapshot, ou image connue bonne.

Vous n’essayez pas d’être ingénieux. Vous essayez d’être prévisible.

Tâches pratiques : commandes, sorties et la décision que vous prenez

Ci‑dessous des tâches éprouvées sur le terrain pour Ubuntu 24.04. Chacune inclut (1) une commande, (2) ce que signifie la sortie, et (3) la décision à prendre.
Exécutez-les en séquence ; elles sont conçues pour réduire progressivement le problème.

Task 1: Check whether Ubuntu thinks a reboot is required

cr0x@server:~$ ls -l /run/reboot-required /run/reboot-required.pkgs
-rw-r--r-- 1 root root  0 Dec 30 10:12 /run/reboot-required
-rw-r--r-- 1 root root 73 Dec 30 10:12 /run/reboot-required.pkgs

Signification : La présence de /run/reboot-required est un indice installé par un paquet indiquant que quelque chose nécessite un redémarrage.
Le fichier .pkgs liste les paquets qui l’ont déclenché.

Décision : Ne redémarrez pas encore. Lisez d’abord la liste des paquets pour classifier le risque.

Task 2: Read which packages requested the reboot

cr0x@server:~$ cat /run/reboot-required.pkgs
linux-image-6.8.0-55-generic
linux-modules-6.8.0-55-generic
intel-microcode

Signification : C’est un véritable ensemble déclencheur de redémarrage : nouveau noyau + modules + microcode.
Redémarrer des services ne chargera pas le nouveau noyau. Le microcode se charge généralement au démarrage aussi.

Décision : Considérez cela comme « redémarrage requis pour correctif complet ». Si vous devez différer, documentez la fenêtre d’exposition et envisagez le live patching.

Task 3: Confirm the running kernel vs installed kernels

cr0x@server:~$ uname -r
6.8.0-49-generic

cr0x@server:~$ dpkg -l 'linux-image-*generic' | awk '/^ii/{print $2,$3}'
linux-image-6.8.0-49-generic 6.8.0-49.49
linux-image-6.8.0-55-generic 6.8.0-55.57

Signification : Vous exécutez 6.8.0-49 mais 6.8.0-55 est installé.

Décision : Un redémarrage (ou kexec, rarement) est requis pour réellement exécuter le noyau patché. Planifiez-le ; ne l’ignorez pas.

Task 4: Check uptime and reboot history (detect “forever defer” patterns)

cr0x@server:~$ uptime -p
up 97 days, 4 hours, 18 minutes

cr0x@server:~$ last reboot | head -3
reboot   system boot  6.8.0-49-gene Tue Sep 24 06:11   still running
reboot   system boot  6.8.0-41-gene Mon Aug 12 02:03 - 06:10 (42+04:07)
reboot   system boot  6.8.0-31-gene Sun Jun 30 01:58 - 02:02  (00:04)

Signification : Les longues durées d’activité ne sont pas automatiquement bonnes. Elles signifient souvent que vous transportez du risque latent et de la dérive de configuration.

Décision : Si vous voyez des mois d’uptime sur des systèmes soumis à beaucoup de patches, planifiez des redémarrages contrôlés et rendez-les routiniers, pas des crises.

Task 5: Identify services that should be restarted because of upgraded libraries (needrestart)

cr0x@server:~$ sudo needrestart -r l
NEEDRESTART-VER: 3.6
Services to be restarted:
  ssh.service
  systemd-journald.service
  cron.service
No containers need to be restarted.

Signification : Ces démons utilisent des bibliothèques ou binaires obsolètes et devraient être redémarrés pour prendre les mises à jour.
Cela vous indique aussi si des conteneurs sont concernés.

Décision : Si un redémarrage est impossible aujourd’hui, redémarrez ces services pendant une période calme et revérifiez. Cela réduit l’exposition sans vous mentir sur le noyau.

Task 6: Verify whether a critical process is still mapped to deleted libraries

cr0x@server:~$ sudo lsof | awk '/DEL/{print $1,$2,$9}' | head
systemd 1 /usr/lib/x86_64-linux-gnu/libssl.so.3 (deleted)
nginx 2154 /usr/lib/x86_64-linux-gnu/libcrypto.so.3 (deleted)
php-fpm8 3011 /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 (deleted)

Signification : Des processus utilisent encore d’anciennes versions de bibliothèques qui ont été remplacées sur le disque.
C’est une situation classique de « patch installé mais code ancien encore en cours d’exécution ».

Décision : Redémarrez les services affectés (ou l’hôte) en fonction de la criticité et de la redondance. Si c’est systemd ou le cœur de la couche système, privilégiez une fenêtre de redémarrage.

Task 7: Confirm microcode package status (why the reboot flag won’t clear)

cr0x@server:~$ dpkg -l intel-microcode amd64-microcode | awk '/^ii/{print $2,$3}'
intel-microcode 3.20241112.0ubuntu0.24.04.1

Signification : Le microcode est installé ; il s’appliquera généralement au démarrage. Le flag de redémarrage est attendu.

Décision : Si vous opérez dans des environnements régulés, les mises à jour microcode peuvent être considérées comme pertinentes pour la sécurité ; planifiez le redémarrage comme un événement de conformité.

Task 8: Inspect what unattended-upgrades did (change control without the drama)

cr0x@server:~$ sudo tail -n 30 /var/log/unattended-upgrades/unattended-upgrades.log
2025-12-30 09:58:12,219 INFO Installing linux-image-6.8.0-55-generic:amd64 (6.8.0-55.57) ...
2025-12-30 10:02:41,887 INFO Installing linux-modules-6.8.0-55-generic:amd64 (6.8.0-55.57) ...
2025-12-30 10:06:09,014 INFO Installing intel-microcode:amd64 (3.20241112.0ubuntu0.24.04.1) ...
2025-12-30 10:06:10,120 INFO Packages that were upgraded: linux-image-6.8.0-55-generic linux-modules-6.8.0-55-generic intel-microcode

Signification : Le système a fait ce que vous lui avez demandé : il a installé des mises à jour. Il n’a pas redémarré parce que c’est un choix de politique.

Décision : Utilisez ce journal comme votre enregistrement de changement. Ne devinez pas ce qui a changé quand vous rédigez le ticket de maintenance.

Task 9: Check for pending initramfs or bootloader changes

cr0x@server:~$ sudo grep -E "update-initramfs|update-grub" -n /var/log/dpkg.log | tail -n 5
184392:2025-12-30 10:03:12 status half-configured linux-image-6.8.0-55-generic:amd64 6.8.0-55.57
184411:2025-12-30 10:03:28 status installed linux-image-6.8.0-55-generic:amd64 6.8.0-55.57
184412:2025-12-30 10:03:28 trigproc initramfs-tools:amd64 0.142ubuntu25.3 <none>
184413:2025-12-30 10:03:28 status half-configured initramfs-tools:amd64 0.142ubuntu25.3
184420:2025-12-30 10:03:42 status installed initramfs-tools:amd64 0.142ubuntu25.3

Signification : Les triggers initramfs ont été exécutés ; vos artefacts de démarrage ont été mis à jour.
Si cet hôte boote depuis un stockage inhabituel ou a des hooks initramfs personnalisés, c’est ici que viennent les surprises.

Décision : Pour des piles de démarrage complexes (LUKS, ZFS root, multipath), testez la procédure de redémarrage sur un nœud frère d’abord.

Task 10: Check ZFS/OpenZFS status if this is a storage host

cr0x@server:~$ sudo zpool status
  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Upgrade the pool to enable all features.
  scan: scrub repaired 0B in 01:12:33 with 0 errors on Sun Dec 29 03:10:01 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          sda3      ONLINE       0     0     0
          sdb3      ONLINE       0     0     0

errors: No known data errors

Signification : Le pool est sain. Le message « features not enabled » concerne les flags de fonctionnalités du pool, pas la santé immédiate.

Décision : Si vous devez redémarrer une tête de stockage, ne le faites que lorsque le pool est propre et qu’aucun resilver/scrub n’est en cours de manière risquée.

Task 11: Confirm whether ZFS modules match the running kernel

cr0x@server:~$ dkms status | grep -E '^zfs'
zfs/2.2.2, 6.8.0-49-generic, x86_64: installed
zfs/2.2.2, 6.8.0-55-generic, x86_64: installed

Signification : DKMS a construit ZFS pour les deux noyaux, ce qui est ce que vous voulez avant de redémarrer.
Si l’entrée pour le nouveau noyau est manquante ou en « build error », votre redémarrage devient un incident de stockage.

Décision : Si DKMS n’a pas construit pour le nouveau noyau, corrigez cela avant le redémarrage. Sinon, vous risquez de booter dans un noyau sans votre module de stockage.

Task 12: Validate systemd failed units before you touch anything

cr0x@server:~$ systemctl --failed
  UNIT                    LOAD   ACTIVE SUB    DESCRIPTION
● multipathd.service       loaded failed failed Device-Mapper Multipath Device Controller

1 loaded units listed.

Signification : Vous avez déjà une unité critique en échec. Redémarrer pourrait « la corriger » ou pourrait bloquer votre chemin de démarrage, selon de quoi il s’agit.

Décision : Résolvez les unités échouées qui affectent le stockage/le réseau avant de planifier un redémarrage. Si vous dépendez de multipath, considérez cela comme un panneau stop.

Task 13: Check whether critical services are restartable without downtime

cr0x@server:~$ systemctl show nginx --property=CanReload,CanRestart,ActiveState,SubState
CanReload=yes
CanRestart=yes
ActiveState=active
SubState=running

Signification : systemd estime que nginx peut être rechargé et redémarré. Le reload est généralement moins risqué que le restart, mais seulement si votre configuration est valide.

Décision : Préférez le reload quand c’est possible, validez la config d’abord, et ne redémarrez que si vous devez prendre en compte un changement binaire/bibliothèque.

Task 14: Validate configuration before restarting (avoid self-inflicted outage)

cr0x@server:~$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Signification : La configuration est syntaxiquement valide ; reload/restart a moins de chances d’échouer.

Décision : Si la validation de la configuration échoue, corrigez cela d’abord. Un redémarrage de maintenance qui devient une panne est la manière dont vous perdez vos week-ends.

Task 15: Check journald and kernel logs for boot-related warnings before scheduling reboot

cr0x@server:~$ sudo journalctl -p warning -b | tail -n 10
Dec 30 07:11:02 server kernel: nvme nvme0: missing or invalid SUBNQN field.
Dec 30 07:11:03 server systemd[1]: Failed to start Device-Mapper Multipath Device Controller.
Dec 30 07:11:05 server kernel: xhci_hcd 0000:00:14.0: BIOS handoff failed (BIOS bug?)

Signification : Vous avez des avertissements qui peuvent compter pendant le redémarrage (particularités NVMe, multipath).
Ce sont des indices que le redémarrage n’est pas « juste un redémarrage ».

Décision : Si des avertissements de boot/stockage existent, faites un redémarrage contrôlé avec accès console et un plan de rollback. Ne « YOLO reboot » pas à distance.

Task 16: Confirm what will boot by default (GRUB) and ensure fallback is available

cr0x@server:~$ grep -E '^GRUB_DEFAULT=|^GRUB_TIMEOUT=' /etc/default/grub
GRUB_DEFAULT=0
GRUB_TIMEOUT=5

Signification : L’entrée par défaut boote le premier item du menu ; le timeout est court. C’est correct jusqu’au moment où vous devez une sélection manuelle.

Décision : Si vous avez déjà eu des régressions kernel, envisagez un timeout plus long sur les systèmes critiques, ou assurez-vous que la console out-of-band peut interagir avec GRUB.

Report intelligent : comment rester sûr quand vous ne pouvez pas redémarrer

Parfois, vous ne pouvez vraiment pas redémarrer : fin de trimestre, gel de migration live, démonstration client, migration de base de données, ou tout simplement pas de redondance.
« Pas de redémarrage » ne doit pas signifier « ignorer ». Cela doit signifier : réduire l’exposition, préparer le redémarrage, et le planifier.

Sachez ce que vous différez

Si la liste des paquets dans reboot-required contient un noyau, vous différez des correctifs de sécurité du noyau. C’est une exposition réelle.
Si elle ne contient que des bibliothèques userland, vous pouvez souvent réduire le risque en redémarrant des services spécifiques.

Le live patching peut aider pour certaines CVE du noyau. Mais ce n’est pas un laissez-passer gratuit. C’est une ceinture de sécurité, pas une cage de protection.

Première blague (et seulement parce que nous l’avons tous faite) : un report « temporaire » de redémarrage ressemble à une règle de firewall temporaire—finalement elle devient partie de l’architecture.

Stratégie de redémarrage des services (la version sobre)

Un plan de redémarrage ciblé est légitime quand :

Vous avez de la redondance ou du load balancing, donc redémarrer un nœud n’interrompt pas le trafic.
Les composants mis à jour sont des bibliothèques userland ou des démons, pas le noyau.
Vous pouvez valider la santé après chaque redémarrage avec des checks réels (pas des impressions).

Un plan de redémarrage ciblé est dangereux quand :

L’hôte est un point de défaillance unique (SPOF).
La pile stockage et réseau est impliquée (multipath, iSCSI, modules ZFS).
Vous n’avez pas de backout testé ou vous ne pouvez pas atteindre la console.

Cadre de risque qui fonctionne en environnements matures

Ne dites pas aux parties prenantes « nous ne pouvons pas redémarrer ». Dites-leur :

Ce qui est patché sur le disque vs ce qui tourne en mémoire (noyau et processus impactés).
Quel est le risque connu (classe de composant, exploitabilité, exposition).
Quelle mitigation vous appliquez maintenant (redémarrages de services, règles WAF, restrictions d’accès).
Quand le redémarrage aura lieu (fenêtre, dépendances, plan de repli).

C’est de l’honnêteté opérationnelle. Et c’est ainsi que vous évitez le postmortem « on croyait que c’était bon ».

Concevoir des fenêtres de maintenance qui font peu (ou pas) de mal

La vraie solution au « je ne peux pas redémarrer » est d’arrêter de construire des systèmes qui ne peuvent pas redémarrer.
Pas parce que les redémarrages sont amusants—ils ne le sont pas—mais parce que la sécurité et la fiabilité exigent que vous puissiez cycler la machine.

Rendez les redémarrages banals grâce à la redondance

Si vous faites tourner un nœud de production unique parce que « c’est moins cher », vous payez déjà.
Vous payez en risque, en patchs retardés, en héros fragiles, et en anxiété d’astreinte qui raccourcit les carrières.

Couche web : au moins deux nœuds derrière un load balancer, avec des health checks qui échouent réellement quand l’application est cassée.
Bases de données : réplication avec basculement testé, ou services managés si vous ne pouvez pas l’exploiter.
Stockage : contrôleurs doubles ou stockage en cluster ; si ce n’est pas possible, soyez honnête : les redémarrages des têtes de stockage sont des pannes.
Identité/plan de contrôle : traitez-les comme de l’infrastructure critique ; la redondance n’est pas optionnelle.

Concevez le workflow de redémarrage, pas seulement la fenêtre

Les fenêtres de maintenance échouent quand elles sont traitées comme un créneau horaire plutôt que comme une procédure.
Une bonne procédure de redémarrage inclut :

Pré-checks (santé des pools, latence de réplication, espace disque, unités échouées).
Vidage du trafic (cordon, mouvement VIP, désactivation LB, ou basculement manuel).
Exécution du redémarrage avec accès console.
Post-checks (santé des services, vérification des versions, logs, contrôle de régression de performance).
Rollback documenté (noyau précédent, snapshot, ou plan de restauration).

Mises à jour du noyau : traitez-les comme routinières, pas comme des urgences

Le redémarrage kernel le plus difficile est le premier après des mois de report.
Vous n’appliquez pas un seul changement ; vous sautez par-dessus une pile de changements, en espérant qu’aucun ne touche vos particularités matérielles.

Le meilleur schéma est la cadence : redémarrez chaque mois (ou plus souvent si votre modèle de menace l’exige) et gardez-la régulière.
La cadence la rend banale. Et l’ordinaire est l’objectif.

Deuxième blague (dernière, promis) : la seule chose plus coûteuse qu’un redémarrage planifié est un redémarrage non planifié avec un public.

Une citation fiabilité à intérioriser

L’idée paraphrasée de Gene Kim issue de la culture DevOps s’applique ici : faites des petits changements fréquents pour que les échecs soient plus petits et plus faciles à récupérer.
Ce principe ne concerne pas que les déploiements ; il concerne aussi les redémarrages du noyau.

Trois mini-histoires du monde de l’entreprise (anonymisées)

Mini-histoire 1 : Un incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne exploitait des flottes Ubuntu avec auto-security updates. Ils étaient récemment passés à une nouvelle pile de monitoring
qui signalait /run/reboot-required comme une « alerte critique ». Excellente idée. Mauvaise implémentation.

Un ingénieur a vu un groupe d’alertes « redémarrage requis » et a supposé qu’il s’agissait majoritairement de paquets userland.
Il a décidé « d’effacer l’alerte » en redémarrant les services listés par needrestart, ce qui semblait sûr.
Les services ont redémarré proprement, l’alerte est restée, et il a haussé les épaules.

La mauvaise hypothèse était subtile : il croyait que l’alerte signifiait « les services sont obsolètes » et que redémarrer quelques démons résoudrait le problème.
Mais la liste de paquets incluait une mise à jour du noyau et du microcode. Le noyau en cours d’exécution avait des mois de retard.
Leur modèle de menace incluait des workloads exposés à Internet. Cet écart comptait.

Deux semaines plus tard, un exercice de réponse à incident a révélé que les hôtes de production n’exécutaient pas le noyau patché malgré leur statut « entièrement mis à jour ».
Il n’y a pas eu de brèche, mais c’est devenu un problème de conformité : « installé » ne signifiait pas « effectif ».
La correction n’était pas technique—c’était de processus. Ils ont mis à jour l’alerte pour inclure la liste de paquets et le delta de version du noyau, et ajouté un SLA pour l’achèvement du redémarrage.

Mini-histoire 2 : Une optimisation qui s’est retournée contre eux

Une entreprise financière détestait les redémarrages car leurs jobs batch duraient longtemps. Quelqu’un a proposé un plan « malin » :
redémarrer agressivement uniquement les services affectés après le patch, et ne redémarrer qu’une fois par trimestre. Ils l’ont automatisé.

Pendant un moment, cela a paru bien. Moins d’indisponibilité, moins de tickets de maintenance, parties prenantes satisfaites. Puis le retour de bâton.
Ils ont patché OpenSSL et redémarré « tous les services » avec un script qui itérait des unités systemd.
Le script ne comprenait pas les dépendances de service et a redémarré la couche reverse-proxy avant la couche applicative.

Résultat : des interruptions partielles brèves mais répétées—pics HTTP 502 qui n’ont pas déclenché une panne complète parce que le load balancer voyait encore quelques nœuds sains.
Les clients ont constaté des erreurs intermittentes. Le support a reçu des tickets. Les SRE ont eu des graphs en peigne.

Le postmortem a été gênant parce que rien n’« avait crashé ». L’optimisation a créé un nouveau mode de défaillance : des redémarrages incohérents à travers la stack.
Ils ont remplacé le script par un workflow contrôlé de drain-et-redémarrage par rôle (proxy/app/worker), et ont raccourci la cadence des redémarrages kernel.
L’idée du « redémarrage trimestriel » est morte doucement, comme il se doit.

Mini-histoire 3 : Une pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise traitant des charges lourdes de stockage (ZFS sur Ubuntu) avait une règle stricte : pas de redémarrage sans trois feux verts :
zpool status propre, modules DKMS construits pour le noyau cible, et accès console testé.
Cela semblait lent. Ça l’était.

Un mois, unattended-upgrades a installé un nouveau noyau pendant la nuit. Une fenêtre de redémarrage planifiée était prévue pour la soirée suivante.
Les pré-checks ont montré que DKMS avait échoué à construire ZFS pour le nouveau noyau à cause d’un paquet d’en-têtes manquant (un problème de miroir de dépôt).

S’ils avaient redémarré selon le planning sans regarder, ils auraient démarré dans un noyau sans module ZFS.
Sur une tête de stockage, ce n’est pas « dégradé ». C’est « votre pool ne s’importe pas et maintenant tout le monde apprend de nouveaux jurons ».

À la place, ils ont corrigé le problème de paquet, reconstruit DKMS, vérifié la présence des modules, puis redémarré.
Personne en dehors de l’équipe infrastructure n’a rien remarqué. C’est le but d’une pratique ennuyeuse et correcte : rien ne se passe, et vous rentrez chez vous.

Erreurs courantes : symptômes → cause racine → correction

Ce sont des schémas qui apparaissent dans de vraies flottes. Ce ne sont pas des théories.

1) Symptom: “Reboot required” won’t go away after restarting services

Cause racine : Le flag de redémarrage a été déclenché par une mise à jour du noyau ou du microcode ; redémarrer des services ne peut pas charger un nouveau noyau.

Correction : Confirmez avec cat /run/reboot-required.pkgs et uname -r. Planifiez un redémarrage, ou appliquez du live patching pendant que vous le planifiez.

2) Symptom: Reboot clears the flag, but services behave oddly afterward

Cause racine : Dérive de configuration et redémarrages non testés. Le système a tourné si longtemps que le redémarrage active d’anciennes hypothèses de boot (noms réseau, montages, dépendances).

Correction : Rendez les redémarrages fréquents et routiniers. Ajoutez des vérifications post-redémarrage et corrigez l’ordre des unités de boot, les montages et la config réseau.

3) Symptom: After reboot, storage is missing or pool won’t import

Cause racine : Mismatch module-noyau (DKMS ZFS non construit), ou services multipath/iSCSI qui échouent tôt au démarrage.

Correction : Pré-vérifiez le statut DKMS pour le noyau cible ; vérifiez que systemctl --failed est propre ; assurez-vous que l’initramfs contient les modules nécessaires si applicable.

4) Symptom: Restarting services causes brief 502s or timeouts

Cause racine : Ordre de redémarrage et ignorance des dépendances ; health checks du load balancer trop permissifs ; capacité insuffisante.

Correction : Vide du nœud d’abord ; redémarrez selon l’ordre des rôles ; resserrez les health checks pour refléter la réelle readiness ; maintenez une capacité N+1.

5) Symptom: Security team says “patched,” SRE says “still vulnerable”

Cause racine : Confusion entre « paquet installé » et « code en cours d’exécution ». Les processus longue durée et les noyaux anciens persistent.

Correction : Rapportez à la fois les versions installées et celles en cours d’exécution. Utilisez needrestart et les deltas de version du noyau comme preuves de conformité.

6) Symptom: Reboot causes prolonged downtime because the host never returns

Cause racine : Pas d’accès console out-of-band, configuration du bootloader cassée, ou accès uniquement distant avec une stack réseau qui dépend du succès du reboot.

Correction : Vérifiez toujours l’accès console avant la maintenance. Assurez-vous qu’un noyau de repli existe. Ne planifiez pas de redémarrages risqués sans les mains sur le volant.

Checklists / plan pas-à-pas

Checklist A: When you see “reboot required” and you can’t reboot today

Lisez /run/reboot-required.pkgs et classifiez : noyau/microcode vs userland.
Enregistrez le noyau en cours d’exécution (uname -r) et le noyau cible installé (liste dpkg).
Exécutez needrestart -r l ; redémarrez les services à faible risque si approprié.
Vérifiez les mappings de bibliothèques supprimées (lsof | ... DEL) ; redémarrez les démons affectés dans un ordre contrôlé.
Appliquez des mitigations si vous différez les correctifs du noyau : restreignez l’exposition réseau, limitez les taux, règles WAF, réduisez les chemins d’administration.
Créez un ticket de redémarrage avec : raison, liste de paquets, risque, fenêtre proposée, rollback et étapes de validation.

Checklist B: Pre-reboot safety checks (15 minutes that save hours)

Confirmez que l’accès console fonctionne (IPMI/iDRAC/console virt).
systemctl --failed doit être vide pour les unités critiques stockage/réseau.
Hôtes de stockage : zpool status doit être propre ; pas de resilver/scrub en phase risquée.
Modules DKMS construits pour le nouveau noyau (dkms status inclut le noyau cible).
Sanity espace disque : assurez-vous que /boot n’est pas plein ; assurez-vous qu’aucune opération de paquet n’est en half-configured.
Confirmez le chemin de rollback : le noyau précédent est toujours installé ; GRUB peut le sélectionner.

Checklist C: Reboot execution with minimal blast radius

Videz le trafic ou basculez (désactivation LB, mouvement VIP, cordon du nœud, etc.).
Arrêtez ou mettez en quiescence les workloads stateful si nécessaire (bases de données, exports de stockage).
Redémarrez en utilisant systemd et surveillez la console.
Vérifiez la version du noyau après le boot, puis vérifiez les services critiques, puis restaurez le trafic.

Checklist D: Post-reboot validation (don’t stop at “it pings”)

Confirmez que le noyau en cours d’exécution est celui attendu.
Confirmez que les services critiques sont actifs et en bonne santé.
Vérifiez les logs pour de nouveaux avertissements/erreurs depuis le démarrage.
Vérifiez les montages/pools de stockage et les routes réseau.
Exécutez une transaction synthétique (login, appel API, lecture/écriture) via le chemin réel.
Fermez la boucle : effacez l’alerte, documentez la complétion, et définissez la prochaine cadence.

FAQ

1) Is “reboot required” always about the kernel?

Non. C’est souvent le noyau ou le microcode, mais cela peut aussi être déclenché par d’autres paquets.
Vérifiez /run/reboot-required.pkgs pour voir ce qui l’a réellement demandé.

2) If I restart all services, am I secure without rebooting?

Vous pouvez réduire le risque pour des mises à jour userland, mais vous ne prendrez pas les correctifs du noyau sans redémarrage (ou sans mécanisme de live patch pour des CVE spécifiques).
Considérez les « redémarrages de services » comme une mitigation, pas comme une résolution.

3) What’s the safest thing to do when I cannot reboot a single critical server?

Soyez honnête : c’est un SPOF, donc tout changement significatif est risqué. Minimisez l’exposition (restrictions réseau, durcissement d’accès),
planifiez une fenêtre de maintenance, et priorisez la construction de la redondance pour que vous puissiez redémarrer sans drame la prochaine fois.

4) Can I just delete /run/reboot-required to clear the warning?

Vous pouvez, et cela effacera l’alerte basée sur le fichier. Cela ne changera pas la réalité.
C’est comme retirer la pile de l’alarme incendie parce que la cuisine est bruyante.

5) How do I know which processes are still using old libraries?

Utilisez needrestart pour une liste organisée et lsof pour repérer les mappings de bibliothèques supprimées.
La décision est alors : redémarrer des services individuels maintenant, ou planifier un redémarrage si l’étendue est trop large.

6) What’s different about Ubuntu 24.04 in this context?

Les fondamentaux sont les mêmes, mais Ubuntu 24.04 tend à être déployé avec des noyaux modernes, le comportement systemd,
des conteneurs, et des modules DKMS (comme ZFS) qui rendent les changements de noyau plus significatifs opérationnellement.

7) How often should we reboot production servers?

Assez souvent pour que ce soit routinier. Mensuellement est une base commune pour de nombreux environnements ; les environnements à plus haut risque vont plus vite.
L’essentiel est la régularité : une cadence prévisible vaut mieux que des redémarrages sporadiques et paniqués.

8) We run Kubernetes. Is rebooting a node just “cordon and drain”?

Pour l’essentiel, oui, mais les détails comptent : PodDisruptionBudgets, statefulsets, stockage local, daemonsets et agents réseau peuvent compliquer les drains.
Le concept tient : évacuer les workloads, redémarrer, valider, annuler le cordon.

9) What if the new kernel causes a regression?

C’est pour cela que vous conservez au moins un noyau connu bon installé et que vous assurez pouvoir le sélectionner via la console.
Testez d’abord sur un nœud canari. Les régressions kernel sont rares, mais « rare » n’est pas « jamais ».

10) Do storage servers need special handling for reboots?

Oui. Tout ce qui touche ZFS, multipath, iSCSI ou hooks initramfs personnalisés mérite des pré-checks (santé du pool, builds de modules, unités échouées)
et un redémarrage soigné surveillé depuis la console.

Conclusion : étapes suivantes qui réduisent vraiment le risque

« Redémarrage requis » n’est pas Ubuntu qui vous embête. C’est Ubuntu qui vous dit la vérité : certains correctifs ne prennent effet que lorsque le système en cours change.
Votre travail est de décider quand et comment, pas de déterminer si la réalité s’applique à vous.

Faites ceci ensuite :

Sur chaque hôte signalé, enregistrez : /run/reboot-required.pkgs, uname -r, et needrestart -r l.
Si c’est noyau/microcode : planifiez un redémarrage avec un plan de rollback et accès console. Si c’est userland : redémarrez les services impactés en sécurité.
Construisez une cadence : redémarrages mensuels, canari d’abord, puis déploiement sur la flotte. Rendez-le banal.
Éliminez les systèmes « on ne peut pas redémarrer » par conception : redondance, basculement, et procédures qui transforment les redémarrages en opérations routinières.

Vous ne gagnez pas en fiabilité en ne redémarrant jamais. Vous gagnez en étant capable de redémarrer quand vous en avez besoin — et en le prouvant régulièrement.