Utiliser le watchdog du SheevaPlug

Le watchdog est un mécanisme qui permet d'effectuer des actions précises en cas de défaillance du système. Le comportement par défaut est de simplement redémarrer la machine quand un problème est constaté, mais on peut aussi exécuter des scripts, afin de tenter des réparations automatiques, avant de redémarrer la machine en dernier recours.

Un watchdog matériel est présent dans le SheevaPlug. C'est un composant dont le fonctionnement est simple : S'il ne reçoit aucune éciture pendant un temps déterminé, il redémarre électriquement la machine. Ainsi, même lorsque le système est complètement bloqué, le redémarrage est assuré, ce qui est bien utile pour une machine à distance.

Installation¶

Sous Debian, il suffit d'installer le paquet watchdog.

$ sudo apt-get install --no-install-recommends watchdog

Configuration¶

La configuration se trouve dans deux fichiers.

Le premier, /etc/default/watchdog, permet d'activer le watchdog, définir le module du noyau si la machine a un watchdog matériel, et éventuellement définir des pramètres de lancement pour le démon.

# Start watchdog at boot time? 0 or 1
run_watchdog=1
# Load module before starting watchdog
watchdog_module="orion_wdt"
# Specify additional watchdog options here (see manpage).
#watchdog_options="-v -q"

Note : La variable watchdog_options définie ici est idéale pour tester la configuration, mais ne doit pas être utilisée ensuite. Le paramètre -v augmente la verbosité des logs, et le paramètre -q désactive toutes les actions. Il est ainsi possible de simuler des pannes en observant les actions qu'auraient effectué le watchdog, sans que la machine ne redémarre réellement.

Le second fichier de configuration est /etc/watchdog.conf. Il permet de définir le comportement du watchdog : éléments surveillés et actions effectuées en cas de détection d'erreur.

Dans ce fichier, j'utilise ces paramètres :

• min-memory = 1 : Vérifie qu'il reste au moins une page de mémoire disponible.
• pidfile = /var/run/rsyslogd.pid : Définit le fichier pid d'un processus à tester, en testant l'existence du fichier, et en effectuant un ping sur le pid contenu dans le fichier. On peut déclarer plusieurs fois ce paramètre pour tester l'exécution de plusieurs programmes.
• watchdog-device = /dev/watchdog : Définit le nom du périphérique sur lequel écrire pour signaler à la partie matérielle que le système fonctionne toujours.
• interval = 10 : Certaines options ont un timeout supérieur à une seconde (qui est l'intervalle de test par défaut), et tester toutes les 10 secondes me parait suffisant, puisque que le watchdog matériel attend 60 secondes avant de redémarrer la machine.
• realtime = yes et priority = 1 : Permet de s'assurer que le watchdog sera bien exécuté sans être retardé par des processus gourmands.

J'ai aussi testé quelques autres paramètres, mais sans succès :

• ping = 192.168.2.1 : Ce paramètre semble avoir un timeout d'environ 3 secondes sur ma machine, et nécessite donc de mettre au minimum 4 secondes pour le paramètre interval décrit ci-dessus. Il effectue un ping sur l'IP donnée pour vérifier que l'hôte répond. Le ping sur les interfaces du plug lui-même répond toujours, même quand le câble est débranché et après un ifdown. Je n'ai eu des états d'erreur qu'en mettant l'IP de ma livebox et en débranchant le câble. On peut déclarer plusieurs fois ce paramètre pour tester plusieurs machines.

  Note : Je pense que ce paramètre s'utilise en conjonction avec le paramètre repair-binary (par exemple, le script repair.sh dispo dans les exemples du paquet).

• interface = eth0 : Vérifie que l'interface spécifiée reçoit régulièrement des données. Si tout fonctionne, mais qu'aucune machine ne communique par cette interface, ce sera considéré comme une erreur. On peut déclarer plusieurs fois ce paramètre pour tester le traffic de plusieurs interfaces.

Et enfin, les paramètres que je n'ai pas testés :

• Le paramètre admin permet de donner une adresse email afin de recevoir des emails d'alerte en cas de problème détecté.
• Le paramètre test-binary permet d'exécuter un script de test personnalisé.
• Le paramètre test-timeout donne le temps d'exécution maximum autorisé pour le test-binary. Je suppose que si ce temps est dépassé, le test échoue et le système est considéré comme défaillant.
• Le paramètre repair-binary permet d'exécuter un script personnalisé lors de la détection d'une erreur, pour tenter des réparations automatiques au lieu de se contenter de redémarrer la machine.
• Le paramètre repair-timeout donne le temps d'exécution maximum autorisé pour le repair-binary. Tout comme pour test-timeout, je suppose qu'il provoque une erreur s'il est atteint.
• Les paramètres max-load-1, max-load-5, max-load-15 permettent de vérifier la charge du système (load average). Au vu de la charge actuelle de mon Sheeva (proche de 0), j'ai choisi de ne pas les activer.
• Je n'ai pas non plus activé les vérifications de température, puisque que mon Sheeva ne chauffe pas du tout.
• Le paramètre watchdog-timeout est prévu pour définir le timeout de la partie matérielle. Il ne semble pas fonctionner sur mon système. J'obtiens l'erreur cannot set timeout XXX (errno = 22 = 'Invalid argument'), où XXX est la valeur que j'ai donnée. La valeur par défaut est 60, et j'ai la même erreur si je ne définis pas cette option.