Arrêter et redémarrer proprement un système Linux

Arrêter ou redémarrer un système Linux semble trivial — jusqu’au jour où un reboot sec coupe une transaction base de données, une session rsync, ou votre propre connexion SSH sans retour possible. Les systèmes modernes exposent plusieurs commandes (shutdown, reboot, poweroff, systemctl) qui ont des comportements proches mais pas identiques, et systemd les intègre toutes dans un modèle de targets qui remplace les anciens runlevels. Ce guide pose le minimum à savoir pour choisir la bonne commande, planifier une maintenance proprement, et ne jamais se retrouver bloqué en mode dégradé.

Ce que vous allez apprendre

Choisir entre shutdown, reboot, poweroff et systemctl selon le contexte
Planifier un arrêt ou un redémarrage en prévenant les sessions actives
Annuler un shutdown programmé avant qu’il ne démarre
Comprendre la correspondance runlevels SysV ↔ targets systemd
Basculer en mode rescue pour une intervention de secours
Réinitialiser un mot de passe root perdu via le GRUB

Dans quel contexte ?

Trois scénarios concrets motivent la maîtrise de ces commandes :

Maintenance programmée — vous devez rebooter après l’installation d’un kernel ou d’une mise à jour majeure. Prévenir les utilisateurs, laisser le temps aux services de terminer proprement, annuler si quelqu’un objecte.
Intervention urgente — un service est bloqué, les commandes ne répondent plus, il faut rebooter sans casser le filesystem.
Récupération — mot de passe root perdu, /etc/fstab cassé, système qui ne monte pas /. Passer par le mode rescue plutôt qu’un live CD chaque fois que possible.

C’est une compétence attendue en LFCS (domaine System Operations) et RHCSA (Operate running systems).

Prérequis

Un shell avec droits sudo ou root
Un serveur Linux moderne (systemd : Ubuntu 16.04+, Debian 8+, RHEL 7+, Rocky, Fedora)
Pour les manipulations rescue/GRUB : accès console physique ou virtuelle — SSH ne suffit pas quand le système est dégradé

Runlevels, targets : le modèle

L’héritage SysVinit : les runlevels

Les runlevels sont des niveaux d’exécution numériques hérités d’Unix System V. Vous les croiserez encore dans la doc et sur certains systèmes legacy.

Runlevel	Rôle
`0`	Arrêt complet (shutdown)
`1`	Mono-utilisateur (maintenance)
`2`	Multi-utilisateur sans réseau (variable)
`3`	Multi-utilisateur avec réseau (console)
`5`	Multi-utilisateur avec interface graphique
`6`	Redémarrage

Le runlevel par défaut était décrit dans /etc/inittab et chaque niveau avait ses scripts sous /etc/rc<N>.d/ (S* pour démarrer, K* pour arrêter un service).

Le modèle moderne : systemd targets

Avec systemd, les runlevels sont remplacés par des targets plus expressifs et composables. Chaque target regroupe des unités (services, sockets, mounts, timers) et peut dépendre d’autres targets.

Runlevel SysV	Target systemd
0	`poweroff.target`
1	`rescue.target`
2, 3, 4	`multi-user.target`
5	`graphical.target`
6	`reboot.target`

Vérifier le target par défaut :

systemctl get-default
# → graphical.target (poste de travail) ou multi-user.target (serveur)

Changer le target par défaut (actif au prochain boot) :

sudo systemctl set-default multi-user.target

Basculer à la volée vers un target :

sudo systemctl isolate multi-user.target   # arrête l'interface graphique
sudo systemctl isolate rescue.target       # mode de secours

Arrêter une machine

Plusieurs commandes, un seul but : couper proprement.

`shutdown` — la méthode canonique

shutdown prévient les utilisateurs connectés et laisse le temps aux services de terminer. C’est la commande à privilégier en production.

# arrêt immédiat
sudo shutdown -h now

# arrêt dans 10 minutes
sudo shutdown -h +10

# arrêt programmé avec message aux utilisateurs
sudo shutdown -h +5 "Maintenance : patch kernel"

# arrêt à une heure précise (format 24h)
sudo shutdown -h 23:00

Pour annuler un arrêt programmé tant qu’il n’a pas démarré :

sudo shutdown -c

`poweroff` — arrêter et couper l’alimentation

sudo poweroff

Équivalent à shutdown -h now + coupure explicite de l’alimentation. Utile sur serveur physique pour être sûr que la machine est vraiment éteinte.

`halt` — arrêt sans forcément couper l’alimentation

sudo halt

Historique, moins utilisé aujourd’hui. Sur matériel récent avec ACPI, le comportement est équivalent à poweroff.

`systemctl poweroff`

sudo systemctl poweroff

La forme systemd, équivalente à poweroff sur un système moderne. À connaître pour la cohérence avec le reste de l’écosystème systemd.

`init 0` / `telinit 0`

Commandes legacy encore supportées via la compatibilité SysV. À connaître pour comprendre les scripts anciens, pas à utiliser au quotidien sur un système systemd.

Redémarrer une machine

Les mêmes outils, avec des options différentes.

`reboot` — rapide et universel

sudo reboot

Fonctionne sur toutes les distributions. Termine les processus, démonte les systèmes de fichiers, puis redémarre.

`shutdown -r` — planification

sudo shutdown -r now              # redémarrage immédiat
sudo shutdown -r +5 "mise à jour" # dans 5 minutes, avec message
sudo shutdown -c                  # annuler

La version à privilégier quand d’autres utilisateurs peuvent être connectés.

`systemctl reboot`

sudo systemctl reboot

La forme systemd, équivalente à reboot. Cohérente avec systemctl poweroff, systemctl rescue, etc.

`init 6` / `telinit 6`

Legacy SysV, même fonction que reboot.

shutdown attend par défaut 90 secondes que chaque service termine via systemd-shutdown. Un service bloqué peut prolonger le délai jusqu’à DefaultTimeoutStopSec (90 s par défaut). Pour forcer un arrêt immédiat d’un système qui traîne :

sudo systemctl reboot --force --force   # ou: sudo reboot -f -f

À n’utiliser qu’en dernier recours — ça saute le démontage propre des filesystems.

Mode rescue et maintenance

Le rescue target bascule le système dans un état minimal : filesystem racine monté, shell root ouvert, pas de réseau ni de services. Utile pour réparer /etc/fstab, changer un mot de passe, lancer fsck.

Basculer en rescue depuis un système qui tourne

sudo systemctl isolate rescue.target

Tous les services non essentiels sont stoppés, un shell root attend sur la console.

Entrer en rescue au boot

Via le menu GRUB, éditer la ligne linux (touche e) et ajouter à la fin :

systemd.unit=rescue.target

Puis Ctrl+X pour démarrer avec cette option (unique). Très utile quand le système ne termine pas son boot normal.

Mode `emergency` — plus bas encore

Si même rescue ne démarre pas (filesystem cassé, par exemple), bascule vers emergency.target qui n’essaie même pas de monter le filesystem en lecture-écriture :

systemd.unit=emergency.target

Le filesystem racine est alors monté en lecture seule. Pour le passer en RW afin de réparer :

mount -o remount,rw /

Cas classique : réinitialiser un mot de passe root perdu

Redémarrer et entrer dans GRUB, interrompre le démarrage auto.
Éditer la ligne linux et ajouter en fin de ligne :
```
rd.break
```
(Alternative RHEL/Rocky. Sur Debian/Ubuntu : systemd.unit=rescue.target avec mot de passe root requis ; si aucun mot de passe n’est défini, rd.break reste la voie.)
Démarrer (Ctrl+X). Le système s’arrête avant de monter / — vous êtes dans un initramfs avec un shell switch_root:/#.
Monter le filesystem racine en RW :
Fenêtre de terminal
```
mount -o remount,rw /sysroot
chroot /sysroot
```
Changer le mot de passe :
Fenêtre de terminal
```
passwd root
```
Forcer le relabel SELinux (RHEL/Rocky/Fedora) au prochain boot, sinon le nouveau /etc/shadow sera refusé :
Fenêtre de terminal
```
touch /.autorelabel
```

Sortir et rebooter :

exit   # quitte le chroot
exit   # quitte l'initramfs, poursuit le boot

Bonnes pratiques

Préférez shutdown -r +N à reboot dès qu’il y a d’autres utilisateurs potentiellement connectés.
Annoncez une maintenance avec un message explicite dans la commande (-k envoie un wall message sans éteindre, utile pour prévenir sans encore rebooter).
Vérifiez systemctl list-units --failed avant un reboot : un service déjà en échec ne redémarrera pas magiquement après le reboot, il faut diagnostiquer avant.
Désactivez proprement les services qui ne doivent pas redémarrer (systemctl disable) plutôt que de les kill manuellement à chaque boot.
Logs du dernier reboot : journalctl -b -1 affiche le journal du boot précédent ; essentiel pour comprendre un crash.
last reboot et last shutdown listent l’historique depuis /var/log/wtmp.

Sécurité et rollback

Annuler un shutdown : sudo shutdown -c tant que l’arrêt n’a pas commencé.

Rebooter en target alternatif une seule fois :

sudo systemctl reboot --boot-loader-menu=10   # affiche le menu GRUB 10 s

Protéger le GRUB avec un mot de passe pour empêcher quiconque ayant accès à la console d’entrer en rescue — voir Durcir le bootloader dans le guide BP-028.
Garder un accès physique / IPMI / console cloud : si un kernel mis à jour ne boote pas, c’est la seule voie de retour.

Dépannage rapide

Symptôme	Cause probable	Action
`reboot` rend la main mais la machine ne redémarre pas	Service bloqué au stop, attend son timeout	Attendre ou forcer : `sudo systemctl reboot --force --force`
Le système boote en mode rescue sans raison	`/etc/fstab` cassé ou device absent	Éditer `/etc/fstab`, `systemctl daemon-reload`, puis `reboot`
`shutdown -c` n’annule rien	Le shutdown a déjà commencé son phase finale	Trop tard, attendre le reboot
Le mot de passe root ne passe pas après `passwd root`	Relabel SELinux non déclenché	Au prochain boot : `touch /.autorelabel` avant sortie
Aucune console après boot en rescue	Le target nécessite un mot de passe root que vous n’avez pas	Utiliser `rd.break` au niveau initramfs
Le système redémarre en boucle après reboot	Kernel cassé ou driver manquant	GRUB → choisir le kernel précédent (entrée « advanced options »)
`systemctl list-units --failed` liste plusieurs services après reboot	Dépendances mal ordonnées ou ressource absente	`journalctl -xe -u <service>` pour chaque service en échec

À retenir

Quatre commandes principales : shutdown (planifié), reboot (rapide), poweroff (éteindre), systemctl poweroff/reboot (forme systemd).
shutdown -r +N "message" est la commande par défaut en production — prévient les utilisateurs, laisse le temps aux services.
shutdown -c annule, tant que l’arrêt n’a pas commencé.
Targets systemd remplacent les runlevels : multi-user.target, graphical.target, rescue.target, emergency.target.
systemctl isolate <target> bascule à la volée sans reboot.
Rescue mode s’active via systemctl isolate rescue.target ou en passant systemd.unit=rescue.target dans GRUB.
rd.break dans GRUB permet de réinitialiser un mot de passe root perdu (avec relabel SELinux si applicable).
journalctl -b -1 pour analyser le boot précédent après incident.
Protéger GRUB par mot de passe en production pour empêcher l’accès rescue non autorisé.

Prochaines étapes

systemd et les services Approfondir la gestion des services Linux avec systemd, la colonne vertébrale derrière les commandes d'arrêt et de redémarrage.

Gérer les services Linux Activer, arrêter, redémarrer et diagnostiquer un service avec systemctl.

Gérer les logs avec journald Lire journalctl pour analyser le dernier boot et diagnostiquer un service en échec.

ANSSI-BP-028 — Durcissement Linux Protéger le bootloader, restreindre l'accès aux commandes d'arrêt, sécuriser les targets.