Objectifs

• Décrire la séquence d'arrêt : signal aux processus, arrêt des services, vidage des caches, synchronisation et démontage des disques.
• Décrire la séquence de démarrage : firmware (BIOS ou UEFI), chargeur d'amorçage, noyau, processus init (systemd).
• Expliquer pourquoi un arrêt brutal menace la cohérence des données, et comment la journalisation limite les dégâts.

1. La séquence d'arrêt

1.1 Prévenir puis arrêter les processus

Sous Linux, la commande systemctl reboot (ou reboot) demande à systemd, le premier processus du système, d'atteindre l'état « redémarrage ». systemd arrête alors les services (serveur web, base de données, impression…) dans l'ordre inverse de leurs dépendances : un service qui en utilise un autre est arrêté avant lui. Par exemple, l'application web est arrêtée avant la base de données dont elle a besoin.

Chaque processus reçoit d'abord un signal poli, SIGTERM (« termine proprement ») : il peut enregistrer son travail et fermer ses fichiers. S'il ne s'est pas arrêté après un délai (90 secondes par défaut avec systemd), il reçoit SIGKILL, qui le tue immédiatement sans lui laisser le temps de rien enregistrer. Sous Windows, le principe est le même : les applications sont invitées à se fermer, puis fermées de force si elles ne répondent pas.

1.2 Vider les caches et synchroniser les disques

Pour aller vite, le système n'écrit pas immédiatement sur le disque ce que les programmes enregistrent : les données sont d'abord placées dans le cache de pages, en mémoire vive. Les pages modifiées mais pas encore écrites sont dites sales (dirty). Sous Linux, elles sont écrites périodiquement, en général au plus tard une trentaine de secondes après leur modification avec les réglages par défaut.

À l'arrêt, le système force l'écriture de toutes les pages sales : c'est la synchronisation (l'appel système sync). Il demande aussi au disque de vider son propre cache interne.

1.3 Démonter les systèmes de fichiers

Enfin, les systèmes de fichiers sont démontés, ou remontés en lecture seule pour celui qui contient le système. Le système de fichiers est alors marqué « fermé proprement ». Le noyau appelle ensuite le firmware, qui réinitialise le processeur : la machine redémarre.

Le schéma ci-dessous déroule l'arrêt étape par étape.

2. La séquence de démarrage

1. Le firmware (BIOS ou UEFI), enregistré sur la carte mère, s'exécute dès la mise sous tension ou la réinitialisation. Il teste le matériel (le POST, test de mise sous tension), puis cherche un support de démarrage selon l'ordre configuré. Le BIOS, ancien, lit le premier secteur du disque (MBR) ; l'UEFI, plus récent, lit un programme de démarrage dans une partition dédiée (la partition système EFI).
2. Le chargeur d'amorçage (GRUB sous Linux, Windows Boot Manager sous Windows) choisit le système à lancer, charge le noyau en mémoire, et sous Linux un petit système de fichiers temporaire (l'initramfs) qui contient les pilotes nécessaires pour lire le vrai disque.
3. Le noyau prend le contrôle : il initialise la mémoire, les processeurs et les pilotes, puis monte le système de fichiers racine. Si celui-ci n'a pas été fermé proprement, une vérification ou une relecture du journal a lieu ici.
4. Le processus init, de numéro 1 (aujourd'hui systemd sur la plupart des distributions), démarre les services dans l'ordre de leurs dépendances, souvent plusieurs en parallèle, jusqu'à l'écran de connexion.

flowchart LR
A[Mise sous tension] --> B[Firmware BIOS ou UEFI]
B --> C[Chargeur GRUB]
C --> D[Noyau et initramfs]
D --> E[systemd PID 1]
E --> F[Services et connexion]

Pour bien retenir l'ordre, place toi-même les quatre acteurs sur la chaîne de démarrage.

3. Redémarrage et cohérence des données

Une donnée est cohérente quand toutes les écritures qui vont ensemble ont été faites, ou aucune. Lors d'une coupure brutale, le cache en mémoire est perdu et le disque peut contenir une opération à moitié écrite : un fichier dont la taille est mise à jour mais pas le contenu, un répertoire qui pointe vers des blocs non écrits.

Pour limiter ce risque, les systèmes de fichiers modernes (ext4 sous Linux, NTFS sous Windows) sont journalisés : avant de modifier leur structure, ils notent l'opération prévue dans un journal. Après une coupure, au démarrage suivant, le système relit le journal et termine ou annule les opérations inachevées. C'est beaucoup plus rapide qu'une vérification complète du disque. Les bases de données utilisent le même principe avec leur propre journal de transactions.

Exemple résolu : que reste-t-il après la coupure ?

Sur un PC Linux, Kouni enregistre son fichier de notes à 10 h 00 min 00 s. Avec les réglages par défaut, les pages sales sont écrites sur le disque environ 30 secondes après leur modification. Que se passe-t-il dans les deux cas suivants ?

1. À 10 h 00 min 10 s, une coupure de courant éteint la machine.
2. À 10 h 00 min 10 s, Kouni lance un redémarrage logiciel.

Erreurs fréquentes

• Confondre le firmware (BIOS ou UEFI, sur la carte mère) et le chargeur d'amorçage (GRUB, sur le disque).
• Penser que SIGKILL laisse au programme le temps d'enregistrer : c'est SIGTERM qui le permet.
• Croire qu'un système de fichiers journalisé ne perd jamais de données.
• Oublier que le cache d'écriture existe : « enregistré » ne veut pas toujours dire « écrit sur le disque ».

Récapitulatif

• Arrêt : services arrêtés dans l'ordre inverse des dépendances, SIGTERM puis SIGKILL, synchronisation des caches, démontage des systèmes de fichiers, réinitialisation.
• Démarrage : firmware (POST, BIOS ou UEFI), chargeur d'amorçage, noyau et initramfs, init (systemd, PID 1), services.
• Cohérence : un arrêt brutal saute la synchronisation ; la journalisation garde la structure cohérente, fsync garantit l'écriture d'un fichier.