Objectifs

• Classer un incident réel dans l'un des quatre grands motifs de redémarrage, à partir d'indices observables (journaux, commandes).
• Distinguer redémarrage doux (soft), dur (hard), planifié et forcé, et savoir ce que chacun garantit ou non.
• Choisir la commande adaptée sous Linux (systemd) et sous Windows, et mesurer les conséquences (indisponibilité, perte de données, vérification du disque).
• Calculer un budget d'indisponibilité pour décider quand redémarrer.

1. Les motifs : pourquoi redémarrer ?

Un redémarrage remet le système dans un état initial connu : la mémoire vive est vidée, les processus repartent de zéro, le noyau est rechargé. C'est utile, mais c'est aussi une coupure de service. On regroupe les raisons en quatre motifs.

2. Les types : comment redémarrer ?

2.1 Redémarrage doux (soft)

Le système d'exploitation orchestre l'arrêt : il demande aux services de s'arrêter proprement, écrit sur le disque les données encore en mémoire, démonte les systèmes de fichiers, puis demande au matériel de redémarrer.

• Linux (systemd) : systemctl reboot ou shutdown -r now (sur les systèmes systemd, reboot fait la même chose).
• Windows : shutdown /r /t 0.

Conséquences : coupure de service pendant l'arrêt et le démarrage ; pas de perte de données si les applications respectent le signal d'arrêt. Risque : faible ; un service qui ne s'arrête pas peut retarder l'arrêt (systemd attend un délai, par défaut 90 secondes, avant de le tuer).

2.2 Redémarrage planifié

C'est un redémarrage doux déclenché à une heure choisie, avec un avertissement aux utilisateurs connectés.

• shutdown -r 02:00 "Maintenance : redémarrage à 2 h" (à une heure précise) ou shutdown -r +15 (dans 15 minutes).
• shutdown -c annule un arrêt programmé.
• Windows : shutdown /r /t 900 (dans 900 secondes) ; shutdown /a annule.

Conséquences : les utilisateurs sont prévenus, on choisit l'heure creuse. Risque : le plus faible, à condition de vérifier le retour du service après coup.

2.3 Redémarrage forcé

Le système redémarre sans attendre que les programmes s'arrêtent. Il existe plusieurs niveaux.

• systemctl reboot --force (ou reboot -f) : saute l'arrêt ordonné des services, mais tue les processus et démonte les systèmes de fichiers.
• systemctl reboot --force --force : redémarre immédiatement, sans tuer les processus ni démonter les disques ; proche d'une coupure.
• Windows : shutdown /r /f /t 0 ferme les applications sans attendre l'utilisateur.
• Touches « SysRq » du noyau Linux (si elles sont activées) : on peut demander au noyau d'écrire les tampons sur disque (Alt+SysRq+S), de remonter les disques en lecture seule (U), puis de redémarrer (B). C'est le dernier recours « propre » sur une machine figée.

Conséquences : les applications perdent ce qu'elles n'avaient pas encore enregistré. Risque : moyen à élevé selon le niveau.

2.4 Redémarrage dur (hard)

Le courant est coupé puis rétabli, ou le bouton « reset » est pressé : le système d'exploitation n'a aucune chance de se préparer. Sur un serveur distant, on le fait par la carte de gestion (BMC), par exemple ipmitool chassis power cycle. Un délestage électrique sans onduleur produit le même effet.

Conséquences : données en mémoire perdues, écritures en cours interrompues ; au démarrage, le système de fichiers peut devoir être vérifié (fsck) ou rejouer son journal. Risque : le plus élevé ; à réserver aux machines totalement figées.

flowchart TD
  A[Machine qui pose probleme] --> B{Elle repond aux commandes}
  B -- oui --> C{Urgence immediate}
  C -- non --> D[Redemarrage planifie]
  C -- oui --> E[Redemarrage doux]
  B -- non --> F{Le noyau repond aux touches SysRq}
  F -- oui --> G[Redemarrage force S U B]
  F -- non --> H[Redemarrage dur par le BMC ou le courant]

3. Exemples résolus

Exemple 1 — Planifier après une mise à jour du noyau

Sur un serveur Ubuntu d'une PME de Cotonou, Moussa a installé les mises à jour. Le fichier /var/run/reboot-required existe. Les clients utilisent le service de 7 h à 22 h. Que faire, avec quelles commandes ?

Exemple 2 — Budget d'indisponibilité

Une plateforme de cours promet une disponibilité de 99,9 % sur un mois de 30 jours. Un redémarrage complet (arrêt, démarrage, vérifications) dure 6 minutes. Combien de redémarrages imprévus le budget permet-il ce mois-ci ? Cherche d'abord.

Exemple 3 — Retrouver la cause d'un redémarrage spontané

Le serveur d'un laboratoire à Bamako a redémarré seul dans la nuit. Comment savoir si c'était un arrêt propre ou un plantage ?

4. Erreurs fréquentes

• Redémarrer pour « réparer » une fuite mémoire et s'arrêter là : la fuite revient. Il faut signaler et corriger.
• Utiliser d'emblée le redémarrage dur alors que la machine répond encore : risque inutile de corruption.
• Oublier de vérifier après : un service qui ne redémarre pas seul (non activé avec systemctl enable) reste coupé.
• Redémarrer toute la machine alors que relancer un seul service (systemctl restart nom.service) suffisait : on coupe tous les autres services pour rien.
• Effacer les preuves : redémarrer avant d'avoir regardé les journaux, alors que le journal n'est pas persistant.

5. Récapitulatif

• Quatre motifs : mise à jour, fuite mémoire, plantage ou défaut matériel, optimisation/maintenance. Seuls la mise à jour et la maintenance sont vraiment « réglées » par le redémarrage.
• Quatre types, du plus sûr au plus risqué : planifié, doux, forcé, dur.
• Diagnostiquer avec journalctl, last -x, free -h, smartctl avant d'agir ; vérifier avec uname -r et systemctl --failed après.
• Le budget d'indisponibilité \(I_{\max} = (1 - D) \times T\) aide à décider combien de redémarrages on peut se permettre.