Un serveur peut rester des semaines avec des mises à jour de sécurité installées mais non appliquées, en attendant un redémarrage que personne n'a planifié. La solution consiste à surveiller l'état « redémarrage en attente » et « mises à jour en attente » lui-même, et non la panne qu'il finit par provoquer. Sur Debian et Ubuntu, cet état est déjà écrit sur le disque : il suffit que quelque chose le surveille.
C'est une défaillance plus discrète qu'un service qui plante. Les mises à jour de sécurité automatiques téléchargent et installent les paquets, mais le noyau, la libc ou un démon de longue durée continuent d'utiliser l'ancien code en mémoire jusqu'à ce que quelque chose les redémarre. Le correctif est là, sur le disque, inutilisé, et rien ne semble anormal sur le serveur jusqu'à ce que la vulnérabilité corrigée soit exploitée, ou qu'un redémarrage finisse par se produire au pire moment, parce que personne n'a choisi quand.
Comment Linux sait qu'un redémarrage est en attente
Il n'existe aucune norme POSIX pour dire « cette machine doit redémarrer » : tout dépend de la distribution. Sur Debian et Ubuntu, le paquet update-notifier-common s'accroche à APT et écrit un fichier indicateur dès qu'un paquet nécessitant un redémarrage (le noyau, une bibliothèque essentielle, systemd lui-même) a fini de s'installer :
$ cat /var/run/reboot-required
*** System restart required ***
$ cat /var/run/reboot-required.pkgs
linux-image-6.8.0-45-generic
libssl3
Le second fichier liste précisément les paquets qui ont déclenché l'indicateur, ce qui est utile pour décider si un redémarrage peut attendre le week-end ou doit avoir lieu tout de suite. Les systèmes de la famille RHEL utilisent un autre mécanisme (dnf needs-restarting -r), et needrestart va plus loin sur les deux familles en vérifiant quels processus en cours d'exécution référencent encore des fichiers supprimés. Mais le fichier indicateur de Debian/Ubuntu reste le signal le plus simple et le plus répandu, c'est pourquoi la plupart des configurations de supervision le vérifient en premier.
Pourquoi des mises à jour de sécurité restent non installées
La plupart des serveurs Debian et Ubuntu exécutent unattended-upgrades, qui installe automatiquement les correctifs de sécurité selon un minuteur, configuré dans /etc/apt/apt.conf.d/50unattended-upgrades et /etc/apt/apt.conf.d/20auto-upgrades. Quand tout fonctionne, vous n'y pensez jamais. Quand cela s'arrête (une dépendance cassée, un paquet bloqué, une tâche cron qui a échoué en silence), les mises à jour s'accumulent :
$ apt list --upgradable 2>/dev/null | grep -i security
openssl/jammy-security 3.0.2-0ubuntu1.15 amd64 [upgradable from: 3.0.2-0ubuntu1.14]
Quelques paquets à mettre à jour pendant un jour ou deux, c'est normal : les miroirs se synchronisent, les minuteurs sont décalés. Des mises à jour de sécurité qui restent non installées plus d'environ une journée signifient presque toujours que l'automatisation censée les installer s'est arrêtée sans bruit, et non qu'aucun correctif important n'a été publié. C'est un problème différent d'un redémarrage en attente, et il mérite une alerte distincte : un serveur peut n'avoir aucun redémarrage en attente et rester malgré tout exposé à des vulnérabilités non corrigées.
Configurer ces alertes sans écrire de script
Vous pouvez assembler tout cela vous-même avec une tâche cron, un textfile collector Prometheus ou un plugin Nagios qui teste la présence de /var/run/reboot-required et traduit le résultat en état de vérification. Cela fonctionne, mais c'est un script de plus à maintenir par serveur, et il faut encore un endroit où envoyer l'alerte et un moyen d'éviter qu'elle vous réveille toutes les cinq minutes.
InfraNest propose ces deux vérifications sous forme d'alertes intégrées dans Monitoring → Alert defaults, pour tout serveur sur lequel l'agent est installé :
| Alerte | Mesurée en | Par défaut | Se déclenche quand |
|---|---|---|---|
| Un redémarrage est en attente | Jours | Une fois, puis à nouveau après 7 jours | Le serveur signale qu'il doit redémarrer pour terminer l'installation des mises à jour |
| Des mises à jour de sécurité sont en attente | Heures | Plus de 0, pendant 24 heures | Des mises à jour sont restées non installées pendant une journée |
Les deux lisent les mêmes signaux au niveau de la distribution que ceux décrits plus haut (l'indicateur reboot-required et la liste des paquets de sécurité à mettre à jour), il n'y a donc rien de plus à configurer sur le serveur lui-même. Activez l'un ou l'autre interrupteur une seule fois et il s'applique à tous les serveurs supervisés de l'organisation ; chaque serveur peut ensuite recevoir ses propres seuils sans toucher aux autres, via son onglet Alerts & rules.
NoteCes deux alertes sont remontées uniquement par les serveurs Debian et Ubuntu, puisque c'est là que se trouvent les fichiers indicateurs sous-jacents. Sur les autres distributions, les alertes restent désactivées plutôt que de se déclencher pour rien.
Pourquoi l'alerte de redémarrage ne vous harcèle pas
Un serveur qui attend un redémarrage attend souvent volontairement : personne ne veut qu'une machine de production redémarre en plein déploiement simplement parce qu'une mise à jour du noyau est arrivée il y a une heure. C'est pourquoi l'alerte de redémarrage en attente vous prévient une fois lorsque l'indicateur apparaît, puis une nouvelle fois s'il est toujours présent après le nombre de jours que vous avez choisi, et reste silencieuse entre les deux. Un serveur volontairement mis de côté en attendant une fenêtre de maintenance calme ne vous interrompt pas sans cesse ; un serveur oublié depuis une semaine reçoit un second rappel.
L'alerte de mises à jour de sécurité se comporte différemment, car rien ne justifie d'attendre. Elle se déclenche lorsque des mises à jour sont restées non installées pendant 24 heures et se résout d'elle-même dès que le serveur a rattrapé son retard : il n'y a rien à « planifier » dans l'application d'un correctif, donc aucun second délai de grâce n'est prévu.
TipChoisissez une fenêtre en minutes ou en heures réaliste plutôt qu'agressive. Un seuil qui se déclenche dès qu'une mise à jour apparaît vous apprend simplement à ignorer le canal où il arrive. Consultez nos notes sur les alertes de monitoring pour éviter la fatigue d'alertes de manière générale, pas seulement pour cette vérification.
Boucler la boucle avec l'automatisation
Une alerte qui arrive dans Slack à 2 h du matin et attend qu'un humain intervienne ne fait que la moitié du travail. Comme il s'agit d'alertes InfraNest ordinaires, vous pouvez les confier à une automatisation au lieu d'une notification, ou en plus : ouvrir un ticket lorsqu'un serveur attend un redémarrage depuis plus de deux semaines, publier chaque lundi dans un canal un récapitulatif des serveurs en attente, ou exiger une approbation puis redémarrer automatiquement le serveur dès que quelqu'un a validé. L'alerte vous informe ; c'est l'automatisation qui règle réellement le problème sans que vous ayez à redémarrer à la main.
Si vous vous demandez encore ce qu'il vaut la peine de surveiller sur un serveur avant qu'il ne provoque une panne, la page métriques et alertes serveur aborde le CPU, la mémoire, le disque et la charge de la même manière. Elle mérite d'être lue en parallèle de notre checklist plus générale pour sécuriser votre infrastructure si la fréquence des correctifs fait partie d'un audit plus large.
Activez les deux alertes dans Monitoring → Alert defaults : les serveurs qui ont besoin d'un redémarrage ou d'un coup de pouce pour terminer leurs correctifs vous le signaleront, au lieu d'attendre que quelque chose casse.
Questions fréquentes
#Un redémarrage en attente signifie-t-il qu'une mise à jour de sécurité est en attente ?
Pas forcément. Un redémarrage peut être en attente à cause d'une mise à jour courante du noyau ou d'une bibliothèque sans aucun correctif de sécurité, et une mise à jour de sécurité peut rester non installée sans qu'aucun redémarrage soit nécessaire. C'est pour cette raison qu'ils sont suivis et font l'objet d'alertes séparées.
#Que se passe-t-il si un serveur ne redémarre jamais ?
Les programmes déjà en cours d'exécution continuent d'utiliser l'ancienne version de toute bibliothèque ou de tout noyau mis à jour, y compris le correctif qu'une mise à jour de sécurité vient d'installer, jusqu'au redémarrage effectif. Le correctif est donc techniquement installé, mais pas encore actif.
#Pourquoi ces alertes ne fonctionnent-elles pas sur RHEL ou CentOS ?
Elles s'appuient sur des fichiers et des métadonnées de paquets que Debian et Ubuntu maintiennent spécifiquement à cet effet ; les systèmes de la famille RHEL exposent le même type d'informations via d'autres outils, que ces deux alertes ne lisent pas actuellement.
#Vais-je recevoir une alerte tous les jours si un serveur est volontairement laissé sans correctifs ?
Non. L'alerte de redémarrage se déclenche une fois à son apparition, puis une nouvelle fois après le nombre de jours que vous avez choisi, avant de rester silencieuse ; l'alerte de mises à jour de sécurité se résout d'elle-même dès que le serveur a rattrapé son retard, elle ne se répète donc que si le problème sous-jacent persiste.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
