Réinitialisations du watchdog sur Ubuntu 24.04 : détecter les blocages silencieux avant qu’ils n’impactent la disponibilité (cas n°18)

décembre 24, 2025 • février 3, 2026 • Lecture : 31 min • Views: 6

Cet article vous a aidé ?

Rien ne met plus à l’épreuve une rotation d’astreinte qu’un serveur qui « redémarre tout seul » sans arrêt propre, sans dump de crash et avec des logs qui s’arrêtent en plein milieu. Le service revient, les tableaux de bord redeviennent verts, et tout le monde fait comme si c’était un coup de chance — jusqu’à ce que cela se reproduise pendant la démo du CEO.

Ubuntu 24.04 est tout à fait capable de vous dire ce qui s’est passé. L’astuce consiste à savoir où le watchdog intervient dans la chaîne, ce que signifie réellement un « blocage silencieux », et comment capturer des preuves avant que la réinitialisation n’efface la scène du crime.

Ce que font réellement les watchdogs (et ce qu’ils ne font pas)

Un watchdog est un minuteur avec une mission : si le système cesse de faire des progrès, le redémarrer (ou au moins pousser un grand cri). Dans Linux vous verrez plusieurs couches :

Watchdog matériel (BMC/iDRAC/iLO, ou un minuteur du chipset). Si le noyau ne le « caresse » pas, le matériel réinitialise la machine. C’est celui qui continue de fonctionner quand le noyau est complètement bloqué.
Watchdogs du noyau (soft lockup, hard lockup/NMI watchdog). Ils détectent des CPU bloqués en espace noyau, des régions avec interruptions désactivées ou des états non planifiables.
Watchdogs en espace utilisateur (systemd watchdog, heartbeats d’application). Ils détectent un service vivant-mais-mort, comme un démon coincé dans une boucle infinie tout en conservant son PID.

Les watchdogs ne sont pas des « détecteurs de crash ». Ce sont des détecteurs de « nous avons perdu le contrôle ». Un panic laisse des traces (traces d’appel, dumps). Un blocage est une coupure. Les watchdogs existent parce que, en production, une défaillance propre est un luxe.

Voici la partie douloureuse : la même réinitialisation que vous aimez pour rétablir le service détruit aussi vos meilleures preuves. Si votre stratégie est « on attend que ça se reproduise puis on SSH », vous faites de l’archéologie avec un souffleur de feuilles.

Conseil orienté : utilisez un watchdog en production, mais traitez-le comme un filtre d’alarme qui déclenche la capture de données. Configurez la capture d’abord. Puis laissez-le réinitialiser.

Deux termes que vous verrez souvent

Soft lockup : le CPU est bloqué à exécuter du code noyau trop longtemps sans planification. Le noyau peut encore fonctionner suffisamment pour se plaindre.
Hard lockup : le CPU ne répond plus aux interruptions (ou semble mort). La détection repose souvent sur des NMI ou des sources de temps séparées.

Une citation, parce qu’elle est vraie

Werner Vogels (idée paraphrasée) : « Vous concevez pour la défaillance — parce que l’échec n’est pas optionnel, c’est une partie de l’exploitation à grande échelle. »

Pour la précision : un « blocage silencieux » n’est pas silencieux. Il parle juste au mauvais endroit — comme le ring buffer du noyau que vous n’avez jamais persisté, sur une file d’attente disque qui est en train de geler.

Faits intéressants et contexte historique

Les watchdogs existent depuis assez longtemps pour avoir des bagages. Quelques points de contexte utiles quand vous lisez des logs à 03:00 :

Les minuteurs watchdog précèdent Linux de plusieurs décennies. Les automates industriels les utilisaient parce qu’une boucle de contrôle bloquée peut être un problème de sécurité, pas seulement un SLA.
La détection des soft lockups dans Linux est arrivée avec des noyaux plus préemptifs. Au fur et à mesure de l’évolution du scheduler et de la préemption, « CPU bloqué » est devenu mesurable et exploitable.
Le rôle du NMI watchdog a évolué. Il était autrefois un outil courant « le CPU est-il vivant ? » ; les noyaux modernes utilisent souvent l’infrastructure perf events dans ce chemin de détection.
La détection des tâches bloquées a été ajoutée parce que « il attend juste de l’I/O » peut quand même tuer un système. Une tâche bloquée en état D peut bloquer des sous-systèmes critiques même si les CPU vont bien autrement.
Les watchdogs matériels ont migré vers les BMC. Beaucoup de serveurs peuvent vous réinitialiser même si l’OS a disparu, ce qui est génial jusqu’à ce que la configuration du BMC devienne un domaine de défaillance séparé.
systemd a popularisé les watchdogs de service. Pas le premier, mais il a rendu le « le processus doit me pinguer » courant dans les distributions Linux.
Les environnements virtualisés compliquent la notion de temps. Les seuils du watchdog peuvent se déclencher sous forte contention de l’hôte parce que votre invité cesse de recevoir du CPU.
Les blocages de stockage sont devenus plus visibles avec le NVMe. C’est rapide — jusqu’à ce que le firmware/driver fasse un cas limite qui coince les files, et alors tout ce qui touche au disque semble coupable.
Certaines « réinitialisations aléatoires » sont délibérées. Une réinitialisation par watchdog matériel est indiscernable d’un coup de courant à moins de collecter les bons logs hors bande.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Si vous êtes en mode incident, vous n’avez pas le temps pour une grande théorie. Il faut localiser rapidement le goulot d’étranglement : blocage CPU, gel I/O, pression mémoire, réinitialisation matérielle ou famine CPU en virtualisation.

Premier : prouver s’il s’agissait d’une réinitialisation par watchdog vs un reboot normal

Vérifiez les logs du boot précédent pour des messages watchdog/lockup.
Vérifiez la présence de marqueurs d’arrêt propre (généralement absents).
Consultez les logs hors-bande/BMC si vous les avez (même une coupure de courant ressemble à une réinitialisation).

Deuxième : décider si le système a gelé au niveau CPU ou I/O

Recherchez soft lockup, hard LOCKUP ou des avertissements du NMI watchdog (voie CPU).
Recherchez blocked for more than, hung_task, timeouts NVMe, réinitialisations SCSI, erreurs ext4/XFS I/O (voie I/O).
Corrélez avec les symptômes applicatifs : timeouts vs indisponibilité totale.

Troisième : collecter des preuves pour la prochaine fois

Activez journald persistant et préservez le ring buffer du noyau si possible.
Configurez kdump pour capturer un vmcore sur panic (et configurez le watchdog pour panicer au lieu de redémarrer si approprié).
Configurez les triggers sysrq et la journalisation distante afin d’avoir une piste même lorsque les disques locaux bloquent.

Point de décision : si vous ne pouvez pas capturer de preuves, vous ne faites pas de débogage — vous devinez. Et deviner coûte cher.

Des symptômes aux preuves : les signaux importants

« Ça a redémarré » est un résultat, pas un diagnostic. Les réinitialisations watchdog sont généralement la conséquence d’un des éléments suivants :

Blocage CPU : noyau coincé avec interruptions désactivées, ou bloqué à spinner sur un lock. Le watchdog l’attrape.
Impasse I/O ou spirale de timeouts de périphérique : les files de stockage se bloquent ; les tâches s’accumulent en état D ; le système devient non réactif ; le watchdog finit par déclencher.
Pression mémoire et tempêtes de reclaim : ce n’est pas un blocage, mais ça y ressemble. Si kswapd et alliés se retrouvent coincés dans des reclaim pathologiques ou en attente d’I/O, la machine « gèle ».
Défaillances firmware/matériel : erreurs corrigées jusqu’à ce qu’elles ne le soient plus ; tempêtes AER PCIe ; réinitialisations de contrôleur NVMe ; événements ECC ; parfois le watchdog matériel coupe simplement l’alimentation.
Contention sur l’hôte VM : l’invité cesse d’être planifié ; le watchdog se déclenche dans l’invité ; l’hôte apparaît innocent dans les logs (comme toujours).

Ubuntu 24.04 embarque un noyau moderne et une pile systemd récente, ce qui est une bonne nouvelle : vous avez les mécanismes pour voir ce qui se passe. La mauvaise nouvelle : les valeurs par défaut favorisent « continuer à fonctionner » plutôt que « laisser un rapport d’autopsie parfait ». Vous devrez faire des compromis délibérés.

Tâches pratiques (commandes, sorties, décisions)

Ce ne sont pas des « lancez ça pour avoir l’air occupé ». Chacune donne un signal précis, et vous devez prendre une décision en fonction.

Task 1: Confirm the reboot was not clean (previous boot)

cr0x@server:~$ journalctl -b -1 -p warning..alert --no-pager | tail -n 40
Aug 12 03:14:22 server kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 26s! [kworker/7:1:1234]
Aug 12 03:14:22 server kernel: Modules linked in: nvme tcp_bbr ...
Aug 12 03:14:30 server kernel: NMI watchdog: Watchdog detected hard LOCKUP on cpu 7
Aug 12 03:14:31 server systemd[1]: Starting Reboot...
Aug 12 03:14:31 server kernel: watchdog: Initiating system reboot

Ce que cela signifie : soft lockup évoluant en détection de hard lockup, puis une réinitialisation déclenchée par le watchdog.

Décision : traitez comme un blocage noyau/matériel/driver, pas comme un redémarrage applicatif. Passez immédiatement à la collecte de preuves noyau et périphériques.

Task 2: See whether the system recorded a normal shutdown

cr0x@server:~$ last -x | head -n 8
reboot   system boot  6.8.0-41-generic Mon Aug 12 03:15   still running
crash    system crash 6.8.0-41-generic Mon Aug 12 03:14 - 03:15  (00:01)
reboot   system boot  6.8.0-41-generic Sun Aug 11 18:02 - 03:15  (09:13)
shutdown system down  6.8.0-41-generic Sun Aug 11 18:01 - 18:02  (00:01)

Ce que cela signifie : un marqueur de crash apparaît plutôt qu’une séquence d’arrêt propre.

Décision : priorisez les logs noyau et les preuves hors-bande ; ne perdez pas de temps à auditer les redémarrages des unités systemd.

Task 3: Identify active watchdog devices and drivers

cr0x@server:~$ ls -l /dev/watchdog /dev/watchdog0 2>/dev/null || echo "no /dev/watchdog node"
crw------- 1 root root 10, 130 Aug 12 08:40 /dev/watchdog
crw------- 1 root root 10, 130 Aug 12 08:40 /dev/watchdog0

Ce que cela signifie : un périphérique caractère watchdog existe ; quelque chose peut l’armer.

Décision : confirmez qui l’utilise (systemd, démon watchdog, agent fournisseur). Un espace utilisateur mal configuré peut provoquer des réinitialisations surprises.

Task 4: Check whether systemd is feeding a hardware watchdog

cr0x@server:~$ systemctl show -p RuntimeWatchdogUSec -p RebootWatchdogUSec -p WatchdogDevice systemd-logind
RuntimeWatchdogUSec=0
RebootWatchdogUSec=0
WatchdogDevice=

Ce que cela signifie : ces valeurs ici ne sont pas le watchdog global de systemd ; elles sont par unité. Ne les interprétez donc pas mal.

Décision : vérifiez ensuite la configuration globale de systemd ; la sortie par unité peut vous endormir dans une conclusion erronée.

Task 5: Check global systemd watchdog settings

cr0x@server:~$ grep -E '^(RuntimeWatchdogSec|RebootWatchdogSec|ShutdownWatchdogSec|WatchdogDevice)=' /etc/systemd/system.conf
RuntimeWatchdogSec=30s
RebootWatchdogSec=10min
ShutdownWatchdogSec=2min

Ce que cela signifie : systemd est configuré pour armer un watchdog pendant le runtime et les transitions reboot/shutdown.

Décision : validez le périphérique/driver watchdog et assurez-vous que vos délais sont raisonnables pour vos pires pauses I/O (plus loin on en reparle).

Task 6: Identify the kernel lockup detection configuration

cr0x@server:~$ sysctl kernel.watchdog kernel.softlockup_panic kernel.hardlockup_panic kernel.watchdog_thresh
kernel.watchdog = 1
kernel.softlockup_panic = 0
kernel.hardlockup_panic = 0
kernel.watchdog_thresh = 10

Ce que cela signifie : la détection watchdog est activée ; elle avertit mais ne panique pas par défaut. Le seuil est de 10 secondes (valeur par défaut courante).

Décision : en production, envisagez de panicer sur lockup (avec kdump configuré) pour obtenir un vmcore. Redémarrer sans preuves, c’est finir par « surveiller » au lieu de corriger.

Task 7: Inspect dmesg from the previous boot (if preserved)

cr0x@server:~$ journalctl -k -b -1 --no-pager | egrep -i 'watchdog|lockup|hung|blocked for more than|nvme|reset|I/O error' | tail -n 60
Aug 12 03:13:58 server kernel: nvme nvme0: I/O 123 QID 4 timeout, aborting
Aug 12 03:14:02 server kernel: nvme nvme0: Abort status: 0x371
Aug 12 03:14:06 server kernel: INFO: task jbd2/nvme0n1p2-8:512 blocked for more than 120 seconds.
Aug 12 03:14:06 server kernel:       Tainted: G           O       6.8.0-41-generic #41-Ubuntu
Aug 12 03:14:22 server kernel: watchdog: BUG: soft lockup - CPU#7 stuck for 26s! [kworker/7:1:1234]
Aug 12 03:14:31 server kernel: watchdog: Initiating system reboot

Ce que cela signifie : des timeouts NVMe ont précédé un thread de journalisation bloqué, puis un avertissement de lockup CPU. C’est le classique « le stockage a rendu le noyau misérable ».

Décision : traitez le chemin de stockage (firmware, driver, erreurs PCIe, mise en file) comme suspect principal. Ne perdez pas des jours à blâmer la pool de threads de votre appli.

Task 8: Verify journald persistence (so you don’t lose the trail)

cr0x@server:~$ grep -E '^\s*Storage=' /etc/systemd/journald.conf
Storage=auto

cr0x@server:~$ ls -ld /var/log/journal || echo "no persistent journal directory"
ls: cannot access '/var/log/journal': No such file or directory
no persistent journal directory

Ce que cela signifie : les logs peuvent être volatils. Après une réinitialisation, vos meilleurs indices peuvent avoir disparu.

Décision : activez le journal persistant sur les serveurs où vous tenez aux post-mortems. Oui, ça utilise le disque. Tout comme le downtime.

Task 9: Enable persistent journald storage (safely)

cr0x@server:~$ sudo mkdir -p /var/log/journal
cr0x@server:~$ sudo systemd-tmpfiles --create --prefix /var/log/journal
cr0x@server:~$ sudo systemctl restart systemd-journald
cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 1.1G in the file system.

Ce que cela signifie : journald persiste maintenant les logs. Vous avez une chance la prochaine fois.

Décision : définissez des limites de rétention adaptées à vos disques et à vos besoins d’intervention.

Task 10: Check for kernel “hung task” policy and decide if you want panics

cr0x@server:~$ sysctl kernel.hung_task_timeout_secs kernel.hung_task_panic kernel.hung_task_warnings
kernel.hung_task_timeout_secs = 120
kernel.hung_task_panic = 0
kernel.hung_task_warnings = 1

Ce que cela signifie : le noyau avertira des tâches bloquées depuis 120 secondes, mais ne panique pas.

Décision : si les blocages tuent la disponibilité, envisagez de panicer (avec kdump) après des deadlocks confirmés pour capturer l’état. C’est un compromis : un panic est disruptif, mais une réinitialisation watchdog sans preuve l’est aussi.

Task 11: Verify kdump is installed and armed

cr0x@server:~$ systemctl status kdump-tools --no-pager
● kdump-tools.service - Kernel crash dump capture service
     Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; preset: enabled)
     Active: active (exited) since Mon 2025-08-12 08:41:12 UTC; 3h ago
       Docs: man:kdump-tools(8)

Ce que cela signifie : kdump est activé. Ce n’est pas la preuve que ça marchera, mais c’est un début.

Décision : validez la réservation crashkernel et faites un test de crash contrôlé pendant une fenêtre de maintenance.

Task 12: Check crashkernel reservation (without it, kdump often fails)

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.8.0-41-generic root=UUID=... ro crashkernel=512M-:192M quiet splash

Ce que cela signifie : crashkernel est réservé. La taille compte ; trop petite et les dumps échouent sous charge.

Décision : assurez-vous qu’elle est adéquate pour votre taille de RAM et votre noyau ; ajustez si les vmcores sont tronqués ou manquants.

Task 13: Force a controlled crash test (maintenance window only)

cr0x@server:~$ sudo sysctl -w kernel.sysrq=1
kernel.sysrq = 1
cr0x@server:~$ echo c | sudo tee /proc/sysrq-trigger
c

Ce que cela signifie : le noyau panique immédiatement. Si kdump est correct, vous obtiendrez un vmcore au redémarrage.

Décision : si vous n’obtenez pas de dump, corrigez kdump maintenant — pas après le prochain blocage en production.

Task 14: After reboot, confirm a dump exists

cr0x@server:~$ ls -lh /var/crash | tail -n 5
drwxr-xr-x 2 root root 4.0K Aug 12 09:02 202508120902
cr0x@server:~$ ls -lh /var/crash/202508120902 | egrep 'vmcore|dmesg'
-rw-r----- 1 root root 2.8G Aug 12 09:03 vmcore
-rw-r----- 1 root root  92K Aug 12 09:03 dmesg.0

Ce que cela signifie : vous pouvez capturer des preuves. Ça change complètement la donne.

Décision : envisagez de changer la gestion des lockups/hung-task de « avertir seulement » à « panicer » pour les classes de blocages que vous ne pouvez pas autrement déboguer.

Task 15: Check for PCIe AER errors that often precede device wedges

cr0x@server:~$ journalctl -k -b -1 --no-pager | egrep -i 'AER|pcie|nvme.*reset|link down|fatal error' | tail -n 40
Aug 12 03:13:40 server kernel: pcieport 0000:3b:00.0: AER: Corrected error received: 0000:3b:00.0
Aug 12 03:13:40 server kernel: pcieport 0000:3b:00.0: AER: [ 0] RxErr
Aug 12 03:13:58 server kernel: nvme nvme0: controller is down; will reset: CSTS=0x3

Ce que cela signifie : le bus se plaint et la réinitialisation du contrôleur NVMe a suivi. Ce n’est pas « un bug d’appli ».

Décision : impliquez les propriétaires matériel/firmware : BIOS, firmware NIC/HBA/NVMe, topologie PCIe, paramètres de gestion d’alimentation.

Task 16: Check I/O pressure and stalls (post-incident baseline)

cr0x@server:~$ cat /proc/pressure/io
some avg10=0.00 avg60=0.05 avg300=0.12 total=11234567
full avg10=0.00 avg60=0.01 avg300=0.03 total=1234567

Ce que cela signifie : PSI montre à quelle fréquence les tâches sont en attente d’I/O. Après un événement de blocage, vous voulez comparer avec une baseline ; les pics se corrèlent avec « tout semble gelé ».

Décision : si PSI est élevé pendant les périodes normales, vous avez probablement une contention de stockage chronique ; les lockups peuvent être la queue extrême.

Task 17: Confirm NVMe health and error logs (if NVMe is involved)

cr0x@server:~$ sudo nvme list
Node             SN                   Model                                   Namespace Usage                      Format           FW Rev
/dev/nvme0n1     S6XXXXXXXXXXXX       ACME NVMe Datacenter 3.2TB              1         1.20  TB / 3.20  TB        512   B +  0 B   1.2.3
cr0x@server:~$ sudo nvme smart-log /dev/nvme0
critical_warning                    : 0x00
media_errors                        : 0
num_err_log_entries                 : 14
cr0x@server:~$ sudo nvme error-log /dev/nvme0 | head
Entry[ 0]
error_count     : 14
sqid            : 4
cmdid           : 0x001a
status_field    : 0x4004
parm_err_loc    : 0x0000

Ce que cela signifie : le contrôleur a enregistré des erreurs. Pas forcément fatal, mais c’est une piste qui correspond aux timeouts.

Décision : planifiez des mises à jour de firmware et consultez les avis du fournisseur. Si vous pouvez corréler les entrées d’erreur avec les horodatages du blocage, vous avez un solide dossier.

Task 18: Check CPU starvation signals (virtualization or noisy neighbors)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0-41-generic (server)  08/12/2025  _x86_64_  (16 CPU)

08:52:01 AM  CPU   %usr %nice  %sys %iowait  %irq %soft %steal %idle
08:52:02 AM  all   12.0  0.0    5.0   2.0     0.0  0.5   18.0  62.5
08:52:03 AM  all   10.8  0.0    4.7   1.8     0.0  0.4   21.3  61.0

Ce que cela signifie : un %steal élevé indique que la VM ne reçoit pas son tour de CPU. Les watchdogs dans les invités peuvent se déclencher parce que le temps s’arrête effectivement.

Décision : si c’est une VM, traitez la contention hôte comme suspect de première classe ; ajustez les seuils du watchdog prudemment ou corrigez la capacité de l’hôte.

Task 19: Identify whether CPU frequency/power settings are doing something weird

cr0x@server:~$ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor 2>/dev/null || echo "cpufreq not exposed"
performance

Ce que cela signifie : le governor est réglé sur performance (souvent adapté pour les serveurs). Les modes d’économie d’énergie peuvent interagir avec la latence et les timeouts de périphériques sur certaines plateformes.

Décision : si vous observez des lockups corrélés à des états C profonds ou à une gestion d’alimentation agressive, coordonnez des changements BIOS et paramètres noyau ; ne faites pas de tuning aveugle en production.

Blague n°1 : Un watchdog qui redémarre votre serveur, c’est comme un détecteur de fumée qui éteint l’incendie en faisant exploser l’immeuble. Efficace, mais vous voulez tout de même le rapport d’incident.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils avaient un récit rassurant : « La base de données a planté. » Les graphiques montraient la latence des requêtes monter, puis une falaise. Une réinitialisation watchdog a suivi. Le responsable d’incident a donc fait ce que beaucoup d’entre nous font sous pression : attribuer des actions à l’équipe DB, demander des plans de requêtes et noter « optimiser les index ».

L’équipe DB était agacée mais professionnelle. Ils ont extrait les logs de requêtes lentes, comparé les baselines, et n’ont rien trouvé de spectaculaire. Pendant ce temps, le blocage est revenu — encore pendant une période de volume « normal ». Ce n’était pas lié à des déploiements non plus. La seule chose stable était la réinitialisation watchdog.

Un ingénieur stockage a finalement posé la question grossière : « Avons-nous des logs noyau persistants ? » Non. Journald était volatile. Le seul indice était une capture d’écran de console tronquée prise sur un KVM distant montrant une ligne sur blocked for more than 120 seconds.

Ils ont activé journald persistant et configuré kdump. Lors de l’occurrence suivante, les logs montraient des timeouts NVMe évoluant vers un thread de journalisation coincé en état D, puis des lockups. La base de données était dommage collatéral : elle attendait un fsync qui n’est jamais revenu. L’histoire « la base de données a planté » était confortable, mais fausse.

La correction était ennuyeuse : mises à jour firmware pour les NVMe, mise à jour du noyau qui améliorait la gestion des réinitialisations de contrôleur, et rollback d’un réglage BIOS de gestion d’alimentation PCIe agressif. La DB était innocente, mais il a fallu une semaine pour le prouver parce que l’équipe avait supposé que le composant le plus bruyant causait la défaillance.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une équipe plateforme voulait une récupération plus rapide des crashes. Ils ont activé un watchdog matériel avec un timeout court et configuré systemd pour le « caresser ». Leur logique : si le noyau gèle, redémarrer vite, réduire l’impact client. Ce n’était pas absurde ; c’est un pattern courant dans les appliances.

Puis ils ont déployé une « amélioration de performance » : écriture plus agressive des pages sales et profondeurs de files I/O plus élevées sur les nœuds les plus chargés. Ça fonctionnait en benchmark. En production, pendant une fenêtre de compactage lourde, un sous-ensemble de nœuds devenait non réactif assez longtemps pour manquer les pings du watchdog. Le watchdog matériel les a réinitialisés en plein écriture.

Après le redémarrage, les systèmes de fichiers ont rejoué les journaux, les services ont redémarré et le parc semblait « sain ». Mais des alarmes de corruption de données subtiles ont commencé à apparaître — pas immédiatement, mais des semaines plus tard — parce que certaines invariantes applicatives n’aimaient pas être interrompues à ce moment-là. L’optimisation n’a pas directement corrompu les disques ; elle a corrompu des hypothèses sur l’atomicité et le timing des écritures.

Le post-mortem a été tranchant : le watchdog a réduit le temps moyen de récupération mais augmenté le temps moyen pour prouver l’innocence. Il masquait le motif sous-jacent des blocages I/O et raccourcissait la fenêtre pour capturer des preuves. Ils ont corrigé en augmentant les timeouts du watchdog, en activant panic-on-lockup avec kdump sur une sous-population, et en instrumentant la pression I/O. La grande leçon : un watchdog ne remplace pas la planification de capacité, et encore moins la compréhension des latences de queue de stockage.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une société financière avait une habitude dont on se moquait : chaque mise à jour de noyau et changement de firmware exigeait une « feuille de plan de preuves en cas d’échec » d’une page. Elle listait où vont les logs, si kdump est testé et quels logs hors-bande sont conservés. Personne n’aimait ce document. Ça ressemblait à du cosplay conformité.

Puis un parc de serveurs a commencé à faire des réinitialisations watchdog occasionnelles sous charge maximale. Les équipes applicatives étaient prêtes à se blâmer mutuellement, comme la tradition l’exige. Mais le plan de preuves signifiait deux choses déjà vraies : journald était persistant, et kdump avait été testé le trimestre précédent.

Le tout premier incident a produit un vmcore. Les traces noyau montraient un deadlock impliquant un chemin driver spécifique sous forte charge d’interruptions. Ils l’ont corrélé avec une mise à jour firmware récente qui changeait le comportement d’interruption d’un périphérique PCIe partageant un root complex avec le contrôleur NVMe.

Ils n’ont pas eu besoin d’attendre trois redémarrages de plus pour être « sûrs ». Ils ont rollbacké le firmware, isolé le problème de topologie PCIe, et appliqué une mise à jour noyau avec le correctif pertinent une fois validée. L’impact sur la disponibilité a été réel mais contenu.

La pratique ennuyeuse — garder la capture de preuves prête — n’a pas empêché le blocage. Elle a empêché la semaine suivante de chaos. C’est à ça que ressemble une bonne exploitation : pas des héros, juste la vérité pré-positionnée.

Ajuster les watchdogs sans s’auto-saboter

Les watchdogs ont deux modes d’échec :

Trop sensibles : ils réinitialisent des systèmes sains mais occupés (faux positifs), transformant des pics de charge en outages.
Trop laxistes : ils ne se déclenchent jamais, vous laissant avec des trous noirs de plusieurs heures jusqu’à ce que quelqu’un coupe l’alimentation.

Ubuntu 24.04 vous donne des leviers à plusieurs couches. Utilisez-les délibérément.

Seuils de lockup du noyau : ne pas « corriger » les lockups en les masquant

kernel.watchdog_thresh contrôle la durée avant les avertissements soft lockup. L’augmenter peut réduire le bruit dans des environnements à latence élevée, mais retarde aussi la détection de vrais deadlocks.

Mon biais : n’augmentez pas les seuils tant que vous n’avez pas mesuré la planification CPU et la pression I/O. Si vous voyez des avertissements de lockup parce que votre VM est affamée (%steal élevé), corrigez l’hôte. Si vous voyez des avertissements parce que des pauses de stockage bloquent des threads critiques, corrigez le stockage.

Envisagez panic-on-lockup pour la forensique (avec garde-fous)

Si vous ne pouvez pas reproduire l’incident et qu’il est rare mais coûteux, définissez :

kernel.softlockup_panic=1 et/ou kernel.hardlockup_panic=1
Assurez-vous que kdump fonctionne et que crashkernel est correctement dimensionné
Testez d’abord sur un canari

Cela transforme un blocage en dump de crash. Les crashes sont débogables ; les blocages silencieux, ce sont des impressions.

RuntimeWatchdogSec de systemd : alignez-le sur la réalité

Le watchdog runtime de systemd est souvent câblé sur le watchdog matériel. Si systemd ne peut pas tourner (parce que le noyau est bloqué), il ne peut pas caresser le watchdog, et le matériel vous réinitialise. C’est acceptable — si le timeout est suffisamment long pour éviter les réinitialisations pendant des pauses légitimes (reconstruction RAID lourde ou timeouts pathologiques de périphériques).

Règle empirique : réglez le timeout du watchdog matériel pour qu’il soit plus long que la pire pause de stockage attendue plus assez de temps pour la stratégie kdump/panic si vous l’utilisez. Si votre array peut suspendre l’I/O 45 secondes pendant un basculement de contrôleur, un watchdog runtime à 30 secondes est un problème auto-infligé.

Blague n°2 : Si vous réglez votre watchdog à 10 secondes sur une machine de stockage, vous ne faites pas du SRE — vous speedruinez la réponse aux incidents.

Stockage et blocages I/O : le gel qui ressemble à un problème CPU

En tant qu’ingénieur stockage, voici le schéma que je vois souvent : des avertissements de lockup CPU apparaissent dans les logs, donc le blâme va au CPU ou au scheduler noyau. Mais le déclencheur est souvent l’I/O. Quand le stockage se bloque, les tâches restent en état D. Les threads noyau s’accumulent. Le reclaim mémoire s’emmêle. Finalement un CPU boucle sur un chemin qui arrête la planification, et le watchdog se déclenche. Le CPU est le messager.

Lignes de log révélatrices qui impliquent le stockage

nvme ... I/O timeout, aborting
task ... blocked for more than ... seconds
Buffer I/O error, blk_update_request errors
Thread de journalisation du système de fichiers bloqué : jbd2 (ext4) ou blocages du log worker (XFS)
Réinitialisations et aborts SCSI (même si vous « n’utilisez pas SCSI » — votre HBA le fait)

Pourquoi Ubuntu 24.04 est pertinent ici

Ubuntu 24.04 tend à être déployé sur des plateformes récentes : NVMe, PCIe Gen4/Gen5, stacks firmware modernes et plus de virtualisation. C’est un bon environnement pour la performance — et aussi pour des cas limites rares où un périphérique, un driver ou une topologie PCIe fait quelque chose « créatif » sous pression.

De plus : beaucoup d’équipes sont passées des SSD SATA (lents, tolérants) au NVMe (rapide, complexe). Le mode de défaillance est passé de « c’est lent » à « ça marche jusqu’à ce que ça ne marche plus du tout ».

Erreurs courantes : symptôme → cause racine → correction

Ce ne sont pas des fautes morales. Ce sont des pièges dans lesquels on tombe quand le système redémarre et que tout le monde veut passer à autre chose.

Mistake 1: “Random reboot” with no logs

Symptôme : l’uptime se réinitialise, les services redémarrent, pas d’erreurs évidentes dans les logs du boot courant.

Cause racine : les logs étaient en RAM (journald volatile) et la réinitialisation a effacé le ring buffer.

Correction : activez journald persistant et/ou la journalisation distante ; confirmez que les logs du boot précédent sont conservés (journalctl -b -1 doit être utile).

Mistake 2: Confusing a hardware watchdog reset with a kernel panic

Symptôme : la machine redémarre brutalement ; on suppose « kernel crashed ».

Cause racine : le watchdog matériel a déclenché ; il n’y a pas eu de panic, donc pas de vmcore et pas de sortie console finale.

Correction : décidez si vous préférez panicer sur lockup/hung task (avec kdump) au lieu de réinitialisations aveugles ; ajustez le timeout du watchdog matériel pour permettre la capture de preuves.

Mistake 3: Treating soft lockup warnings as “just noise”

Symptôme : lignes occasionnelles BUG: soft lockup, le système « semble ok ».

Cause racine : avertissement précoce de deadlocks driver, tempêtes IRQ ou blocages I/O. Le système récupère — jusqu’au jour où il ne récupère plus.

Correction : corrélez avec les timeouts de périphériques et PSI. Si récurrent, reproduisez sous charge et capturez un vmcore en activant panic-on-lockup sur un canari.

Mistake 4: Raising watchdog thresholds to stop reboots

Symptôme : les réinitialisations watchdog cessent après tuning ; plus tard, des gels de plusieurs minutes apparaissent sans récupération automatique.

Cause racine : vous avez désarmé l’alarme au lieu d’éteindre l’incendie.

Correction : revenez sur les seuils ; corrigez la cause racine (timeouts stockage, %steal hôte, bugs driver). Utilisez un watchdog matériel plus long mais conservez la détection.

Mistake 5: Ignoring %steal in VMs

Symptôme : le watchdog invité déclenche « hard lockup » lors d’événements noisy neighbor.

Cause racine : l’invité est mis en pause/affamé par l’hyperviseur ; les timeouts se déclenchent dans l’invité.

Correction : corrigez la planification/capacité de l’hôte ; pincez les vCPU ou ajustez les priorités VM. Si nécessaire, augmentez les seuils dans les invités — mais considérez cela comme un palliatif, pas une cure.

Mistake 6: Blaming the database because it was the first to complain

Symptôme : pics de latence DB et timeouts avant le redémarrage.

Cause racine : la DB est souvent la première à bloquer sur fsync ; le problème réel est le stockage ou le chemin I/O du noyau.

Correction : inspectez les logs noyau pour NVMe/SCSI/erreurs système de fichiers et tâches bloquées ; mesurez la pression I/O et la latence de queue sur les périphériques bloc.

Listes de vérification / plan étape par étape

Étape par étape : se préparer à attraper le prochain blocage

Activez les logs persistants (journald sur disque) et définissez des limites de rétention.
Assurez-vous de pouvoir lire le boot précédent : vérifiez que journalctl -b -1 contient des messages noyau.
Activez et testez kdump dans une fenêtre de maintenance en utilisant SysRq crash ; confirmez qu’un vmcore est écrit.
Décidez de votre stratégie :
- Option A : réinitialisation watchdog pour récupération rapide (moins de preuves)
- Option B : panic-on-lockup + kdump pour preuves (plus de preuves, crash contrôlé)
Instrumentez la pression I/O (PSI) et normalisez-la. Si vous ne savez pas ce qui est normal, vous ne pouvez pas repérer l’anormal.
Collectez les logs hors-bande (BMC SEL, événements watchdog) si possible. Si vous ne pouvez pas, au moins coordonnez-vous avec l’équipe hardware pour savoir comment les récupérer.
Changés canaris : appliquez les mises à jour noyau/firmware à une sous-ensemble ; conservez une procédure de rollback. L’objectif est de changer une variable à la fois.

Checklist d’incident : quand le redémarrage est déjà arrivé

Confirmez la fenêtre du boot précédent : journalctl -b -1 et last -x.
Extraites les 200 dernières lignes noyau du boot précédent ; recherchez lockups, tâches bloquées, réinitialisations de périphériques.
Vérifiez les logs d’erreurs stockage (error-log NVMe, timeouts noyau, erreurs système de fichiers).
Vérifiez les signaux de virtualisation : %steal et contention hôte si applicable.
Vérifiez les versions firmware et noyau pour des changements récents ; corrélez avec le démarrage de l’incident.
Rédigez une hypothèse et un test de réfutation. Évitez la réunion des « vingt hypothèses ».

Checklist de contrôle des changements : ajuster les réglages watchdog

N’ajustez pas les timeouts avant de confirmer si vous avez affaire à des lockups CPU, des blocages I/O ou de la famine d’invité.
Si vous activez panic-on-lockup, assurez-vous que kdump est fonctionnel et que le stockage des dumps est fiable.
Gardez les timeouts watchdog confortablement au-dessus des pires pauses connues (basculement de contrôleur, lecture RAID patrol, compaction lourde).
Documentez la raison. Le vous du futur ne se souviendra pas pourquoi RuntimeWatchdogSec=73s semblait une bonne idée.

FAQ

1) Quelle est la différence entre un soft lockup et un hard lockup ?

Un soft lockup survient lorsqu’un CPU exécute du code noyau trop longtemps sans planification ; le noyau peut encore enregistrer des avertissements. Un hard lockup survient lorsque le CPU cesse de répondre aux interruptions ; la détection est plus difficile et implique souvent des NMI ou des sources de temps.

2) Pourquoi les réinitialisations watchdog semblent « aléatoires » ?

Parce que la condition déclenchante est généralement la queue d’une distribution : timeouts de stockage rares, deadlocks driver rares, ou contention hôte rare. La réinitialisation se produit après un timeout, pas au moment où le système a commencé à mal fonctionner.

3) Dois-je désactiver les watchdogs pour arrêter les redémarrages ?

Seulement si vous aimez les gels de plusieurs heures qui nécessitent des coupures manuelles d’alimentation. Conservez les watchdogs. À la place, augmentez la capture de preuves (journald persistant, kdump) et corrigez les pauses sous-jacentes.

4) Si j’active panic-on-lockup, est-ce que ça va réduire la disponibilité ?

Ça peut, à court terme, parce que ça convertit « peut-être récupère » en « ça plante ». En échange, vous obtenez un vmcore et pouvez corriger la cause racine. Pour des blocages récurrents en production, ce compromis paye généralement.

5) Est-ce que le stockage peut vraiment provoquer des messages de lockup CPU ?

Oui. Les pauses I/O peuvent bloquer des threads noyau critiques, déclencher des tempêtes de reclaim et créer des contentions de locks. Le watchdog indique où le CPU s’est bloqué, pas forcément ce qui a démarré la cascade.

6) Comment savoir si ma VM est affamée par l’hyperviseur ?

Regardez mpstat et la colonne %steal. Un steal élevé indique que l’invité voulait du CPU mais n’a pas été planifié. Cela peut faire déclencher des timeouts même si l’invité est « sain ».

7) Pourquoi je n’ai pas eu de dump de crash ?

Parce qu’une réinitialisation watchdog n’est pas un panic, et kdump se déclenche sur les panics. Aussi, kdump échoue si crashkernel n’est pas réservé ou est trop petit, ou si la cible de dump n’est pas disponible pendant le crash.

8) Quelle est la manière la plus rapide de trouver les logs les plus pertinents après un reboot ?

Utilisez journalctl -b -1 -k et filtrez pour lockups, tâches bloquées et erreurs de périphériques. Puis corrélez les horodatages avec les alertes applicatives. Si les logs ne sont pas persistants, corrigez cela d’abord.

9) Le watchdog de systemd est-il le même que le watchdog noyau ?

Non. Le watchdog systemd alimente un périphérique watchdog (souvent matériel). Les watchdogs noyau détectent des lockups liés au scheduling/interrupt du noyau. Ils peuvent interagir, mais ce sont des mécanismes différents avec des modes d’échec différents.

10) Que faire si la machine se réinitialise si brutalement que même journald ne flush pas ?

Alors vous avez besoin de redondance : journalisation distante, logs hors-bande, et/ou une stratégie de panic qui écrit un vmcore via kdump. Si le chemin disque est ce qui bloque, les logs locaux sont intrinsèquement fragiles.

Conclusion : prochaines étapes qui réduisent vraiment le downtime

Si vous ne faites rien d’autre cette semaine, faites ces trois choses :

Rendez fiables les logs du boot précédent : journald persistant, rétention configurée, et confirmez que journalctl -b -1 est utile.
Obtenez une voie de dump fonctionnelle : activez et testez kdump. Un seul vmcore peut vous faire économiser des mois de spéculation.
Choisissez une position sur le comportement du watchdog : redémarrage rapide pour la disponibilité, ou panic-on-lockup pour les preuves. N’évoluez pas vers un état à moitié configuré qui ne vous donne ni l’un ni l’autre.

Puis attaquez-vous aux causes racines en privilégiant les suspects habituels : timeouts stockage, erreurs PCIe, %steal VM, et interactions driver/firmware. Les watchdogs ne créent pas le blocage. Ils refusent juste de le laisser voler tranquillement votre disponibilité.