Le Reboot, un mal nécessaire

Un serveur Linux ou autre qui tourne bien, on préfère souvent ne pas y toucher. Pourtant, l’absence de reboot peut devenir un risque silencieux.

Les mises à jour

Un bon système est un système à jour. C’est pourquoi même les développeurs connaissent la comptine : 

sudo apt-get update
sudo apt-get upgrade

Chez les administrateurs, il est possible de voir la même chose avec différents gestionnaires de paquets et plus ou moins d’automatisation. Il en ressort que nous savons en général tous mettre à jour un système. Dans la majorité des cas, ce genre de mise à jour est inofensif pour le système et la plupart des applications sont redémarrées en nouvelle version, ce qui amène à des micro-coupures de quelques secondes tout au plus.

Mais certaines applications ne sont pas redémarrées !

Un redémarrage des applications, pas systématique

Certaines applications ne sont pas redémarrées automatiquement après une mise à jour. C’est souvent le cas lorsque les bibliothèques sont mises à jour, mais pas l’application elle-même. L’application continue d’utiliser l’ancienne version de la bibliothèque qui a été copié en mémoire, jusqu’à son redémarrage. Il est important de savoir quels processus redémarrer.

RedHat Based

Sur RedHat, le plugin needs-restarting est généralement déjà installé (voir la doc):

dnf needs-restarting

Debian Based

Sur Debian il vous faut installer le paquet debian-goodies pour avoir accès à checkrestart (voir la doc)

apt install debian-goodies
checkrestart

Problème des couches basses

Pour démarrer, un système a besoin d’un noyau, qui va s’occuper de fournir une interface entre le matériel et les logiciels. Sur Linux, le noyau (ou kernel) va lancer le processus numéro 1, appelé processus init. En général c’est systemd qui joue le rôle du processus init. C’est lui qui sera en charge de démarrer et d’arrêter les différentes applications, et qui sera appelé par les scripts de post-installation du gestionnaire de paquet pour redémarrer une application mise à jour.

Le noyau et le processus init sont liés, dans le sens où le noyau est une dépendance des applications (les applications sont codées pour utiliser le noyau pour bénéficier des fonctionnalités du matériel), et le noyau panique si son processus init s’arrête (kernel panic). Il n’y a pas d’autre solution que de redémarrer les deux ensembles. Ce qui revient à effectuer un redémarrage complet du système.

Parmi tous les paquets, il en existe d’autres qui nécessitent un redémarrage : les dépendances de ces deux là. Par exemple, la libc est une dépendance nécessaire à systemd. Donc pour mettre à jour la libc, il faudra redémarrer systemd, donc redémarrer tout le système.

Le système n’est pas redémarré par le gestionnaire de paquets à chaque mise à jour. Et chaque mise à jour ne requiert pas un redémarrage. Lorsqu’un redémarrage est nécessaire, il revient à l’administrateur de planifier le redémarrage à un horaire qui convient (souvent en dehors des heures d’affluence).

Illustration des différentes briques qui composent un système Linux, avec une différentiation entre ceux qui nécessite un reboot complet (matériel, noyau, init) et les autres applis qui peuvent être redémarrées à chaud

Comment savoir s’il faut reboot ou pas ?

C’est là tout l’objectif de cet article. La méthode dépend en fonction du système.

RedHat Based

Sur les RedHat Based, c’est assez simple et vient avec dnf:

dnf needs-restarting --reboothint

Qui retourne quelque chose comme:

Core libraries or services have been updated since boot-up:
  * glibc
  * kernel

Debian Based

Sur Debian c’est un peu plus compliqué, il faut vérifier la présence du fichier /var/run/reboot-required:

test -e /var/run/reboot-required && echo "Reboot required" || echo "No need to reboot"

Et s’il y a besoin de redémarrer, la liste des paquets qui nécessitent un redémarrage est présente dans le fichier /var/run/reboot-required.pkgs:

cat /var/run/reboot-required.pkgs

Est-ce qu’il faut vraiment redémarrer le système ?

Nous préconisons systématiquement de le faire. Les mises à jour apportent des correctifs pour les bugs mais aussi pour la sécurité. Et les vulnérabilités sur les couches basses d’un système permettent souvent l’escalade de privilège, car toutes les autres applications en dépendent.

Et avec le recul et l’expérience, nous savons que redémarrer ses serveurs régulièrement permet de:

  • Appliquer tous les correctifs de sécurité
  • Éviter d’accumuler les fuites mémoire
  • Tester la reprise applicative après reboot
  • Vérifier la validité des configurations de démarrage

Un système qui redémarre bien est un système sain. Ne laissez pas un redémarrage devenir un saut dans l’inconnu.

Vous n’avez pas le temps de redémarrer vos serveurs ?

Contactez un expert
Retour en haut