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
1 « J'aime »
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 :
- Reboot afin d’avoir les services qui plantent et rechargent leurs dépendances.
- Pour fail2ban :
$ cd /usr/local/lib/python3.9/site-packages
$ ln -s /usr/lib/python3/dist-packages/fail2ban* ./
$ service fail2ban restart
$ service fail2ban status
2 « J'aime »
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
2 « J'aime »
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