Le fix réseau a bien corrigé le problème de perte d’IPv4, mais les crashs viennent d’autre chose.
En analysant les graphes mémoire et les logs, le système accumule progressivement de la mémoire sur une douzaine d’heures jusqu’à se figer complètement. Le watchdog: watchdog0: watchdog did not stop! dans tes logs indique que c’est le watchdog hardware qui a parfois tenté un reboot automatique depuis le freeze, mais le problème sous-jacent est bien un freeze kernel.
Le suspect le plus sérieux est le plugin Détection de téléphone (Bluetooth) : il scanne en permanence les appareils BT, ce qui stresse le stack Bluetooth kernel. On voit d’ailleurs bluetoothd crasher et redémarrer deux fois en 4 minutes dans tes logs. Ce type de fuite se produit en espace kernel et ne peut pas être compensé par le swap.
Pour confirmer : désactive le plugin Détection de téléphone et observe si les crashs disparaissent. Si c’est stable pendant 48-72h, c’est bien lui le coupable.
PS : avant que tu poses la question, la différence de comportement sur ce point entre l’ancienne et la nouvelle image système se situe au niveau du kernel plus récent, probablement couplé à un usage intensif du Bluetooth sur cette machine.
Ok je vais tenter ça. J’avais déjà fait une tentative en désactivant plusieurs plugins dont phone-detection, mais j’étais avec un système basé sur l’image précédente (12.13).
Est-ce que le supprimer complètement peut aider encore plus ?
Bon j’ai continué à avoir des crashs cette semaine mais pas eu le temps de me pencher dessus. Finalement ce matin je m’aperçois que j’ai effectivement une grosse chute de mémoire libre tous les matins autour de 6h15 ! A l’inverse, après les crashs et reboot la mémoire remonte à un niveau correct (selon moi).
En cherchant partout je vois dans le moteur des tâches que c’est l’heure de ma sauvegarde journalière ! Que puis-je regarder pour savoir pourquoi ça fuit comme ça, comment l’eviter, ou au moins récupérer la mémoire libre après la fin du backup ?
Bon j’ai toujours des crashs réguliers (mais aléatoires) et c’est bien la sauvegarde à 6h qui fait chuter la mémoire libre, pas la copie externe de cloudysnc.
Le PIC était au moment d’un reboot et tu vois que ça passe très très vite en dessous de 10%
Mon swap libre est maintenant plutôt stable depuis que j’ai augmenté la RAM allouée. Avant avec 2 Go ça finissait pas planter. Plus de soucis depuis que je suis passé à 3 Go de RAM
Sauf qu’avec l’ATLAS tu as 4 Go de RAM, 1 Go de swap et une DB bien plus light que la mienne (2,4 Go). Ce n’est pas très logique que ça plante et ton swap n’avait pas l’air de descendre sous les 40%
Est-ce que tu avais analysé ta DB avec un outil type mysqlcheck pour voir s’il n’y avait pas un soucis non visible ?
Est-ce que tu avais eu moyen de tester la mémoire ? J’en avais parlé il y a un moment mais une mémoire défaillante pourrait vraiment occasionner ce problème
je me suis débrouillé comme un grand pour mysqlcheck
jeedom.cache OK
jeedom.calendar_event OK
jeedom.cmd OK
jeedom.config OK
jeedom.cron OK
jeedom.dataStore OK
jeedom.eqLogic OK
jeedom.event
note : The storage engine for the table doesn't support check
jeedom.history OK
jeedom.historyArch OK
jeedom.interactDef OK
jeedom.interactQuery OK
jeedom.listener OK
jeedom.message OK
jeedom.note OK
jeedom.object OK
jeedom.plan OK
jeedom.plan3d OK
jeedom.plan3dHeader OK
jeedom.planHeader OK
jeedom.queue OK
jeedom.scenario OK
jeedom.scenarioElement OK
jeedom.scenarioExpression OK
jeedom.scenarioSubElement OK
jeedom.timeline OK
jeedom.update OK
jeedom.user OK
jeedom.view OK
jeedom.viewData OK
jeedom.viewZone OK
jeedom.widgets OK
Par contre j’ai cru comprendre que pour tester la mémoire avec memtest86 par exemple c’est pus ardu…
Pour la RAM il y a principalement 2 options. En utilisant en effet memtest86+ pour que ce soit plus efficace c’est fait en dehors de l’OS donc en démarrant sur une clef USB par exemple.
Il y a aussi des outils qui tourne sous l’OS (Debian). Tu peux peut-être commencer par là mais normalement c’est moins fiable/efficace : sudo apt install memtester
Après … faudrait pas que ça te fasse sauter la garantie s’il y en a encore une …
On est d’accord que quand je rebooterai ensuite sans la clé USB je retrouverai mon jeedom à l’identique ? (A moins que memtest fasse tout cramer évidemment)
Non j’ai cherché sur le site et il est bien dit qu’il faut avoir la main dessus en direct.
Pour le moment j’ai lancé un memtester comme proposé par @bison , même si c’est moins robuste que memtest87 je verrai déjà ce que ça donne.
Cette RockPi dispose également d’un port HDMI, que Jeedom a pris la décision de dissimuler dans le boitier. Un choix qu’on comprendra, cette box n’ayant pas pour but d’être branchée sur un écran de toute façon. Et esthétiquement, cela permet d’épurer le design au maximum.
J’ai lancé un premier memtester sur 2Go et j’ai aucune erreur. Je vais en relancer régulièrement pour augmenter la probabilité de tester toute la mémoire.
. Tu saurais me guider?
