Installation d'un watchdog sur RPI pour relancer le système automatiquement en cas d'erreur 500 ou de freeze du système

bernard.dandrea · Juin 15, 2026, 4:07

Sur mon installation Jeedom, il arrive parfois que Jeedom se mette en erreur et renvoie un code 500 à toutes les requêtes http qui lui sont adressées. Cela se produit de façon tout à fait aléatoire, parfois après quelques jours, parfois après plusieurs semaines. Je soupconne un problème hardware mais n’ai pas vraiment d’éléments pour en déterminer l’origine car après plantage, le système ne répond plus au ssh.

Pour gérer une relance automatique du RPI dans cette situation (ou en cas de freeze du système), j’ai mis en oeuvre le package watchdog disponible sur les systèmes Linux. Dans mon cas, la procédure fonctionne parfaitement et Jeedom est relancé proprement et sans intervention humaine lorsque le problème se produit.

Afin d’en faire profiter la communauté, je décris ci-dessous la procédure d’installation. Celle-ci a été testée sur Debian 11 et 12. Elle doit s’appliquer à peu près de la même façon sur l’ensemble des systèmes de type Linux étant donné que le package watchdog est largement répandu.

Les instructions ci-dessous nécessitent une connexion ssh sur le système Jeedom.

Activer le watchdog matériel

Editer le fichier de configuration du RPI : sudo nano /boot/config.txt ( en debian 12, /boot/firmware/config.txt)
Ajouter à la fin après [all] la ligne suivante : dtparam=watchdog=on

Relancer le RPI : sudo reboot

Installer le service watchdog

Lancer l’installation du service : sudo apt install watchdog -y

Copier le script check_jeedom.sh dans /home/pi

Le script check_jeedom.sh va se lancer toutes les minutes et vérifier que Jeedom ne renvoie pas un code 500 à une requête http basique. Après 5 échecs, le script renvoie un code erreur différent de zéro ce qui va provoquer un reboot du système par le service watchdog. Les différentes tentatives de connexion sont loggées dans la log jeedom pi_watchdog.

Créer le fichier check_jeedom.sh dans le répertoire home de pi: sudo nano /home/pi/check_jeedom.sh

check_jeedom.sh.txt (3,4 Ko)

Copier le code du fichier ci-dessus après l’avoir adapté si nécessaire à votre configuration. Sauvegarder et quitter.

Rendre le fichier executable avec la commande : sudo chmod +x /home/pi/check_jeedom.sh

Vérifier que le fichier est bien exécutable avec la commande : file /home/pi/check_jeedom.sh

Si on n’a pas le résultat ci-dessus, c’est probablement parce que le fichier a été modifié dans un éditeur Windows.

Dans ce cas, le rendre compatatible avec unix avec la commande :

si nécessaire, installer le package dos2unix avec la commande sudo apt update && sudo apt install dos2unix -y
modifier le script: sudo dos2unix check_jeedom.sh
Exécuter le fichier et vérifier qu’aucune erreur n’est affichée : sudo /home/pi/check_jeedom.sh

Configurer le service watchdog

Avant de faire la configuration ci-dessous, il faut s’être assuré que les contrôles du point précédent ont bien été effectués sinon il est possible que le système redémarre toutes les 5 minutes.

Modifier le fichier de configuration de watchdog : sudo nano /etc/watchdog.conf

Décommenter et modifier les lignes :

watchdog-device = /dev/watchdog

watchdog-timeout = 15

Laisser les lignes :

realtime = yes

priority = 1

Ajouter dans la section « User-specified tests » les lignes :

test-binary = /home/pi/check_jeedom.sh

test-timeout = 30

Sauvegarder le fichier.

Pour rendre effecitves les mises à jour, relancer le service watchdog avec la commande : sudo systemctl restart watchdog

Vérifier que tout se passe bien

Message toutes les minutes dans la log pi_watchdog de jeedom
Pas de rédémarrage intempestif

Par défaut, le service se lance au démarrage. On peut désactiver le lancement automatique du service watchdog avec la commande : sudo systemctl disable watchdog

Commandes pour gérer le service watchdog

Vérifier l’état du service : sudo systemctl status watchdog

Arréter le service : sudo systemctl stop watchdog

Démarrer le service : sudo systemctl start watchdog

Supprimer le package watchdog et les fichiers de configuration: sudo apt purge watchdog

micheld · Juin 16, 2026, 12:54

Bonjour @bernard.dandrea,

Et merci pour ce partage qui pourrait aider certains utilisateurs novices comme moi d’éviter de couper électriquement le RPI pour relancer Jeedom

Perso, j’ai un RPI4B. N’étant pas développeur, je me demandais ce qu’il fallait comprendre dans l**’adaptation à sa configuration** ?

Avec des LOG toutes les minutes, le fichier « /var/www/html/log/pi_watchdog » va vite avoir une taille importante.

Je me demandais s’il était possible de le réduire :

avec uniquement les logs indiquant l’erreur 500 :
- Ne sachant pas s’il y a eu une relance automatique, il faudrait faire une vérification manuelle et régulière de sa taille (avec sa suppression pour repartir à ‘zéro’ par exemple)
et faire qu’il ne dépasse pas un certain nombre de lignes (comme pour les logs de Jeedom, avec les 1eres lignes qui se suppriment au profit des nouvelles) ?
- Si Jeedom est automatiquement relancé par ton script, il n’y aurait plus besoin de faire de vérification, ou uniquement pour voir s’il y a eu une relance à un moment donné.

Qu’en penses-tu (la seconde possibilité parait plus compliquée ) ?

Merci @bernard.dandrea

bernard.dandrea · Juin 16, 2026, 4:01

Bonjour Michel

Par adapter à sa configuration, je veux dire vérifier si le script correspond à son environnement et à ses besoins, par exemple pour l’emplacement du fichier log ou les informations loggées. Le script fourni fonctionne avec le raspberry 4 et 5 sous Debian 11 et 12. Pour un autre système, le script doit être testé et il faut s’assurer qu’il n’y a pas de problème de fonctionnement.

Le fichier pi_watchdog est situé dans l’emplacement des fichiers log de Jeedom. Il va donc être traité comme tous les fichiers logs de Jeedom et être limité dans sa taille ou son nombre de lignes selon ce qui est défini dans la configuration Jeedom.

jlb · Juin 17, 2026, 10:08

Bonjour @bernard.dandrea

Pour compléter ta solution watchdog…

Sur mon RPI 4B et SSD Transcend TS32GMTS400 au format M.2 SATA dans un boitier NVMe & SATA.

J’ai eu le même problème, RPI qui plante aléatoirement, tous les mois ou 2 mois parfois même 2 fois dans la semaine.

Et bien sur impossible de se connecter en SSH.

Comme toi j’avais activé le watchdog matériel mais cela n’a pas résolu le problème.

C’est Gemini qui a analysé et apporté la solution et depuis plus aucun plantage.

Voici les recommandation de Gemini :

Certains boîtiers SSD USB 3.0 gèrent mal le protocole UAS avec le noyau Linux du Raspberry Pi.

Le symptôme : Le système fonctionne parfaitement, puis subitement, lors d’une écriture, le contrôleur du boîtier ne répond plus. Le Pi attend une réponse qui ne vient jamais et finit par « freezer ».
Solution : Il faut forcer le mode « USB Storage » (plus lent mais ultra-stable) pour ce boîtier spécifique.

Votre système est passé en mode « Read-Only » (Lecture seule). Linux fait cela pour protéger vos données : dès qu’il détecte que le SSD a un comportement erratique via le protocole UAS, il « verrouille » le disque pour éviter d’écrire n’importe quoi et de tout casser.

La cause racine : Le conflit UAS

Le Raspberry Pi 4 essaie de parler à votre boîtier SSD « trop vite » et avec des commandes trop complexes (UAS). Votre boîtier SSD (probablement à cause de sa puce double protocole) finit par saturer et se figer.

Vérifier le protocole (UAS ou Storage)

Tapez la commande suivante : lsusb -t

Si vous voyez driver=uas : Le SSD utilise le protocole rapide. C’est performant, mais c’est souvent la cause des plantages sur Pi 4 avec certains boîtiers SATA/NVMe.
Si vous voyez driver=usb-storage : Le système utilise le mode compatible, plus lent mais beaucoup plus stable.

Pourquoi ça plante ?

Le driver uas gère les transferts de données par « files d’attente ». Si le boîtier SSD a une micro-faiblesse ou si le contrôleur USB reçoit un parasite du RFXcom (qui est sur le même contrôleur racine xhci_hcd), le driver uas peut rester bloqué indéfiniment en attendant une réponse du SSD. C’est le freeze total.

Ma recommandation pour une stabilité 100% :

Puisque votre Jeedom a planté 2 fois en 2 mois malgré un SSD neuf, je vous conseille de désactiver l’UAS pour ce boîtier. Vous ne verrez aucune différence de vitesse sur Jeedom, mais les plantages s’arrêteront.

Étape 1 : Récupérer l’ID du boîtier

Tapez simplement lsusb (sans le -t). Vous verrez une ligne pour votre SSD type : Bus 002 Device 002: ID XXXX:YYYY ... Notez les 8 caractères XXXX:YYYY.

Étape 2 : Appliquer le « Quirk » (le correctif)

Éditez le fichier de démarrage : sudo nano /boot/cmdline.txt (Tout doit rester sur une seule et unique ligne dans ce fichier !)
Ajoutez au tout début de la ligne (avant console=...) : usb-storage.quirks=XXXX:YYYY:u (Remplacez XXXX:YYYY par l’ID noté à l’étape 1. N’oubliez pas le :u à la fin).
Sauvegardez (Ctrl+O, Entrée) et quittez (Ctrl+X).

Étape 3 : Redémarrer

sudo reboot

Après le redémarrage, si vous refaites lsusb -t, vous devriez voir Driver=usb-storage à la place de uas.

Conclusion de votre dépannage

Avec ces actions, votre Jeedom est maintenant « blindé » :

Le Watchdog redémarrera le Pi s’il fige encore (sécurité logicielle).
Le mode usb-storage évitera les bugs de communication avec le boîtier SSD (sécurité protocole).

micheld · Juin 18, 2026, 1:07

Bonjour @jlb,

J’ai suivi tes explications et modification à faire. Mais mon RPI 4B sous debian 12 n’a plus voulu redémarrer au reboot

Je suis reparti avec un disque de sauvegarde et les conseils de chatgpt pour m’indiquer comment accéder au fichier cmdline.txt sous sdb (second disque à monter) pour retirer la ligne ajouter avant console dans cmdline.txt.

Comme tu indiques sudo nano /boot/cmdline.txtpour modifier ce fichier, je me demandais si ce complément au watchdog fonctionne sous debian 12, car ce fichier est sous un autre répertoire ( sudo nano /boot/firmware/cmdline.txt) ?

PS: je viens de relire :

Est-ce que cela veut dire qu’au final, on doit avoir:

usb-storage.quirks=abcd:1234:u(valeurs pour exemple)
console…

OU

usb-storage.quirks=abcd:1234:u console...

Perso, j’avais compris le 1er choix avec l’ajout sur 1 ligne. Mais peut être que c’est le second avec un espace entre :u et console, voire autre chose

Merci de ta réponse

bernard.dandrea · Juin 18, 2026, 4:06

Merci @jlb pour ton retour

Effectivement, c’est une piste intéressante

Je ne vais pas pouvoir tester étant donné que je viens de passer sour RPI5 avec un disque nmve: le système est beaucoup plus rapide et je n’ai pas encore assez d’expérience pour juger de la fiabilité mais je suis cependant assez confiant

J’étais précédemment sour RPI4 avec un disque externe en USB3.

Concernant le watchdog du RPI, celui-ci s’est déclenché à bon escient à chaque fois que Jeedom renvoyait des erreurs 500 de façon systématique.

A mon avis, le redémarrage était provoqué par le script que j’ai fourni qui demande un reboot après 5 erreurs 500 consécutives. Il est bien possible que le disque soit alors en mode lecture seule puisque je ne récupére aucune log.

Dans ton cas, si tu as la configuration par défaut, le watchdog du RPI va relancer la machine seulement si la CPU ne répond plus, ce qui n’est pas le cas puisque le système est accessible. C’est peut-être la raison pour laquelle le watchdog du RPI ne s’est pas déclenché.

micheld · Juin 18, 2026, 7:44

Bonsoir,

En fait j’ai trouvé la réponse : c’est le choix 2 avec usb-storage.quirks=abcd:1234:u console...

Mais je me pose la question suivante:

Aujourd’hui, pour garder l’image du SSD actif à une date donnée, je le clone sur un autre qui n’est pas forcément de la même marque et avec des caractéristiques différentes.

De ce que je lis sur internet, le Vendor IDentifier (VID) est un identifiant unique permettant d’identifier le fournisseur et le Product IDentifier (PID) est un identifiant unique permettant d’identifier la famille ou le groupe de produits.

Ainsi, si j’utilise le disque cloné (de marque différente et/ou caractéristiques différentes), que va-t-il se passer (boot impossible..) ?

Merci de votre expertise

jlb · Juin 18, 2026, 9:31

Bonsoir @micheld

J’avais préparer une copie de mon fichier cmdline.txt

Perso pour cloner j’utilise le même equipement pour mes 2 SSD (même taille, même boitier).

Pour tes questions j’ai demandé à Gemini et voici ses réponses :

Première question :

Sous debian 12, c’est la meme chose pour le fichier sudo nano /boot/cmdline.txt ?

C’est une excellente question, et la réponse est oui et non : le contenu à modifier est exactement le même, mais l’emplacement du fichier a changé sous Debian 12 (Bookworm).

Si vous passez votre Raspberry Pi 4 sous Debian 12 (Raspberry Pi OS basé sur Bookworm), la fondation a revu l’organisation des dossiers pour mieux isoler le « firmware » de démarrage.

Voici ce qui change concrètement :

1. Le nouvel emplacement

Sous Debian 12, le dossier /boot/ est devenu plus propre et le fichier se trouve désormais ici :
sudo nano /boot/firmware/cmdline.txt

(Si vous tapez l’ancienne commande /boot/cmdline.txt, vous risquez de vous retrouver face à un fichier complètement vide, ou de voir un message d’erreur).

2. Ce qui ne change pas (Le contenu)

La structure de la ligne reste strictement identique. Vous devez faire exactement la même manipulation :
Ajouter usb-storage.quirks=0bda:9210:u au tout début de la ligne, juste avant console=serial0..., et le tout sur une seule et unique ligne.

Résumé pour votre future mise à jour en Debian 12 :

Pour le SSD (Quirks) :
sudo nano /boot/firmware/cmdline.txt
Pour le Watchdog (Étape 1 de la méthode 2) :
sudo nano /boot/firmware/config.txt (au lieu de /boot/config.txt)

Le reste de la procédure (l’installation du service watchdog, la configuration dans /etc/watchdog.conf et la désactivation de wd_keepalive) reste 100% identique.

C’est une très bonne chose d’anticiper cela, car si vous migrez un jour votre Jeedom vers Debian 12 pour des raisons de sécurité ou de compatibilité, vous saurez exactement où appliquer votre « bouclier » contre les plantages !

Deuxième question :

A l’aide de Win32Diskimager. Si je clone mon ssd sur un autre ssd de marque differente et dans un boitier different, le systeme fonctionnera avec le ssd cloné ?

Oui, absolument ! Le système fonctionnera parfaitement sur le nouveau SSD, mais il y a une subtilité très importante à connaître concernant le « Quirk USB » que nous venons de configurer ensemble.

Voici comment cela va se passer techniquement :

1. Pourquoi le clonage avec Win32DiskImager va marcher

Win32DiskImager fait une copie « secteur par secteur » (un clone parfait). Il va copier l’intégralité de votre système (Debian, Jeedom, vos configurations, vos scénarios) ainsi que l’identifiant unique de votre partition (le PARTUUID que l’on a vu dans le fichier cmdline.txt).
Comme le Raspberry Pi cherche le disque grâce à ce PARTUUID, il trouvera le nouveau SSD sans problème, peu importe sa marque.

2. Le piège du « Quirk USB » (Attention !)

Souvenez-vous de la ligne que nous venons d’ajouter : usb-storage.quirks=0bda:9210:u.
Ce code 0bda:9210 correspond uniquement à la puce Realtek de votre boîtier actuel.

Si vous changez de boîtier pour le nouveau SSD :

Cas 1 : Le nouveau boîtier utilise une puce différente (ex: ASMedia, JMicron). Le Raspberry Pi ne reconnaîtra pas le code 0bda:9210. Il va donc essayer d’activer le mode UAS sur le nouveau boîtier. Si ce nouveau boîtier est de bonne qualité et 100% compatible avec le Pi, tout fonctionnera au maximum des performances sans planter !
Cas 2 : Le nouveau boîtier utilise aussi la puce Realtek RTL9210. Le correctif continuera de s’appliquer automatiquement.
Cas 3 : Le nouveau boîtier plante aussi. Il faudra simplement refaire la commande lsusb pour trouver le nouvel ID et remplacer 0bda:9210 par le nouveau code dans le fichier cmdline.txt.

Deux conseils essentiels avant de vous lancer :

La taille du nouveau SSD : Win32DiskImager fait une copie brute. Le nouveau SSD doit être strictement de la même taille ou plus grand que l’ancien. S’il est même un tout petit mégaoctet plus petit (ce qui arrive parfois entre deux marques différentes pour une même capacité affichée de 120 Go par exemple), Win32DiskImager refusera de copier la fin du disque.
L’espace non alloué : Si votre nouveau SSD est beaucoup plus grand (par exemple vous passez de 120 Go à 240 Go), votre Raspberry Pi démarrera mais ne verra que 120 Go. Il faudra simplement utiliser l’outil de configuration du Pi (sudo raspi-config) pour faire un « Expand Filesystem » afin qu’il utilise toute la place disponible.

En résumé, vous pouvez y aller sans crainte. Le clonage conservera tout votre Jeedom intact. Pensez juste à vérifier avec la commande lsusb -t sur le nouveau SSD si le driver utilisé est uas ou usb-storage, et si votre système reste stable !

micheld · Juin 19, 2026, 12:49

Bonjour @jlb,
et merci de ce retour très complet

De mémoire, je n’ai pas exactement le même nombre de secteurs sur mes 2 disques pourtant de 120Go.
Du coup, je ne pense pas pouvoir faire un clone avec Win32Diskimager du SSD ayant le plus grand nombre vers le plus petit..

Perso, j’utilise rpi-clone pour cloner le SSD. Ca me permet de laisser le SSD actif en place et de brancher le SSD cible sur le second USB3 du RPI (après arrêt de Jeedom et coupure électrique).

Mais là, je ne suis pas certain que le script rpi-clone gère bien le PARTUUID..

A priori, je devrais être dans le cas 1 de « Quirk USB », avec l’actuel SSD en Realtek Semiconductor Corp. RTL9201 et toujours de mémoire, en JMicron pour le second SSD.
Sachant que les disques tournent à chaque sauvegarde, il n’y aurait que des tests qui pourraient dire s’il y a compatibilité « Quirk USB » dans les 2 sens..

J’ai déjà mis en œuvre le watchdog de @bernard.dandrea où depuis les LOG de Jeedom, on voit les vérifications par minute et j’imagine quand il y aura un reboot.
A noter qu’avec 2 lignes de log par minute, il faudra un nombre conséquent de lignes des LOGS pour le constater. Mais, le principal est que Jeedom redevienne opérationnel automatiquement en cas d’erreur 500, sauf si le problème provient du protocole AES

Encore Merci @bernard.dandrea et @jlb de vos partages avec la communauté Jeedom

micheld · Juin 20, 2026, 7:33

Bonsoir,

Simplement pour dire que dans le fichier check_jeedom.sh, j’ai retiré les 2 lignes de log Execution curl et HTTP_CODE.

Du coup, il ne s”affichera plus que les éventuels logs lors de l’erreur 500.

Il n’y a plus la visibilité sur le bon fonctionnement du script, mais çà efface aussi les 2 accès disque / minute (2880 / jour) qui pourraient indirectement participer au blocage du RPI si problème uas.