Aller au contenu principal

Watchdog

Le watchdog est le mecanisme de surete qui redemarre automatiquement le node si la boucle de controle se bloque. Dans leukOS, il est pilote par le daemon C++ via /dev/watchdog.

Comment ca fonctionne​

  1. Au demarrage, le daemon ouvre /dev/watchdog et configure un timeout (15 s par defaut).
  2. Tant que la boucle principale tourne, le daemon envoie periodiquement un signal de rearmement (feed).
  3. Si la boucle se fige (deadlock, blocage I/O, panic user-space), le rearmement s'arrete.
  4. A l'expiration du timeout, le watchdog materiel force un reboot de la machine.

Exemples rapides​

Exemple 1: fonctionnement nominal​

  • poll_interval_ms = 250
  • watchdog.timeout_s = 15
  • Le daemon rearmant en continu, aucun reboot n'est declenche.

Exemple 2: blocage de la boucle​

  • Un thread critique bloque la boucle principale plus de 15 secondes.
  • Le feed ne passe plus.
  • Le watchdog expire et redemarre automatiquement le node.

Exemple 3: arret maitrise​

  • Lors d'un SIGTERM/shutdown normal, le daemon execute stop().
  • Le watchdog est desarme/ferme proprement pour eviter un reboot parasite.

Integration dans l'OS leukOS​

Le watchdog n'est pas un service SysV separe. Il est integre dans le cycle de vie du daemon S90leukos-node:

  1. Init BusyBox lance S90leukos-node.
  2. Le daemon initialise ses modules, dont Watchdog.
  3. La boucle de controle appelle watchdog.feed() a chaque cycle.
  4. En cas de blocage, le materiel reprend la main.

Cela garantit que la protection couvre la logique metier reelle (relais, vannes, compteurs, scheduler), pas seulement l'existence d'un process.

Configuration​

Dans /etc/leukos/node.json:

{
  "watchdog": {
    "enabled": true,
    "timeout_s": 15
  }
}
  • enabled: active/desactive le mecanisme.
  • timeout_s: delai max sans feed avant reboot.

Cas de figure geres dans l'OS​

  • Blocage de la boucle principale du daemon.
  • Deadlock applicatif empechant l'avancement du controle.
  • Blocage long sur une ressource critique qui stoppe le cycle.
  • Degradation temporaire reseau/MQTT: pas de reboot tant que la boucle tourne.

Cas non geres directement:

  • Corruption materielle lourde (alim instable, RAM defectueuse).
  • Kernel panic immediate avant reprise du daemon.
  • Boucle applicative vivante mais logique metier incorrecte (le watchdog ne valide pas la justesse fonctionnelle, seulement la vivacite).

Bonnes pratiques​

  • Garder timeout_s plus grand que le pire temps d'un cycle normal.
  • Eviter les operations bloquantes non bornees dans la boucle principale.
  • Utiliser des timeouts reseau/serie explicites.
  • Surveiller les reboots repetes via logs/heartbeat pour distinguer un crash reel d'un faux positif de timeout.