Commande reboot Linux : reboot, shutdown -r now, systemctl

La commande de redémarrage Linux : reboot, shutdown -r now et systemctl reboot

Sur toute distribution actuelle, les trois commandes ci-dessous redémarrent la machine exactement de la même manière. Exécutez-en une en root ou via sudo ; en SSH, un compte non privilégié obtient Failed to reboot system via logind: Interactive authentication required.

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

Il ne s'agit pas de trois implémentations. Sur les distributions systemd, /sbin/reboot, /sbin/shutdown, /sbin/halt et /sbin/poweroff sont des liens symboliques vers systemctl, qui regarde sous quel nom il a été appelé et bascule dans le mode de compatibilité correspondant ; ls -l $(which reboot) montre le lien. Quelle que soit l'écriture choisie, systemd démarre reboot.target, arrête chaque unité dans l'ordre inverse des dépendances, démonte les systèmes de fichiers et demande au noyau de redémarrer. En SSH, la connexion tombe en une seconde ou deux ; la durée d'absence de la machine dépend du noyau, d'une éventuelle vérification du système de fichiers et du parcours de démarrage du fournisseur, alors laissez passer une minute avant de conclure à un problème.

Éteindre : shutdown -h now, poweroff, halt et l'héritage init 6

Pour éteindre la machine, l'une ou l'autre de ces commandes suffit :

sudo shutdown -h now
sudo poweroff          # identical to: sudo systemctl poweroff

Sous systemd, -h signifie "arrêter ou éteindre, selon la valeur par défaut", et cette valeur par défaut est l'extinction : shutdown -h now et shutdown -P now sont donc identiques. La commande qui piège tout le monde, c'est halt tout court : elle arrête le système d'exploitation mais n'envoie jamais la demande d'extinction, si bien qu'une machine virtuelle reste bloquée sur System halted, toujours allouée et toujours facturée, jusqu'à ce que vous l'arrêtiez depuis le panneau. Utilisez plutôt halt -p, poweroff ou shutdown -h now.

Les formes SysV fonctionnent encore, car systemd fait correspondre les runlevels à des cibles : init 6 et telinit 6 renvoient à reboot.target, init 0 à poweroff.target. Elles sont inoffensives dans un vieux script, mais n'offrent ni message wall, ni planification, ni trace dans le journal : aucune raison de les taper à la main.

Planifier un redémarrage, l'annuler et prévenir les utilisateurs connectés

sudo shutdown -r +10 "Kernel update, back in about two minutes"
sudo shutdown -r 02:30
sudo shutdown -c

L'heure peut être now, +m pour m minutes à partir de maintenant, ou hh:mm au format 24 heures (une heure déjà passée aujourd'hui désigne demain). Sans aucune heure, shutdown suppose +1 : un simple sudo shutdown éteint la machine dans soixante secondes. Tout ce qui suit l'heure est diffusé comme message wall sur chaque terminal connecté, et logind répète l'avertissement à l'approche de l'échéance ; --no-wall le fait taire, et shutdown -k envoie l'avertissement sans rien planifier. Cinq minutes avant l'échéance, logind crée /run/nologin et les nouvelles connexions sont refusées à partir de là.

shutdown -c annule l'opération en attente, supprime /run/nologin et informe les utilisateurs connectés que l'arrêt est annulé. Pour vérifier qu'une opération est en attente, cherchez /run/systemd/shutdown/scheduled : ce fichier n'existe que tant qu'un arrêt est en file d'attente et consigne le mode ainsi que l'heure visée. Les versions récentes de systemd acceptent aussi systemctl reboot --when=+10m, avec --when=show et --when=cancel (vérifiez systemctl --help ; les versions plus anciennes ne l'ont pas).

Ce qui arrive aux services et aux sessions SSH pendant un redémarrage

Quand reboot.target est demandé, systemd arrête tout ce qui entre en conflit avec cette cible, c'est-à-dire presque toutes les unités. Les services s'arrêtent dans l'ordre inverse des dépendances : chacun exécute son ExecStop ou reçoit SIGTERM, et s'il n'a pas quitté après TimeoutStopSec (90 secondes par défaut, via DefaultTimeoutStopSec= dans /etc/systemd/system.conf), il reçoit SIGKILL. Ce délai correspond au compte à rebours A stop job is running for ... visible sur une console ; en général un démon qui ignore SIGTERM ou une base de données encore en train de vider ses tampons. Les systèmes de fichiers sont ensuite démontés ou remontés en lecture seule, puis le noyau redémarre. Inutile de lancer sync au préalable.

Votre session SSH ne bénéficie d'aucun traitement de faveur. ssh.service s'arrête, le scope qui porte votre session reçoit SIGTERM, votre shell meurt et le client affiche Connection to 203.0.113.10 closed by remote host. Un serveur tmux ou screen vous protège d'une connexion coupée, pas d'un redémarrage : ce qui tourne à l'intérieur disparaît aussi.

Ce qui revient est déterminé par l'activation, pas par ce qui tournait. Les unités marquées enabled redémarrent ; ce qui a été lancé à la main avec systemctl start, un processus nohup ou un conteneur Docker sans politique de redémarrage, non. Exécutez systemctl list-unit-files --state=enabled avant et systemctl --failed après ; le guide sur lister et filtrer les services avec systemctl explique comment lire les deux.

Redémarrer un VPS en sécurité : la checklist pré-vol

Sur un VPS, il n'y a pas d'accès physique : un redémarrage qui ne revient pas impose un détour par la console du fournisseur. Cinq vérifications, moins d'une minute au total, évitent presque tous ces détours.

1. Vérifier que le redémarrage est vraiment nécessaire

Toutes les mises à jour n'en exigent pas un. Sur Ubuntu, /var/run/reboot-required existe lorsqu'un paquet a demandé un redémarrage et /var/run/reboot-required.pkgs le nomme ; needrestart sur Debian et Ubuntu, et needs-restarting -r de dnf-utils sur la famille RHEL, font la même vérification ailleurs. Un nouveau noyau, une nouvelle glibc ou un nouveau systemd justifient un redémarrage ; un nginx corrigé nécessite seulement systemctl restart nginx. Installez d'abord les mises à jour en attente pour ne redémarrer qu'une fois ; le tutoriel sur la mise à jour d'Ubuntu en ligne de commande couvre la séquence apt et le drapeau reboot-required.

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs
uname -r; ls /boot/vmlinuz-*     # running kernel vs. newest installed

2. S'assurer que rien n'est en cours d'écriture

Interrompre un gestionnaire de paquets est le chemin le plus court vers un système à moitié configuré, et une sauvegarde tuée en pleine exécution est un fichier que vous prendrez plus tard pour une bonne copie. Repérez ces processus et voyez qui d'autre est connecté :

pgrep -a 'apt|dpkg|dnf|yum|unattended'
pgrep -a 'rsync|mysqldump|pg_dump|restic|borg'
w

3. Valider la configuration qui doit survivre au démarrage

Trois fichiers transforment un redémarrage de routine en verrouillage. Une erreur de syntaxe dans sshd_config empêche sshd de démarrer et vous prive de tout retour : sudo sshd -t n'affiche rien quand le fichier est valide, et si vous venez de durcir le démon SSH, lancez-le maintenant. Une entrée /etc/fstab pointant vers un périphérique qui n'existe plus fait basculer le démarrage en mode urgence, sauf si elle porte nofail ; sudo findmnt --verify détecte l'essentiel. Un /boot saturé peut laisser un noyau à moitié installé : vérifiez son espace libre. Les règles de pare-feu écrites directement avec iptables ou nft et jamais sauvegardées disparaîtront au redémarrage ; les règles UFW et firewalld, elles, persistent.

sudo sshd -t
sudo findmnt --verify
df -h / /boot

4. Prendre un état de référence

systemctl --failed
systemctl list-units --type=service --state=running > ~/services-before.txt

5. Redémarrer, puis vérifier

sudo systemctl reboot --message="post-update reboot"
# after reconnecting:
uptime -s; systemctl --failed
systemctl list-units --type=service --state=running | diff ~/services-before.txt -

Un uname -r conforme, un systemctl --failed propre et un diff vide signifient que le redémarrage a fait son travail.

Quand le redémarrage se bloque : le forcer, ou passer par la console du fournisseur

Si reboot rend la main mais que la machine ne s'arrête jamais, un stop job est bloqué ; systemctl list-jobs indique lequel. systemctl reboot --force saute l'arrêt ordonné des unités : les processus sont tués sans ménagement mais les systèmes de fichiers sont tout de même démontés, ce qui reste brutal mais raisonnablement sûr. --force --force redémarre immédiatement sans rien démonter et peut faire perdre des données : considérez-le comme un débranchement. L'interface SysRq du noyau est le dernier recours quand systemd lui-même ne répond plus. L'écriture dans /proc/sysrq-trigger est toujours autorisée pour root, quelle que soit la valeur du sysctl kernel.sysrq, mais la redirection doit s'exécuter en root : utilisez donc un shell root ou sudo sh -c :

echo s > /proc/sysrq-trigger   # sync dirty buffers
echo u > /proc/sysrq-trigger   # remount filesystems read-only
echo b > /proc/sysrq-trigger   # reboot right now

Passez par le panneau ou la console du fournisseur quand l'invité ne peut plus s'aider lui-même : SSH injoignable après un changement réseau ou pare-feu, un noyau qui panique au démarrage, une invite de mode urgence due à une ligne fstab erronée, un mot de passe root oublié. Reboot ou Shutdown dans un panneau envoient normalement un événement d'alimentation ACPI que l'invité traite via logind (HandlePowerKey= dans logind.conf), de sorte que les services s'arrêtent proprement. Reset, Force stop ou Power cycle coupent l'alimentation virtuelle sans prévenir : le journal du système de fichiers est rejoué au démarrage suivant, mais tout ce qui n'était pas écrit est perdu. La console VNC ou série est ce qui vous permet de voir GRUB, les messages du noyau et le shell d'urgence que SSH ne vous montrera jamais.

Vérifier l'uptime et la date du dernier redémarrage

uptime -p                      # up 3 days, 4 hours, 12 minutes
uptime -s                      # 2026-08-31 02:31:07
who -b                         # system boot  2026-08-31 02:31
last -x reboot shutdown | head
journalctl --list-boots

uptime -s et who -b affichent directement l'heure de démarrage. last -x lit /var/log/wtmp et liste les enregistrements reboot et shutdown : une ligne reboot sans ligne shutdown avant elle signifie que la machine s'est arrêtée de façon non propre (panique ou reset matériel). journalctl --list-boots numérote chaque démarrage connu du journal, 0 étant l'actuel et -1 le précédent ; journalctl -b -1 -e affiche alors les dernières lignes avant l'arrêt précédent, là où un dépassement de stop job ou un kill par manque de mémoire laisse sa trace. Si seul le démarrage courant est listé, le journal est volatile : créez /var/log/journal et redémarrez systemd-journald.

Toutes les commandes ci-dessus reposent sur une hypothèse : que vous puissiez encore atteindre l'invité lorsqu'il refuse de revenir. Un VPS Linux KVM avec accès console vous donne exactement cela : une vraie machine virtuelle avec son propre noyau, du CPU et de la RAM dédiés, un root complet, et une console pour les jours où SSH n'est pas une option. rdp.monster en livre un environ 10 secondes après confirmation du paiement, avec une bande passante illimitée (fair-use), sans KYC, cartes et crypto acceptées, à partir de $8.99/mois.