Pour moi le pb est chez Debian.
Pourquoi sont-ils restés bloqué à 3.9.2 alors qu’il y a eu des corrections dans Python ?
Le daemon python qui consomme le plus est celui qui a le plus de trafic.
Le daemon klf200 avec une ouverture / fermeture des volets par jour ne consomme quasiment rien.
Ouais pourquoi officiellement debian 11 reste figé sur cela …
Mais je suis surpris qu’il n’y ait pas plus de plainte ici et d’avertissement de jeedom sur ce sujet même s’ils sont pour rien mais leurs plugins officiels sont impactés (SMS en tout cas chez moi). Alors ouais si on met 16 go de ram et fermer les yeux pour pallier a cela…mais je suis pas du genre a distribuer de la ram généreusement pour rien.
pour moi le problème est un peu plus complexe
tous les démons pythons, même avec beaucoup de « trafic », n’ont pas de fuites de mémoires
il y a probablement une combo de lib & python3.9.2
donc évitons de faire des raccourcis en disant « tous les démons python »
Je suis pas contre, mais les 4 plugin python que j’ai, les 4 impactés et les autres membres en reportent d’autres. C’est peut être pas général mais c’est loin d’être a la marge.
Merci.
fail2ban reparti 
C’est clair que 4 c’est un échantillon statistiquement représentatif 
Debian est une distribution stable. La Debian 11 sort avec Python 3.9.2 est reste en 3.9.2. Si faille de sécurité, ils vont patcher (d’où le -3). Une Fedora sortirait en 3.9.x et se mettrait à jour en restant sur 3.9.X.
4/4 on est pas mal lol.
Beaucoup ingnorent ces fuites et ne se rendent pas compte quils ont des process killés. Ceux qui remontent cela sont rarement des novices et savent un peu prendre la santé de leur système.
Comme je dis je reste focus sur le plugin SMS qui lui est officiel et qui doit être stable avec la distribution debian officielle poussée a savoir la 11.
Je suis surpris malgré ma prudence (debian 11 n’est pas d’hier mais la date butoire de fin de support de debian 10 proche me ‹ force › a upgrader une infra très stable) d’etre confronté a cela.
A quoi peut on s’attendre de la solution jeedom sur le sujet ? Ou faut il feinter le système avec des magouilles qui tôt ou tard referont surface.
J’ai cru que c’étais purement lié à cette version de python 3.9.2
Du coup si je comprend bien il faut cibler uniquement la version 3.9.19 ?
Je vais regarder la procédure décrite sur ce fil, car depuis 1 ans, je relançais tous les process et je trouvais ça pas propre.
Merci
Salut,
J’ai commencé par tester avec python 3.11.x: les plugins se lançaient mais je n’avais plus de remontées d’openenocean.
J’ai ensuite testé avec la dernière release de python 3.9 (3.9.19 donc) et je n’ai pas observé d’anomalie particulière dans le fonctionnement des différents plugins que j’utilise.
Bonjour,
Et bénéficier des autres nouvelles fuites mémoire de python pour Debian 12
C’était un brin d’humour pour signaler qu’avec Debian 12 et python 3.11, il y aurait peut-être d’autres surprises pour le moment pas encore identifiées. Et non corrigées puisque Debian 12 est une version stable…
Je ne connais pas le python, mais n’est-il pas possible de faire cohabiter plusieurs versions ?
J’imaginais par exemple mettre la version 3.9.19 dans un autre répertoire et indiquer ce chemin au plugin xiaomihome par exemple ? Je ne sais pas si c’est faisable, si le plugin n’évolue plus, autant le modifier sans impacter l’OS…
En écrivant ces lignes je me dis que si c’était faisable, ça aurait certainement étudié pour le core jeedom…
Bonjour,
Je suis pas sûr que de mettre à jour le Python du système soit la bonne approche 
Car cela va générer des effets de bords à un moment ou à un autre non souhaités.
il faudrait surtout que l’ensemble des plugins fonctionnent en environnements isolés (avec du PyEnv notamment qui permet de faire cohabiter plusieurs versions de Python) avec là pour le coup la version qu’ils souhaitent de Python (c’est comme cela que fonctionne le plugin TTSCast par exemple, il utilise une version 3.11 de Python, quel que soit l’OS et sa version derrière, donc sur un Debian 10, 11, comme 12).
TiTidom.
EDIT : @jpty le message ne t’ai pas adressé directement, j’ai juste répondu au dernier message lol
Bonjour,
De toute façon à partir de Debian 12 c’est venv obligatoire (à moins de forcer salement).
Mips a travaillé le sujet : SWAP et mémoire saturée - #38 par Mips
Salut @Madcow,
Oui je suis bien au courant, j’ai participé à certaines phases de ces travaux et aux tests avec @Mips 
et je confirme que c’est la bonne solution, le venv + pyenv : Ca permet de s’affranchir de l’ensemble des contraintes des OS et de rester autonome (et donc de choisir exactement ce qu’on va utiliser dans les plugins).
C’est bien pour ca que je l’utilise dans mes plugisn (ttscast et tvremote notamment) : pour être compatible avec toutes les version d’OS et rester le plus autonome possible 
TiTidom.
Bonjour @TiTidom,
Cette solution le venv + pyenv est-il lourd a mettre en place sur un plugin existant ?
Mon idée derrière ça serait de bidouiller le plugin xiaomihome (de façon non officiel) pour ne plus avoir de fuite mémoire lié au python 3.9.2 (en combinaisons avec d’autres bibliothèques).
J’avais coupé le redémarrage de tous mes plugins hier et c’est bien Xiaomihome qui pose vraiment problème chez moi.
Merci TiTidom pour le plugin TTSCast (grace a toi j’ai pu désactivé GoogleCast qui avait aussi une fuite mémoire)
Grace à toi j’ai refais une analyse 1 an après ma migration sur Debian 11 et je vais redémarré que xiaomihome et plus l’ensemble de mes plugins.
Bonne journée
Bonjour @Heliospeed,
Ce qui change, c’est le mode d’installation du plugin, il y a quelques dizaines de lignes de codes (ou la librairie de notre ami Mips qui simplifie encore les choses) à ajouter au script d’install du plugin pour installer pyenv d’une part, la version de python attendue (et si elle est déjà là tant mieux ca fait gagner bcp de temps), le virtualenv (« venv ») et enfin installer les librairies pythons nécessaires au plugin, tout cela dans cet ordre.
Une fois cela fait (dans le script d’install du plugin donc), il faut ensuite aller modifier 2/3 lignes dans le plugin pour modifier la ligne de démarrage du démon, pour faire pointer « python » vers celui que l’on vient d’installer.
Bon, une fois qu’on a dit ca, c’est pas si « simple » qu’il n’y parait, et avant de changer de version de python, il faut s’assurer que les librairies utilisées par le plugin sont compatibles, mais aussi le code, donc ca peut vite devenir un casse tête suivant comment le plugin a été codé
J’aurais pu jeter un oeil rapide, mais de ce que je vois le plugin Xiaomi Home est payant, donc je n’y ai pas accès.
TiTidom.
Bonjour,
Si je regarde mes plugins utilisant python :
Une petite analyse de ma sonde Grafana / Prometheus :
Salut
Sans vouloir lancer une nouvelle polémique ce problème de versions n’est pas limité a python et c’est même inévitable avec l’évolution des releases debian cf par ex ces questions récentes sur php
A mon avis il faudrait dockeriser jeedom ce qui permettrait d’isoler les dependances du core et des plugins en complément des techniques de multi-install des executables comme pour python avec venv:
Réponse la combinaison des 2
Bonjour.
Oui, c’est une bonne idée et en même temps, réserver l’usage de Jeedom qu’aux geek développeurs coca chaud et paninis froid !
