Suite à la mise à jour du plugin eibd en version 2022-09-14, j’ai perdu une fonctionnalité :
J’utilise le plugin Weather pour récupérer les information météo.
J’ai un équipement KNX « Station Méteo KNX Virtuelle » qui utilise les informations du plugin weather pour les envoyer cycliquement (toute les 5mn) sur le bus KNX.
Ca fonctionnait parfaitement depuis 1 an, mais depuis la dernière mise à jour ça ne fonctionne plus.
La température est bien mise à jour dans la commande « Weather », mais n’est plus récupéré dans la commande KNX. La valeur est à 0.
Qui plus est, le daemon knxd crash à chaque lecture cyclique :
J’ai des messages du type :
« Attention je pense qu’il y a un soucis avec le démon que j’ai relancé plus de 3 fois consécutivement »
avec un occurence /5mn
La mise à jour corrigé un soucis pour le read en cyclique qui avait un bug la valeur renvoyer venait de la bas de données donc aucun intérêt
Avant d’utiliser un read cyclique il faut s’assurer dans ets que l’équipement n’ai pas capable de l’émettre tout seul et que dans le gad le flag read soit actif
Visiblement, ce n’est pas le seul problème.
Le moniteur de bus n’affiche plus rien.
J’utilisait des commandes pour historiser des infos (temp°, conso) dans une basse influxdb, mais plus rien ne fonctionne depuis l’installation de la MAJ.
Je ne sais pas si c’est lié, mais le process php consomme 100% de CPU et bouffe toute la mémoire.
J’ai pleins de messages du type :
Sep 16 11:32:11 jeedom kernel: [ 434.373449] Out of memory: Kill process 2856 (php) score 887 or sacrifice child
Sep 16 11:32:11 jeedom kernel: [ 434.376176] Killed process 2856 (php) total-vm:2547956kB, anon-rss:1432540kB, file-rss:448kB, shmem-rss:156kB
Edit :
Je confirme le deaemon knxd redémarre suite a une demande de ‹ Read › sur une commande.
La mémoire est 100% utilisée par le process php, qui fini par se faire tuer par oomkiller.
Mémoire avant de lancer un read
root@jeedom:/tmp/jeedom/cache# free
total used free shared buff/cache available
Mem: 1585892 84040 1406384 4888 95468 1427184
Swap: 1048572 154204 894368
Juste avant le oomkiller
root@jeedom:/tmp/jeedom/cache# free
total used free shared buff/cache available
Mem: 1585892 1541456 23860 1224 20576 5352
Swap: 1048572 1048572 0
dmesg | tail -3
[Fri Sep 16 11:42:37 2022] Out of memory: Kill process 4272 (php) score 894 or sacrifice child
[Fri Sep 16 11:42:37 2022] Killed process 4272 (php) total-vm:2566388kB, anon-rss:1478908kB, file-rss:1096kB, shmem-rss:160kB
[Fri Sep 16 11:42:37 2022] oom_reaper: reaped process 4272 (php), now anon-rss:0kB, file-rss:0kB, shmem-rss:160kB
root@jeedom:/tmp/jeedom/cache# free
total used free shared buff/cache available
Mem: 1585892 56956 1477520 1168 51416 1468884
Swap: 1048572 385900 662672
Vue dans /var/www/html/log/cron_execution:
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
PHP Fatal error: Out of memory (allocated 2401239040) (tried to allocate 262144 bytes) in /var/www/html/vendor/doctrine/cache/lib/Doctrine/Common/Cache/CacheProvider.php on line 185
Failed to restart knxd.service: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
See system logs and 'systemctl status knxd.service' for details.
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
PHP Fatal error: Out of memory (allocated 2189426688) (tried to allocate 20480 bytes) in /var/www/html/vendor/doctrine/cache/lib/Doctrine/Common/Cache/FilesystemCache.php on line 71
Failed to restart knxd.service: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
See system logs and 'systemctl status knxd.service' for details.
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
PHP Fatal error: Out of memory (allocated 2187329536) (tried to allocate 262144 bytes) in /var/www/html/vendor/doctrine/cache/lib/Doctrine/Common/Cache/CacheProvider.php on line 187
# systemctl status knxd.service
Failed to get properties: Failed to activate service 'org.freedesktop.systemd1': timed out (service_start_timeout=25000ms)
C’est étrange, le read attend un réponses ou tombe en timeout je ne vois pas pourquoi il vas créé une surcharge CPU.
J’aurai bien vue une boucle par le flag transmettre mais aucun changement sur cette option
en tous cas, ca fait cracher knxd. Je n’arrive pas à voir les logs.
A ce sujet, le niveau de log de KNXd est très elevé.
J’ai 3 millions de lignes knxd dans le fichier daemon.log.
Est- il possible de baisser la verbosité du daemon ?
Je n’avais pas vu ta réponse @mika-nt28 , désolé … De tout façon, ma VM a fini par cracher complètement, le fs ressortait plein d’erreur. J’ai pu quand même faire une sauvegarde.
J’ai réinstallé une VM Jeedom DIY (Debian 11 + script d’install) et restauré le backup. Je me retrouve avec le même comportement, après la restauration et l’activation du plugin EIB, à savoir redémarrage du daemon knxd et 100% de mémoire occupée.
J’ai l’impression que le problème vennait de ma commande « Station Méteo KNX Virtuelle » qui effectuait un read cyclique de la valeur.
Je suis donc reparti de 0 avec jeedom 4.2.21 tout neuf. J’ai installé le plugin eibd (v2022-09-29 du coup). Le moniteur de bus fonctionne.
J’ai recréé mon équipement Openweather (#[Général][Meteo OpenWeather]).
Par contre, je n’arrive plus a recréer la commande KNX qui lit la commande (#[Général][Meteo OpenWeather][Température]#) et l’envoi périodiquement sur le bus.
Si ca se trouve, c’est cette fonctionnalité qui n’est plus présente dans dernières releases et qui faisaient planter le système ?
EDIT: Je viens de voir qu’il n’est plus possible d’activer le flag READ sur les commande d’info. C’est ce que j’avais activé précédemment. Si ca se trouve le problème vient de là.
Si je comprends bien les informations son issue du plugin openweather il faut donc créer une commande de type actions en retour d’état la commande et le flag transmettre.
Avec cette méthode a chaque changement de la valeur le plugin la transmettra par le bus.
Une commande info est une valeur qui vient du bus aucun intérêt de lui autorisé la réponse
Effectivement, en utilisant un commande action avec le flag « transmettre », ca fonctionne.
Enfin plus ou moins. De temps en temps, le commande répond par une RESPONSE à un requête READ provenant d’un autre participants. Mais c’est assez aléatoire. Ca a marché pendant 5 mn, puis plus rien. Oublis ca, c’était dû à un trop grand nombre de sessions IP ouverte sur la passerelle, ça fonctionne maintenant.
Par contre concernant le READ, je ne vois pas ou est le problème ? J’ai des participants KNX qui ont des flag READ/WRITE activés simultanément. On peut ainsi s’assurer qu’un commande à bien été transmise.
