Linux / Commande reboot : préparer et vérifier un redémarrage

reboot demande le redémarrage du système Linux. Sur un système utilisant systemd, la demande normale passe par la procédure d’arrêt des services puis de redémarrage. Préparez les travaux en cours, l’accès de secours et la vérification du retour des services avant de l’exécuter : la fermeture de votre connexion ne prouve pas à elle seule que la machine a redémarré correctement.

Vérifier la machine et préparer l’interruption

Avant toute demande, confirmez que votre session vise le bon hôte. Les consultations suivantes aident à vérifier son identité et les utilisateurs connectés :

hostnamectl status
who

hostnamectl présente le nom et les informations système. Vérifiez aussi le contexte de la session : hôte physique, machine virtuelle ou conteneur ne représentent pas nécessairement le même périmètre. La commande who montre les sessions qu’elle sait recenser ; elle n’inventorie pas tous les traitements en arrière-plan ou les utilisateurs d’une application.

1. Choisissez une fenêtre d’intervention et prévenez les personnes concernées selon votre procédure.
2. Enregistrez les travaux, terminez ou mettez en pause les mises à jour, sauvegardes et écritures importantes avec la méthode prévue pour chaque service.
3. Vérifiez les services qui doivent repartir, leurs dépendances et les contrôles applicatifs à réaliser après le démarrage.
4. Assurez-vous d’avoir un accès de secours, par exemple la console de l’hyperviseur ou de la machine, si SSH ne revient pas.

Une procédure d’arrêt normale permet aux services de terminer leurs opérations, mais elle ne remplace pas la sauvegarde d’un document non enregistré ni le contrôle d’une application qui exige une préparation spécifique.

Demander un redémarrage normal

La commande suivante est une modification réelle à exécuter seulement sur la cible et à l’heure prévues, après les vérifications précédentes :

sudo reboot

N’attendez pas un résultat textuel unique qui certifierait le retour de la machine. Une session SSH peut se fermer pendant l’arrêt ; selon le client et le réseau, un message peut ressembler à :

Connection to host closed by remote host.

C’est une illustration de déconnexion, pas une preuve de redémarrage terminé. Ne répétez pas immédiatement la demande parce que la sortie vous semble vide. L’implémentation de reboot et ses options peuvent différer entre distributions ; vérifiez man reboot pour votre système.

Une fois la procédure immédiate engagée, ne supposez pas qu’une commande d’annulation pourra la rattraper. Si un délai d’annulation est nécessaire, utilisez une planification avant l’action immédiate.

Prévoir un délai et comprendre les options à risque

Dans l’implémentation systemd de shutdown, cette commande programme un redémarrage dans dix minutes :

sudo shutdown -r +10

Si l’intervention doit être annulée pendant qu’elle est encore en attente :

sudo shutdown -c

Vérifiez que la demande en attente est bien celle de votre intervention avant de l’annuler. Sur les versions systemd proposant --show, shutdown --show affiche l’action planifiée. L’annulation ne constitue pas une garantie de retour arrière une fois l’arrêt commencé ; elle ne vise pas une demande immédiate now ou +0 déjà lancée.

Ne choisissez pas -f simplement pour aller plus vite. Son comportement n’est pas identique à une unique option --force de systemctl reboot ; le manuel systemd le rapproche de la double force de cette autre commande. Une intervention forcée exige un diagnostic et une acceptation du risque de perte de données, hors de la procédure normale présentée ici.

Vérifier le nouveau démarrage et le retour du service

Après le délai nécessaire et la reconnexion, confirmez l’identité de l’hôte puis consultez le démarrage et les unités en échec :

hostnamectl status
uptime
who -b
systemctl --failed
journalctl -b -p err --no-pager

uptime indique la durée de fonctionnement ; who -b peut fournir le dernier démarrage si les données correspondantes sont disponibles. Comparez ces indications au relevé initial et au moment de l’intervention. systemctl --failed signale les unités chargées en échec, mais l’absence d’une unité dans cette liste ne prouve pas que toutes les applications répondent correctement.

Vérifiez les états des services attendus avec systemctl, puis réalisez un contrôle réel de l’application, du réseau et des données nécessaires. Les filtres journalctl par démarrage et priorité aident à lire les erreurs du nouveau démarrage. Si l’accès ne revient pas, utilisez la console prévue pour examiner le démarrage, plutôt que d’envoyer aveuglément une nouvelle action d’alimentation.

Le manuel systemd de reboot, halt et poweroff précise les options de force. Le manuel shutdown décrit le délai et l’annulation d’une demande encore planifiée.