Utiliser le watchdog du SheevaPlug
mar. 17 sept. 2013 by MarmotteLe 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
etpriority = 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ètreinterval
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 unifdown
. 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 letest-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 lerepair-binary
. Tout comme pourtest-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'erreurcannot 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.