Utiliser un Watchdog (chien de garde)

Une machine qui plante celà n'arrive pas qu'aux autres et malheureusement, Lois de Murphy obligent, le problème se produira lorsque vous serez à des dizaines ou des centaines de kilomètres de votre ordinateur et que personne ne sera chez vous pour appuyer sur le bouton Reset. Même si un plantage est rare sous GNU/Linux il n'en reste pas moins qu'il est n'est pas impossible. Bref, l'idéal serait qu'un dispositif surveille pour vous automatiquement l'état du système et provoque une remise à zéro en cas de problème... C'est là précisément le but d'un watchdog (littéralement chien de garde).

L'idée du chien de garde consiste en un dispositif (matériel ou purement logiciel) doté d'une temporisation. Si sa temporisation (timer) n'est pas remise à zéro avant l'atteinte d'un certain délai, le chien de garde provoque le redémarrage immédiat de la machine.

Il est à noter qu'il ne s'agit pas d'un redémarrage « propre » du système avec envoi d'un SIGTERM/SIGKILL à chaque processus mais plutôt un redémarrage sauvage du même style que celui qui se produit lorsque vous appuyez sur le bouton Reset de la machine. Ses conséquences peuvent être  :

• Pertes de travaux en cours non enregistrés sur une mémoire de masse
• Perte de données du fait de l'absence de synchronisation des caches système avec les mémoires de masse et ce même si vous utilisez des systèmes de fichiers journalisés (le risque sera cependant amoindri dans ce cas).

Attention !
Attention à vos volumes tmpfs ! Leur contenu sera irrémédiablement perdu si une sauvegarde n'est pas effectuée.

Il y a deux approches possibles pour l'implémentation d'un chien de garde

• Une approche logicielle : le chien de garde est dans ce cas un simple processus situé soit en espace noyau (c'est le cas sous Linux), soit en espace utilisateur et son temporisateur prend la forme d'un compteur qui se trouve lui en mémoire centrale. Le compteur est incrémenté (ou décrémenté selon le sens du comptage utilisé) par le biais un processus reveillé à intervalles de temps réguliers (toutes les 10 millisecondes en moyenne par exemple). Si cette solution l'avantange de ne pas nécessiter de matériel additionnel elle a comme principal inconvénient de ne pas être d'une fiabilité à toute épreuve car si le système est instable ou planté il y a de bonnes chances que le le processus du chien de garde le soit aussi.

• Une approche matérielle : le chien de garde est un dispositif électronique autonome (carte PCI, chipset de la carte-mère, carte électronique externe). Son temporisateur peut prendre plusieurs formes comme par exemple un compteur numérique situé dans un registre dans du microcontrôleur du chien de garde ou un simple système analogique résistance-condensateur. Ce type de chien de garde peut provoquer le redémarrage de la machine de plusieurs manières :

• • Provoquer une NMI (Non-Maskable Interrupt) qui sera immédiatement traitée
  • Activer une broche du CPU qui provoque la remise à zéro immédiate de ce dernier
  • Couper brièvement l'alimentation électrique de la machine
  • etc.

Les avantages de l'approche matérielle sur l'approche logicielle sont évidents : le chien de garde est totalement indépendant du CPU (et du système d'exploitation) et reste par conséquent fonctionnel en cas de plantage de la machine. Si jusqu'à une époque récente cette solution exigeait l'installation d'une carte d'extension spécialisée dans la machine, certains manufacturiers comme Intel ou Winbond intègrent de nos jours un chien de garde matériel dans certains de leurs chipsets qui sont fréquemment utilisés sur les cartes mères PC actuelles :

• Winbond : chipsets de la série 83627
• Intel : chipsets série 63xxESB et série 82801 (également plus connue sous le nom d' Intel ICH).  ! Le chien de garde intégré aux chipsets iTCO ou TCO (TCO tout simplement pour Total Cost of Ownership, en référence au temps d'utilisation d'une machine).

TODO: glisser un schéma fonctionnel du 82801 avec les histoires d'horloge PCI, d'assertions aux broches CPU, parler de la double expiration, etc.

Information !
iTCO est totalement interne au chipset ICH/63xxESB, vous ne le verrez nullement apparaître si vous utilisez la commande lspci.

La mise en oeuvre d'un chien de garde sous GNU/Linux repose sur deux composantes:

• Une partie noyau qui prendra en charge l'aspect matériel (ou son pendant purement logiciel) du chien de garde et en fournira l'abstraction au travers d'un pseudo-fichier orienté caractères se nommant watchdog situé dans le répertoire /dev;

• Une partie en espace utilisateur (userland) qui prend la forme d'un démon (processus d'arrière plan) dont le but va être de réinitialiser périodiquement le temporisateur du chien de garde par l'intermédiaire du pseudo-fichier /dev/watchdog;

A moins que votre noyau n'incorpore déjà le support du support du chien de garde iTCO et du congélateur de processus (control groups), vous allez devoir ajouter ces deux options. Pour ce faire rendez-vous dans le répertoire /usr/src/linux, faites un make menuconfig (ou ce que vous préférez) et activez :

• WDT iTCO (situé dans Device drivers / Watchdog timer support)
• Le sous-système Freezer dans les control group (situé dans General Setup / Control Group support). Ce sous système est présent dans tous les noyaux Linux à partir du 2.6.29.

Information !

• Le support des control group n'est pas requis pour utiliser un chien de garde en temps normal. Il ne nous servira qu'à simuler le plantage de la machine (gel du processus qui remettra à zéro la temporisation du chien de garde).
• L'illustration montre que plus d'un sous-système a été activé dans les control groups, ils ne constituent en aucune manière des dépendances reliées au sous-système congélateur et vous n'avez nullement obligation de les activer.

Au besoin, recompilez ensuite votre noyau et/ou ses modules et si vous devez redémarrez la machine n'oubliez pas d'ajouter votre nouveau noyau à la liste de ceux connus de votre chargeur favori. Si vous avez mis le chien de garde en module, assurez-vous que les dépendances de vos modules soient à jour au moyen de :

# depmod -a

Une fois le redémarrage de la machine effectué ou le module (iTCO_wdt) chargé au moyen de la commande modprobe, vous devriez avoir une trace dans votre journal système qui ressemble à ceci:

# dmesg | grep TCO
[ 0.791882] pci 0000:00:1f.0: quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
[ 43.090218] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.05
[ 43.090354] iTCO_wdt: Found a ICH10R TCO device (Version=2, TCOBASE=0x0860)
[ 43.090390] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

Notez d'ailleurs qu'à ce stade vous le pseudo-fichier orienté caractère se nommant watchdog (majeur 10, mineur 130) devrait exister dans votre répertoire /dev:

# ls -l /dev/watchdog
crw-rw---- 1 root root 10, 130 2009-08-13 03:05 /dev/watchdog

C'est tout pour la partie noyau ! Il ne reste plus qu'à nous occupper du démon en espace utilisateur qui aura pour tâche de remettre à zéro de temporisateur du chien de garde.

Le démon sys-apps/watchdog va ouvrir le pseudo-fichier /dev/watchdog et y effectuer périodiquement une opération d'écriture réguliers afin de remettre à zéro le temporisateur du chien de garde. Notez que les opérations d'écriture de sys-apps/watchdog sont conditionnelles à par exemple :

• Un délai temporel (ex. toutes les 3 secondes, inutile de préciser que ce délai doit être inférieur à celui du temporisateur....)
• Un niveau maximal de charge système
• La réponse d'une machine sur le réseau (ping)

Information !
Le sursis au redémarrage de votre machine débute à la première opération d'écriture dans /dev/watchdog et ne se termine que lorsque /dev/watchdog est poprement fermé (ce qui a pour effet de désactiver le chien de garde). Tuer le démon watchdog par le biais d'un etc/init.d/watchdog stop ou de la commande/appel système kill engendre une fermeture propre de /dev/watchdog.

Pour commencer, emergez le paquetage sys-apps/watchdog :

# emerge sys-apps/watchdog

Si désiré, vous pouvez ajouter sys-apps/watchdog aux services démarrés automatiquement par :

# rc-update add watchdog default

Attention !
sys-apps/watchdog ne fera absolument rien avec la configuration par défaut et votre machine ne redémarrera pas en cas de plantage. Il est absolument nécessaire de modifier le fichier /etc/watchdog.conf préalablement au lancement du démon.

Pour nos besoins dans ce cadre de cet article, nous allons simplement décommenter la ligne watchdog-device (se référer à la page de manuel de watchdog.conf pour plus de détails) ce qui aura pour effet de demander au démon d'écrire dans le pseudo-fichier /dev/watchdog toutes les 10 secondes (valeur par défaut du paramètre interval).

...
 
#test-timeout		= 
 
watchdog-device	= /dev/watchdog
 
# Defaults compiled into the binary
#temperature-device	=
 
...

Ceci fait, enregistrez vos changements et lancez le démon par :

# /etc/init.d/watchdog start

A ce stade sys-apps/watchdog devrait être lancé et ouvrir le pseudo-fichier /dev/watchdog. Ouverture que l'on peut vérifier par le biais de la commande lsof :

# lsof | grep watchdog
...
watchdog 5509 root 1w CHR 10,130 0t0 3000 /dev/watchdog
...

Il ne reste plus qu'à vérifier le bon fonctionnement de l'ensemble en simulant un plantage système :-)

Vérification du bon fonctionnement

Pour simuler le plantage, nous allons tout simplement nous servir du congélateur de processus (Freezer) pour geler le démon sys-apps/watchdog (souvenez-vous que si ce démon est tué même brutalement, le pseudo-fichier est fermé et le chien de garde désactivé). Commençons par créer un point de montage puis montons-y le pseudo système de fichiers de type cgroup (notez l'option freezer qui suit le -o) qui nous permettra d'utiliser le congélateur :

# mkdir -p /containers/freezer
# mount -o freezer -t cgroup freezer /containers/freezer
# mount
...
freezer on /containers/freezer type cgroup (rw,freezer)

Puis on va créer une instance du congélateur :

# mkdir -p /containers/freezer/0

Notez que plusieurs fichiers virtuels sont « automagiquement » créés dans /containers/freezer/0 :

# ls -l
total 0
-rw-r--r-- 1 root root 0 Apr 8 10:42 freezer.state
-rw-r--r-- 1 root root 0 Apr 8 10:42 notify_on_release
-rw-r--r-- 1 root root 0 Apr 8 10:42 tasks

• tasks : contient la liste des PID des processus à congeler (l'ensemble des processus figurant dans cette liste forme un groupe de processus).
• freezer.state :
  • La lecture de ce fichier rapporte l'état de la congélation du groupe de processus inscrit dans le fichier tasks. Trois valeurs sont possibles :
    • RUNNING : le groupe de processus peut être ordonnancé pour utiliser le CPU,
    • FREEZING : La congélation est en cours
    • FROZEN : L'ensemble des processus du groupe se trouve à l'état de sommeil inninterruptible et aucun ne sera éligible par l'ordonnanceur pour utiliser le CPU.
  • L'écriture de FROZEN dans ce fichier commande la « congélation » du groupe de processus (les processus passent à l'état de sommeil inninterruptible) et celle de THAWED en commande le « réchauffage ».

Attention !
Enregistrez tous vos travaux en cours et synchronisez votre cache disque (commande sync). Assurez-vous que la machine est relativement inactive et idéalement passez en single user mode (commande init s).

Il ne nous reste plus qu'à congeler le démon sys-apps/watchdog :

# echo `pidof watchdog` > /containers/freezer/0/tasks
# echo FROZEN > /containers/freezer/0/freezer.state

Ceci fait il ne nous reste plus qu'à vérifier l'état du démon :

# ps x | grep watchdog
15348 pts/1 D 0:00 watchdog

Tout est pour le mieux dans le meilleur des mondes possible, ps nous indique un 'D' signifant que le démon sys-apps/watchdog est à présent plongé dans un sommeil inninteruptible. Une fois le démon endormi, la machine devrait redémarrer dans les 60 prochaines secondes !