Ou a faire nous meme si plus maintenu 
On est d’accord qu’un rollback en debian 10 n’est pas une solution à moyen/long terme ? (compatibilité futur plugin, core jeedom …)
J’avais tout check mes plugins opérationnels mais je suis passé à côté de l’essentiel avec la memoire !
Bonjour znation, comment tu fais pour récupérer la mémoire des plugins?
Merci
De mon coté avec les trois plugins,
zigbee mqtt, mirobot et alexa smarthome,
j’ai pu supprimer le plugin xiaomihome
Victoire 
J’ai pensé à faire la même chose mais je voudrais garder le son et la lumière de la passerelle xiaomi pilotable depuis Jeedom.
Je regarde pour yeelight mqtt / mirobot de mon côté
J’ai cherché pour mettre à jour python3 et fail2ban (car la 1.0.2 supporte la python 3.10).
Ce qui change la donne c’est que le fait de builder un nouveau binaire, l’installe par défaut dans /usr/local/bin.
Même le fait de faire le lien symbolique depuis le répertoire système /usr/bin vers le nouveau binaire fait que python ne va plus chercher les packages au même endroit qu’avant :
/usr/lib/python3/dist-packages/ (packages installés par apt avec python system)
/usr/local/lib/python3.9/dist-packages/ (packages installés par pip avec python system)
/usr/local/lib/python3.9/site-packages/ (packages installés par pip avec python local)
J’ai réinstallé via pip les packages dont j’avais besoin et j’ai relancé l’install des dépendances des plugin (j’ai que xiaomihome en python3).
fail2ban n’étant pas installable par pip directement, j’ai récupérer les packages des répertoires system pour les copier dans site-packages (ce qui évite de modifier les fichiers de l’app directement).
TOUT ça en ayant fait un backup image système avant 
(freebox_delta)
+1 son et lumière utilisé au quotidien. La lumière c’est jouable avec d’autres choses mais le son j’ai rien trouvé
J’ai rien trouvé pour la lumière 
C’est avec quel plugin ?
C’est pas un plugin. C’est monter du mqtt à côté j’en ai parlé sur mes posts précédents
Resultat de mon monitoring de mémoire sur les plugin qui utilisent python au nombre de 4 chez moi, ils sont tous impactés. Restart auto par scénario au dessus d’un certain seuil mais ca monte vraiment trop vite, pas possible de laisser une infra avec des restarts de cette façon. Je laisse dans l’etat quelques semaines voir si ca se décante sur le forum sinon restauration de ma sauvegarde en debian 10.
Le pire xiaomihome, puis broadlink / tahoma (meme augmentation) et enfin sms qui monte pas trop vite
Je pense que l’unité est plutôt des bytes que des Mo.
Merci pour cette commande Script j’avais pas pensé de le faire dans Jeedom
@znation > on est OK que tes stats pourris sont en 3.9 de base ? tu n’as pas updaté ?
Merci. J’ai fait un lien symbolique (plus propre et ça marche !) J’ai donc un python 3.9.19 avec un fail2ban qui marche. J’ai reboot et ça marche plutôt bien.
Oui mes stats sont avec python 3.9.2.
Pourrais tu filer la procédure complète pour être clean en 3.9.19 ainsi qu’un fail2ban opérationnel ? Ya tellement de manipulation dans les posts …
Merci
Après, il faut peut être attendre de passer sur Debian 12 pour bénéficier de python 3.11.2 et ne plus avoir ces fuites de mémoire liées à python
Bon histoire de pas bricoler sur ma vm de prod, j’ai restoré ma sauvegarde en debian 10 (
) et retesté au passage que la restauration de config jeedom fonctionne bien ;-).
Y’a pas photo … ca bouge pas d’un poil ! (python 3.7.3)
Je vais mettre ma vm en debian 11 et python 3.9.2 pour les plugins en question en test
Et bénéficier des autres nouvelles fuites mémoire de python pour Debian 12 
Surtout que debian 12 supporté par jeedom c’est pas pour tout de suite. Que les plugin tiers qui déconnent je peux ‹ comprendre › que c’est pas toujours bien suivi par les devs mais par exemple le plugin SMS c’est un plugin officiel qui est lui aussi impacté par le bug python.
Je vais finir par ouvrir un ticket chez jeedom.
Je vais faire une synthèse pour marquer le topic comme « solved ». Le constat est que des plugins qui utilisent le python du système sous Debian 11 (Python 3.9.3) ont des problèmes de fuites mémoires. La solution côté développeur et d’utiliser du venv pour avoir la main sur la version de Python. Mais côté utilisateur que nous sommes, une solution est de mettre à jour Python en 3.9.19 (à ce jour).
Pour la procédure de mise à jour de Python en 3.9.19 : Mémoire qui baisse progressivement depuis 4.4 ou Debian 11 - #11 par Chrisax
Ensuite :
$ cd /usr/local/lib/python3.9/site-packages
$ ln -s /usr/lib/python3/dist-packages/fail2ban* ./
$ ln -s /usr/lib/python3/dist-packages/apt* ./
$ ln -s /usr/lib/python3/dist-packages/lsb* ./
$ service fail2ban restart
$ service fail2ban status