Problème de redémarrage démon plugin jmqtt

Ds5 · Mars 19, 2026, 3:03

Hello et merci pour le retour. Depuis mon post dans lequel je constatais une meilleure stabilité sur plus de 4j j’ai eu 3 arrets intempestifs sur 2 jeedoms sur 3. 2 arrets à 2h d’intervalle sur un et un arret usuel sur la smart.

Merci pour l’explication sur le cache. On est d’accord que en pratique on peut ne pas toujours avoir de messages MQTT toutes les 5 minutes (cf mes ouvrants 4 fois par jour) donc dans mon cas c’est plutôt l’absence de heartbeat qui ferait tuer le démon. Je comprends aussi que ce n’est pas le démon qui plante mais plutot qui se ferait tuer par erreur. Ca semble en effet une piste cohérente avec les comportements observés (comme pourquoi un même event qui serat problématique ne ferait pas planter en même temps mes 2 jeedoms qui le reçoivent). Hormis du debug dans le démon, je ne sais pas si je peux moi même vérifier des soucis de cache.

Et sinon comme tu évoquais le cache, j’ai constaté depuis quelques temps sans que je sache le corréler aux débuts de plantage de démons des erreurs évoquées ici : Warning cache pip dans http.error. La réponse donnée est de mémoire message sans importance, cela étant vu que ca parle de non accès à un répertoire .cache je me demandais si on parle de la même notion de cache.

J’ai retiré le mode debug dans mon démon jMQTT mais si tu voulais le réactiver avec un code plugin renforcé en debug pourquoi pas. On peut voir cela en MP. Dis moi toutefois s tu veux que je vérifie avant des choses niveau cache.

Ds5 · Mars 19, 2026, 3:20

Ah oui tiens j’avais zappé ce point la. Pouvez vous me redire si sur les 4 valeurs seul le cleansession correspond à une valeur non par défaut ? Sur le NAS, j’ai un peu de mal à manipuler la config mosquitto car c’est un paquetage installé sans que j’ai eu à configurer quoi que ce soit. J’ai trouvé un fichier de config dans les arborescences du NAS mais je ne sais pas trop vérifier à chaud quelles sont les valorisations des paramètres de mon mosquitto et si d’ailleurs je change le bon fichier de config exploité par le paquet mosquitto du NAS.

rennais35000 · Mars 19, 2026, 3:29

Hello,
Normalement les valeurs par défaut à l’installation de mosquitto si j’ai bien compris tout ce que j’avais lu sur un forum en anglais :
cleansession true
keepalive_interval 30
restart_timeout 5
retry_interval 5
Même si on ne les voit pas dans le fichier de conf.
Donc si elle n’y sont pas il faut les créer avec ces nouveaux paramètres

cleansession false
keepalive_interval 60
restart_timeout 30
retry_interval 30

et tester.

Ds5 · Mars 19, 2026, 3:47

bon j’ai édité le fichier de config. Fait stop sur le paquet mosquitto et à la relance mon mosquitto ne démarre plus. Glups… je vais retirer mes modifs en espérant que cela refonctionne, j’ai du mal modifier le fichier ou un paramètre est erroné

[edit] en remettant toutes mes modifs en commentaires cela refonctionne, je ne pige pas bien comment modifier ce fichier, je me suis contenté de mettre une ligne avec chaque paramètre. Ou alors il y a une syntaxe à respecter de type « tab » entre paramètre et valeur. Ou bien encore à l’édition en ssh j’ai involontairement mis un caractère moisi. Je ne comprends pas bien. Au moins je n’ai pas tout qui reste en vrac mais c’est dommage, je ne trouve pas comment faire. Et hormis system failed to start mosquitto je ne vois pas ou trouver un log expliquant pourquoi mes paramètres modifiés empêchent de démarrer (dans mosquitto.log je ne vois rien hormis la commande de relance du serveur mosquitto…)

Jeandhom · Mars 19, 2026, 4:17

dé-commente ligne par ligne pour trouver la fautive.

rennais35000 · Mars 19, 2026, 4:46

il n’y a pas de syntaxe spéciale, ce que j’ai mis est un copié collé de ce que j’ai.

Et pour Paramètres par défaut voilà ce que j’avais trouvé.

Tous les paramètres ont un paramètre par défaut qui n’est pas défini dans le fichier de configuration, mais qui est interne à mosquitto. Les paramètres du fichier de configuration remplacent ces paramètres par défaut.

Moi j’ai installé mosquitto par Jmqtt donc j’édite directement à partir de configuration du plugin.
Mais toi si j’ai bien compris tu l’a installé en dehors, il doit falloir que tu cherches le bon fichier.

Peut-être voir celui de l’install normale.

find -iname mosquitto.conf

Alors que celui géré par jMQTT est jMQTT.conf dans le répertoire /etc/mosquitto/conf.d

Ds5 · Mars 19, 2026, 9:39

@Jeandhom Merci à vous deux. Oui j’avais cherché sur le net et dans les tutos pour trouver le fichier de config utilisé par le paquet Mosquitto officiel Synology sur base d’une commande find -name. Je pense avoir localisé le bon fichier. J’avais décommenté 3 paramètres sur 4 et ca plantait et je n’ai pas vraiment compris l’erreur donc vu que ma prod jeedom était en vrac avec mosquitto down j’ai retiré tout et relancé. Je vais revérifier en ayant plus de temps devant moi. Le paramétrage ayant semble-t-il résolu certains soucis cela vaut le coup d’essayer. Pour retrouver un mosquito opérationnel, j’avais bien juste commenté mes ajouts et pas remis une sauvegarde du fichier précédent donc le fichier modifié et recommenté semble donc ok. Bon ca sent l’erreur bete mais que je n’ai pas vu pour le moment. Ou alors c’est ma méthode de relance qu paquet qui est mauvaise mais bon hormis faire Stop sur le paquet mosquitto puis Lancer sous DSM sur le NAS je ne vois pas ce qui serait mauvais. Bref je vais retenter « au calme »

Ds5 · Mars 21, 2026, 9:37

Hello @Bad. Arrête démon cette nuit à 2h25 après avoir appliqué les modifs de débug. Je prépare l’ensemble des logs.

Dans le jMQTT.log je vois ceci :

[2026-03-21 02:23:03][DEBUG] Nothing has been sent for >45s [deltaTx=60], sending a Heartbeat to the Daemon [deltaRx=0]
[2026-03-21 02:24:04][DEBUG] Nothing has been sent for >45s [deltaTx=61], sending a Heartbeat to the Daemon [deltaRx=1]
[2026-03-21 02:25:04][WARNING] No message or Heartbeat received for >300s [deltaRx=1774056304], killing the probably dead Daemon [deltaTx=60]
[2026-03-21 02:25:04][INFO] Arrêt du démon jMQTT
[2026-03-21 02:25:04][DEBUG] Envoi du signal SIGTERM au Démon
[2026-03-21 02:25:04][DEBUG] Nothing has been sent for >45s [deltaTx=60], sending a Heartbeat to the Daemon [deltaRx=0]
[2026-03-21 02:25:04][DEBUG] Impossible de se connecter du Démon sur le port 37871, erreur Connection refused
[2026-03-21 02:25:04][INFO] Démon jMQTT arrêté
[2026-03-21 02:25:04][DEBUG] Nettoyage du Démon
[2026-03-21 02:26:06][INFO] Démarrage du démon jMQTT
[2026-03-21 02:26:06][DEBUG] Nettoyage du Démon
[2026-03-21 02:26:13][DEBUG] Dependencies installed.
[2026-03-21 02:26:13][INFO] Lancement du démon jMQTT, commande shell: 'LOGLEVEL=debug CALLBACK="http://127.0.0.1:80/plugins/jMQTT/core/php/callback.php" APIKEY=pgsy1XSFijgavYk5yY8moyT0xGjmnI6RHtnVTNXVkxxI1Ec0lqnSB18qNXWIE273 PIDFILE=/tmp/jeedom/jMQTT/jmqttd.py.pid /var/www/html/plugins/jMQTT/resources/jmqttd/venv/bin/python3 /var/www/html/plugins/jMQTT/resources/jmqttd/jmqttd.py >> /var/www/html/core/class/../../log/jMQTTd 2>&1 &'
[2026-03-21 02:26:14][INFO] Démon démarré
[2026-03-21 02:27:03][DEBUG] Nothing has been sent for >45s [deltaTx=49], sending a Heartbeat to the Daemon [deltaRx=0]

dans le jMQTTd j’ai un message jMsg.Snd 162ms d’un module Zwave avant arrêt :

[2026-03-21 02:25:04,308][DEBUG] JMsg.Snd        SockOut               send() : Sent TO Jeedom 2 messages handled in 161.231995ms (qToJ size 3): [{'cmd': 'messageIn', 'id': '1462', 'topic': 'zwaveJeeS2/7/lastActive', 'payload': '{"time":1774056304028,"value":1774056304028}', 'qos': 0, 'retain': False}, {'cmd': 'messageIn', 'id': '1462', 'topic': 'zwaveJeeS2/7/49/0/Power', 'payload': '{"time":1774056304033,"value":4.1}', 'qos': 0, 'retain': False}]
[2026-03-21 02:25:04,309][DEBUG] root            MainThread  signal_handler() : Signal 15 caught, exiting...
[2026-03-21 02:25:04,310][INFO] Main            MainThread        shutdown() : Stop jMQTT python daemon
[2026-03-21 02:25:04,311][DEBUG] JMsg.Rcv        MainThread   receiver_stop() : Stop requested
[2026-03-21 02:25:04,313][DEBUG] JMsg.Snd        SockOut           _loopSnd() : Sending 3 messages (0 left in queue)

rien dans http.error ou cron_execution mais je les mettrai dans le zip de logs.

dans les logs broker :

[2026-03-21 02:25:04][DEBUG] Payload '{"time":1774056304279,"value":1774056304028}' reçu sur le Topic 'zwaveJeeS2/7/lastActive' traité en 7ms, commandes affiliées 
[2026-03-21 02:25:05][INFO] Client MQTT déconnecté du Broker
[2026-03-21 02:25:05][INFO] Client MQTT déconnecté du Broker
[2026-03-21 02:26:06][INFO] Client MQTT déconnecté du Broker
[2026-03-21 02:26:14][INFO] Démarrage du client MQTT

J’envoie donc le zip. Et j’attends pour savoir s’il faut de nouveau modifier un fichier. Merci par avance pour tout cela.

[edit] logs envoyés en MP / j’essaie aussi ce week-end de retenter la modif de config du mosquitto en espérant comprendre pourquoi les modifications d’hier avaient fait planté le broker sur mon NAS

Bad · Mars 21, 2026, 11:35

Salut @Ds5,

Je pense qu’on a mis le doigt sur le problème

deltaRx=1774056304 implique que le cache n’a pas renvoyé de valeur, donc la valeur par défaut 0 est utilisée, c’est bien ce que je pensais quand je t’ai envoyé le nouveau code.

Le fix coté jMQTT est assez simple : mettre time() comme valeur par défaut plutôt que 0.
Mais je vais regarder comment modifier le code du Core pour que comprendre pourquoi le cache à renvoyé ça, ça peut impacter beaucoup d’autres choses dans Jeedom en général !

Peux-tu me dire quel est le moteur de cache utilisé sur tes systèmes ?

Bad

benj29 · Mars 21, 2026, 11:59

Salut,

J’atterris quelques jours après avoir laissé tout de côté.
@Bad tu as toujours l’accès à mon Jeedom. Je n’ai pas de souvenir de plantage ces derniers jours (j’étais à l’étranger). Tu as vu quelquechose ?

Bad · Mars 21, 2026, 12:01

Hello, bon retour parmi nous,

J’avoue que je n’ai pas regardé, vu que tu n’es pas revenu vers moi
Mais avec l’aide de @Ds5, j’ai une bonne idée du pb maintenant.

Le correctif sortira dans la prochaine beta (certainement d’ici demain aprèm), sinon tu peux patcher avec ces changements :

Bad

Bad · Mars 21, 2026, 1:16

@Ds5, peux-tu faire une modification dans le Core avant de chercher à corriger le bug stp ?

Il faudrait remplacer dans core/class/cache.class.php vers la ligne 390 :

file_put_contents(jeedom::getTmpFolder('cache').'/'.base64_encode($_cache->getKey()),serialize($_cache));

par :

file_put_contents(jeedom::getTmpFolder('cache').'/'.base64_encode($_cache->getKey()), serialize($_cache), LOCK_EX);

En gros, ça va ajouter l’option « LOCK_EX » à file_put_contents() pour qu’une écriture en cache soit exclusive pour chaque clé, car cette fonction n’est pas « thread-safe » de base.
Un commentaire en parle dans la doc de la fonction, c’est déjà un bon début, mais ce ne sera peut-être pas suffisant, si tu as encore ces problème avec le daemon avec LOCK_EX, je regarderai pour re-implémenter l’écriture en cache vraiment « thread-safe ».

Bad

Ds5 · Mars 21, 2026, 7:19

Hello. Super si on a une bonne piste. Voici ce que j’ai dans le jeedom sur lequel nous avons testé les arrets intempestifs (je n’ai pas regardé les autres mais comme je n’ai jamais rien touché à cela pas de raison que cela soit différent) :

Ds5 · Mars 21, 2026, 10:07

Modification dans le core avec LOCK_EX réalisée ce soir, 21.03 à 23h05. Je ne touche plus à rien et je n’ai évidemment pas patché le plugin. Si aucun arrêt intempestif sur la semaine à venir ce sera probant. Je n’ai rien redémarré sur mon jeedom au fait, j’imagine que la modif décrite ici Problème de redémarrage démon plugin jmqtt - #52 par Bad ne nécessite aucune manip et est prise en compte à chaud.

pour complément la modification est en ligne 370 chez moi dans ce bloc code :

	public static function save($_cache){
		file_put_contents(jeedom::getTmpFolder('cache').'/'.base64_encode($_cache->getKey()), serialize($_cache), LOCK_EX);
	}

benj29 · Mars 22, 2026, 6:10

Suffisait que je revienne et qu’on en parle ça vient de péter…

benj29 · Mars 22, 2026, 6:10

Il faut aussi faire ça en plus de code côté plugin ?

Ds5 · Mars 22, 2026, 10:40

Bonjour. J’ai vu ce matin en me levant que ca n’a pas fonctionné pour moi côté Core, arrêt intempestif cette nuit à 2h18, j’espère ne pas m’être trompé dans ma manip. Dans le log enrichi jMQTT j’ai ceci :

[2026-03-22 02:16:03][DEBUG] Nothing has been sent for >45s [deltaTx=59], sending a Heartbeat to the Daemon [deltaRx=0]
[2026-03-22 02:17:04][DEBUG] Nothing has been sent for >45s [deltaTx=61], sending a Heartbeat to the Daemon [deltaRx=0]
[2026-03-22 02:18:03][WARNING] No message or Heartbeat received for >300s [deltaRx=1774142283], killing the probably dead Daemon [deltaTx=59]
[2026-03-22 02:18:03][INFO] Arrêt du démon jMQTT
[2026-03-22 02:18:03][DEBUG] Envoi du signal SIGTERM au Démon
[2026-03-22 02:18:04][INFO] Démon jMQTT arrêté
[2026-03-22 02:18:04][DEBUG] Nettoyage du Démon
[2026-03-22 02:19:05][INFO] Démarrage du démon jMQTT
[2026-03-22 02:19:05][DEBUG] Nettoyage du Démon
[2026-03-22 02:19:13][DEBUG] Dependencies installed.

J’ai bien évidemment les logs usuels que je peux envoyer si besoin. Dits moi @Bad si tu les souhaites. Je n’ai pas testé la modification plugin, toutefois de ce qu’indique @benj29 cela n’a pas résolu son problème, je ne sais pas si cela peut résoudre le mien. Il me reste aussi à retenter de modifier mes paramètres mosquitto pour lesquels je n’avais pas réussi la modification sans faire planter mon broker.

benj29 · Mars 22, 2026, 11:30

Nuance, je n’ai fait aucune update de plugin, donc c’est normal que j’ai toujours des bugs.
J’ai installé la beta mais la version date de fév.
v26.1.1 (2026-02-23 19:39:40)

Du coup j’ai réinstallé la stable et j’ai fait la modification dans le code :

J’ai redémarré le démon, il est OK (donc a priori, bien fait lol).

J’ai aussi fait la modif dans le core :

file_put_contents(jeedom::getTmpFolder('cache').'/'.base64_encode($_cache->getKey()), serialize($_cache), LOCK_EX);

A suivre.

Ds5 · Mars 22, 2026, 12:21

ah ok j’avais mal compris. Donc pour le moment la modif Core seule semble ne pas suffire (chez moi).

Ds5 · Mars 22, 2026, 5:33

deuxième arrêt de la journée pour moi à 17h02. Je vais sans doute appliquer le fix du plugin. Avec 1 à 2 arrêts par jour en moyenne, je devrai assez vite voir si cela est mieux. Et je reste en mode debug.