Gladys v4.70.0 (mise à jour automatique via Watchtower)
Docker sur Linux (Ubuntu), network_mode: host
Intégration MQTT avec plusieurs appareils (Raspberry Pis)
Problème :
Après que Watchtower a automatiquement mis à jour Gladys de v4.66.8 vers v4.70.0, le conteneur a commencé à consommer ~60% du CPU en permanence – pas seulement au démarrage, mais en continu.
gladys 59.72%
Les logs montraient une avalanche d’erreurs au démarrage :
NotFoundError: DeviceFeature mqtt:xxx not found
Cela semble être un problème de synchronisation où des messages MQTT conservés arrivent avant que Gladys n’ait chargé son cache de device features. Cependant, même après que les erreurs de démarrage ont cessé et que les logs étaient propres, le CPU est resté à ~60%.
Solution :
Rétrogradé vers v4.66.8 et épinglé la version pour empêcher Watchtower de mettre à jour automatiquement :
Après la rétrogradation, le CPU a chuté immédiatement à ~4%.
gladys 3.90%
Question :
Est-ce un problème connu avec la v4.70.0 ? Y a-t-il des plans pour corriger cette régression de CPU ? J’aimerais mettre à jour éventuellement, mais pas si cela plombe à nouveau les performances.
Salut @bamboleate et bienvenue sur le forum !
tu dois avoir quelque chose qui ne va pas car de mon côté je n’ai pas de soucis de CPU qui s’emballe depuis la version 4.70 (ni même avant) :
Le pic d’utilisation CPU est très reproductible de mon côté. Voici l’avant/après :
v4.70.0:
gladys 59.72%
v4.66.8 (same machine, same config, same moment):
gladys 3.90%
J’utilise l’intégration MQTT avec 3 Raspberry Pi (cartes relais + capteurs). Pas de Zigbee, pas de Z-Wave, j’utilise Node-RED.
Une chose que j’ai remarquée dans les logs au démarrage avec la v4.70.0 :
NotFoundError: DeviceFeature mqtt:xxx not found
Cela se répète pour chaque DeviceFeature MQTT à chaque démarrage — on dirait que les messages conservés (retained messages) arrivent avant que le cache des appareils ne soit prêt. Cette avalanche d’erreurs pourrait-elle provoquer le pic d’utilisation du CPU ? Peut-être que c’est spécifique aux configurations MQTT ?
Ton matériel est clairement bien, de mon côté je suis sur un cluster proxmox et Gladys est sur un LXE (équivalent VM pour faire simple) avec 6Go de RAM et 2 vCPU.
Je ne suis pas un expert pour une analyse poussée malheureusement.
Néanmoins côté intégration MQTT de Gladys, utilises-tu l’intégration interne ?
De ce que je vois du message d’erreur, un (ou plusieurs ?) appareil n’est pas trouvé/reconnu, il faudrait voir avec MQTT Explorer si il est bien visible et si sa configuration est toujours bonne dans l’intégration MQTT de Gladys.
Salut @mutmut, merci pour les questions détaillées !
Oui, j’utilise l’intégration MQTT interne dans Gladys.
Concernant les messages NotFoundError : j’ai déjà étudié cela en profondeur. Les erreurs apparaissent seulement au démarrage et sont un problème de synchronisation — le broker MQTT livre des messages conservés avant que Gladys ait fini de charger son cache de device features. Après le démarrage, les logs sont complètement propres et tous les appareils fonctionnent correctement. Les RPis publient correctement, les topics sont corrects, et tout est visible dans MQTT Explorer.
Ces erreurs ne sont pas la cause de mes problèmes — elles sont un symptôme du timing au démarrage. Et plus important : le CPU reste à ~60 % en permanence, pas seulement pendant la pluie d’erreurs au démarrage.
Le point clé est la comparaison directe :
v4.70.0 → 60 % CPU en permanence, mêmes erreurs au démarrage
v4.66.8 → 4 % CPU en permanence, mêmes erreurs au démarrage (le problème de temporisation existe dans les deux versions)
Donc quelque chose a changé entre v4.66.8 et v4.70.0 qui provoque une régression CPU, du moins sur ma configuration avec MQTT. Les erreurs au démarrage sont un problème distinct (plus ancien).
Mon premier instinct dit que ça vient de la 4.70 parce qu’avant j’avais watchtower activé et je ne me donnais pas la peine de gérer manuellement toutes les versions, mais quand j’ai été confronté au problème pour la première fois, c’était la 4.70 et je n’ai fait qu’une grosse rétrogradation pour ne pas trop bidouiller et juste le remettre à fonctionner.
MAIS j’installerai toutes les versions finalement pour vous aider à identifier le problème. Bien sûr ce week-end je
Les logs montrent quelque chose d’intéressant. Il y a une avalanche de rejets de promesses non gérés liés à des DeviceFeature MQTT introuvables :
NotFoundError: DeviceFeature mqtt:wozipi:07 not found
NotFoundError: DeviceFeature mqtt:wozipi:10 not found
NotFoundError: DeviceFeature mqtt:wozipi_bme680:temperature not found
[...and so on]
Ces erreurs apparaissent toutes les quelques secondes (mon WoZiPi envoie des messages MQTT en continu). Sur la v4.66.9 cela était apparemment géré silencieusement — sur la v4.67.0 cela semble provoquer une boucle CPU.
À noter également : ps aux n’est pas disponible à l’intérieur du conteneur, mais toutes les erreurs proviennent du processus Node.js (index.js), donc oui — c’est le processus Node.js de Gladys qui cause le pic.
Je n’utilise pas HomeKit, donc la mise à jour de la dépendance HAP n’est probablement pas la cause. Mon hypothèse serait un changement dans la gestion des rejets de promesses non gérés entre la v4.66.9 et la v4.67.0.
Je me demande si cela pourrait venir de l’intégration Nuki, car l’intégration Nuki utilise MQTT pour écouter des messages MQTT provenant des serrures Nuki.
Au fait, nous allons publier une amélioration de l’intégration Nuki dans la prochaine version de Gladys pour empêcher l’intégration Nuki de démarrer si elle n’est pas configurée, donc cela pourrait certainement vous aider pour cela !
Je vais bientôt publier la nouvelle version de Gladys avec ce correctif, et pourrais-tu simplement essayer cette version pour voir si elle résout ton problème.
Sinon, nous étudierons le problème plus en profondeur ensemble
Hello,
Je confirme que les logs mqtt en trop cela vient de l’intégration Nuki v1, c’est normalement corrigé sur la v1.0.1 (@mutmut avait détecté ce soucis dès la release G4.67)). Le susbribe mqtt au démarrage se faisait sur tous les devices existants, l’attribut de recherche était mal configuré et allait au delà du service Nuki, ça ne devait pas avoir de conséquence outre mesure en revanche.
J’ai mis à jour de v4.66.8 à v4.71.0 et je vois toujours ~60–70% d’utilisation CPU. Après un débogage approfondi, j’ai trouvé deux problèmes distincts:
Issue 1 : Condition de concurrence avec les messages conservés MQTT (boucle de plantage au démarrage)
Au démarrage, Mosquitto rejoue immédiatement tous les messages conservés sur gladys/master/# avant que Gladys n’ait fini de charger son cache de périphériques. Cela provoque un flot d’erreurs NotFoundError: DeviceFeature mqtt:xxx not found — une par topic conservé, à chaque redémarrage. Le pic CPU est causé par des rejets de promesses non gérés qui saturent la boucle d’événements.
Solution de contournement : supprimez tous les messages conservés sur gladys/master/# en utilisant mosquitto_pub -r -n. Après un redémarrage, Gladys les repopule et fonctionne correctement — mais seulement jusqu’au redémarrage suivant.
Cela ressemble à un bug où le service MQTT s’abonne avant que le gestionnaire de périphériques ait fini son initialisation.
Issue 2 : Le scanner de présence du LAN Manager exécute ip neigh show en boucle continue
Même avec le LAN Manager réglé sur « disabled » dans l’UI (et LANMANAGER_PRESENCE_STATUS=disabled confirmé dans la DB), Gladys continue de lancer ip neigh show via execve en continu. Comme ip n’est pas installé dans l’image Docker de Gladys (exit code 127), chaque appel échoue immédiatement et la boucle se répète.
J’ai confirmé cela avec strace -f -e execve sur le PID de Gladys.
Solution de contournement : injecter un script ip factice qui se termine proprement réduit légèrement la surcharge, mais la boucle elle-même continue.
Cela semble être un bug où le LAN Manager ne respecte pas l’état désactivé à l’exécution.
Environnement :
Gladys v4.71.0 (mis à jour depuis v4.66.9)
Docker, network_mode: host
Broker Mosquitto externe (eclipse-mosquitto:2.0)
~30 appareils MQTT (sur plusieurs pis)
Hôte : Ubuntu 24.04, 32 GB RAM
Je peux fournir davantage de logs ou tester des correctifs si utile. Merci !
Merci pour le retour, je vais examiner les deux problèmes
Cela dit, je ne pense pas qu’ils aient été introduits dans Gladys v4.67.0, donc ils ne sont probablement pas la cause principale de l’utilisation élevée du processeur que vous observez.
Puisque vous avez mentionné que l’utilisation du processeur est constante (pas seulement au démarrage), cela ne ressemble pas non plus à un problème de messages retenus.
Vous avez également dit que votre WoZiPi envoie des messages MQTT en continu, avez‑vous une idée du taux de messages (par ex. messages par seconde) ?
Une explication possible est qu’il n’y a pas de « bug » réel, mais plutôt une limitation de débit :
Avec le code supplémentaire que nous avons ajouté récemment (notamment autour de Nuki), l’intégration MQTT pourrait être un peu plus lente à traiter les messages. Si votre configuration envoie des messages à haute fréquence, Gladys pourrait ne pas suivre, entraînant une accumulation de messages en file d’attente et une augmentation de l’utilisation du processeur.
Si c’est le cas, la solution serait probablement d’optimiser le traitement MQTT dans Gladys pour améliorer le débit.
Indiquez-moi le volume de messages, cela aiderait à cerner le problème !
J’ai mesuré le taux de messages MQTT en utilisant mosquitto_sub -t '#' en le passant dans pv :
~0.8 messages/seconde (291 messages sur ~6 minutes, tous topics confondus)
Cela me semble bas, donc je ne pense pas que le débit soit le problème. L’utilisation CPU élevée (~60–70%) est constante et ne corrèle pas avec des pics de messages.
Pour référence, ma configuration publie les états des relais depuis trois Raspberry Pis (WoZiPi et AZiPi, SchlaZiPi) ainsi que des données des capteurs BME680 et SHT35 — rien de particulièrement bavard.
