Interface Jeedom inaccessible (mais ping OK)

[Rdu]

Bonjour à tous,

Je vous remercie par avance pour le temps que vous m’accorderez et désolé pour le format du message, j’essaie de faire ça bien mais je rate surement des choses (évidemment preneur de vos bons conseils).

Je suis récemment passé sur la nouvelle version de Jeedom (4.4.19) et ceci après avoir refait une installation propre en passant sous Debian 11.11. Ayant essuyé quelques difficultés pour refaire fonctionner certains plugins (merci d’ailleurs la communauté pour tous les sujets déjà ouverts qui m’ont bien aidé !!), tout refonctionnait à merveille.

Trois jours plus tard, Jeedom planté ! (pas d’accès à la page web, pas d’accès par SHH et pas de réponse au ping en local …). Je mets cela sur le dos de la box internet et après un Hard reset, ça refonctionne. Puis de nouveau quelques jours plus tard, plus d’accès à la page Web de Jeedom mais ping OK et SSH OK (les scenarios et autres acquisitions ont continué de fonctionner), je relance donc Jeedom par un « Reboot » via SSH.
Dans les quelques log que je sais voir (j’utilise Jeedom depuis 2021, je n’ai jamais eu de problème donc peu l’habitude de chercher dans les logs) je ne voir rien d’anormal.

Puis cette nuit, plantage de nouveau (après une dizaine de jours sans problème). Page web inaccessible, SSH NOK mais Ping OK, le hard reset me permet de relancer Jeedom. En regardant les logs et les acquisitions, Jeedom s’est complétement arrêté vers 2h40.

En regardant le log « event », deux choses m’interpellent :

[2025-01-19 02:39:58][INFO] : Evènement sur la commande [Energie][Energie Electrique][Tension] valeur : 242.5V
[2025-01-19 02:17:41][INFO] : Local account found for admin
[2025-01-19 02:17:41][INFO] : User connection accepted admin
[2025-01-19 02:17:41][INFO] : Local account found for admin
[2025-01-19 02:17:41][INFO] : User connection accepted admin
[2025-01-19 02:18:05][INFO] : Evènement sur la commande [Equipements][Info du jour][Phase de la lune] valeur : 0.67

1 : La chronologie, on passe de 2:39:58 à 2:17:41
2 : L’évènement à 2:17:41 User connection … je ne me suis pas connecté cette nuit !!

Dans le log « http error » (en image car nombre de lignes important):

Deux lignes à environ le même horaire que le « user connection »

0500|[Sun Jan 19 02:17:12.371327 2025] [mpm_prefork:notice] [pid 625:tid 625] AH00163: Apache/2.4.62 (Debian) OpenSSL/1.1.1w configured -- resuming normal operations
0501|[Sun Jan 19 02:17:12.372526 2025] [core:notice] [pid 625:tid 625] AH00094: Command line: '/usr/sbin/apache2'

Je vous joint la page santé (les 2 mise à jour sont récentes, les premiers problèmes sont apparus avant) :

Avez vous une idée de ce qui pourrait engendrer ce plantage de Jeedom ? En vous remerciant grandement pour votre aide.

Rémi.

[Mips]

Bonjour,

Je n’ai pas les liens sous la main mais cherchez sur « swap » et « journald »
Il y a plusieurs sujets similaires au vôtre et il y a une config à optimiser

[Rdu]

Bonjour Mips,

Merci pour cette réponse. J’ai regardé du coté du SWAP. j’ai commencé par historiser l’info afin de voir si au bout d’un moment le SWAP dispo diminue fortement et également la RAM, à suivre … Je suis sur un Rasp 3B+, j’ai bien suivi lors de l’installation de Debian les préconisations pour optimiser Jeedom (augmentation du Swap, limitation du journal, …)

J’ai remarqué également cela dans le log « cron_execution » :

2h18 : « Starting Jeedom » suivi d’un certain nombre de lignes notifiant « time stamp is xxx s in the futur » … je trouve cela bizarre.

Reste après à savoir si ce n’est pas un problème matériel : Msata ou interface USB en fin de vie (après seulement 4 ans cela serait dommage) ou alimentation un peu faiblarde. Cela arriverai pile au moment ou je décide de passer sous Debian 11 ?

Voyons déjà l’analyse du Swap et de la RAM.

Rémi.

[hlehoux]

Vous avez une base de donnée avec une taille énorme. Peut-être ça serait un problème, sur un pi3b+ assez ancien.

peut être un sujet d’historique de commandes

vousd avez de l’aide ici: Tuto - analyser les archives pour détecter des pbs (lenteurs / espaces disques)

[Rdu]

Bonjour hlehoux,

Merci pour cette réponse, je ne me rends pas compte si cela est énorme ou pas pour une base de données. Pourtant j’ai activé l’option de purger l’historique si plus vieux que 2 ans, le lissage des données, … Peut être un nettoyage de la BDD a lancer tout de même !

Je vais étudier le topic que vous m’avez envoyé.

Petit point sur l’analyse de la RAM et du Swap :

Rien d’alarmant j’ai l’impression, sauf la RAM libre un peu faiblard mais comme ça depuis le reset. A voir si dans quelques jours le Swap diminue encore.

Bonne soirée à tous
Rémi.

[hlehoux]

C’est normal sous linux d’utiliser la RAM disponible, et votre PI 3B+ n’en a pas des grosses réserves, donc ok.
Vos autres paramètres ne sont pas &anormaux je pense.

par contre j’ai rarement vu une base jeedom aussi grosse (de l’ordre de grandeur 50x plus que la mienne) ; vous devez historiser beaucoup de commandes avec une grande fréquence. le tuto vous aidera

[Rdu]

Bonjour hlehoux,

Le swap est stable à ce matin, il oscille entre 50 et 60%.
Concernant la BDD, j’ai fait du tri dans les commande historisées. Et en effet vous aviez raison, j’avais oublié d’activer le moyennage sur 6 commandes (dont la fréquence d’acquisition est de 10s )

De ce fait, à 5h du matin, le moyennage c’est bien passé sur ces commandes par contre, que sur les dernières 24h, comment faire pour que le moyennage se fasse aussi sur l’historique complet ?

Merci !

Rémi.

[hlehoux]

Désolé, je ne me rappelle plus ; j’avais suivi le tuto pour réduire la DB ; dans analyse/historique il y a des outils

[Rdu]

Bonsoir hlehoux,

Après avoir suivi le tuto, la taille de la BDD est divisée par 2 ! (bon, oui elle reste tout de même à 600 MB mais bon, c’est toujours mieux , je poursuivrais l’optimisation un peu plus tard)

Le Swap est toujours stable aux environs des 60%.

Je ne sais pas si tout cela permettra d’éviter le freeze de Jeedom néanmoins cela ne peut pas faire de mal.

Merci pour ces conseils

Petite question bonus : dans le moteur de taches, j’ai vu que le cron Daily qui s’exécute à 2h33, a une durée d’exécution de 604s. Que se passe-t-il durant cette taches qui nécessite tout ce temps ?

Rémi.

[hlehoux]

@Rdu

Petite question bonus : dans le moteur de taches, j’ai vu que le cron Daily qui s’exécute à 2h33, a une durée d’exécution de 604s. Que se passe-t-il durant cette taches qui nécessite tout ce temps

Malheureusement cela dépasse mes compétences ; j’ai regardé sur mes 2 installations , sur le PI4 il prend 70s, et sur mon nouveau PI5 02s

Vous avez déjà bien diminué votre DB ; mais c’est encore de l’ordre de 10x plus que les tailles courantes ; ça fait beaucoup pour un RPI3

Peut-être pouvez vous partager le résultat du script d’analyse, il y a quelques experts sur ce forum, comme @ngrataloup , qui pourront sans doute donner des conseils pertinents.

Ca vaudrait également le coup de faire une fresh installation de jeedom sur une autre carte SD en test (pour ne pas détruire votre système existant) et voir si vous arrivez à faire une restauration

[ngrataloup]

@Rdu

bon, oui elle reste tout de même à 600 MB mais bon, c’est toujours mieux , je poursuivrais l’optimisation un peu plus tard

600MB c’est encore beaucoup trop … visez 100MB
Ceci peut avoir 2 impacts :
1 - les opérations sur la base sont beaucoup plus longues, et necessitent beaucoup d’accès en ecriture sur les disques … pendant ce temps, votre jeedom est saturé
2 - vous devez avoir des commandes très bavardes et qui du coup mobilisent beaucoup d’ecritures en base … qui saturent la base.

… CQFD, faut optimiser !

pour le pb initial, RPI 3B+ et debian 11 en 64bits … je sais, certain diront que le 3B+ n’ai pas concerné par le spbs de plantage aléatoire … je l’ai constaté à plusieurs reprises, donc pour moi, reinstall d’une Raspian 11 LITE en 32bits pour regler le pb !
(les RPI 3, 3B et 3B+ ont des plantages aléatoires si on installe un debian 64bits malgré leur compatibilité annoncée en 64bits)

Norbert

[hlehoux]

Et pour la durée du cron daily, comme il comprend de faire des optimisations de la DB, c’est logique qu’il prenne bcp de temps

[Rdu]

Bonjour hlehoux, ngrataloup,

J’ai encore optimisé l’historisation hier soir, jeedom a fait son petit travail nocturne et ce matin miracle, la data base est descendue à 82 MB !! Je remarque une nette amélioration de la fluidité du chargement des pages de Jeedom. Le cron daily s’est exécuté pendant seulement 28s et le cron history pendant 44s.

Concernant le point sur la version de debian, avant de passer en 11 64 bits, j’étais sur du 10 64 bits depuis 3 ans … Sans aucun soucis de plantage.
Pour l’heure je vais laisser vivre jeedom avec cette nouvelle optimisation de la database pour voir s’il y a de nouveau des problèmes de stabilité, si c’est le cas, j’envisagerais un passage sous debian 11 32 bits.

Encore merci pour vos précieux conseils, j’ai appris beaucoup grâce à vous.

Rémi.

[ngrataloup]

Super, Laisse effectivement tourner. Je pense que la durée du cron history va encore baisser puisqu’il a du la nuit dernière proceder à pas mal d’opérations de purge.
Tu peux aussi faire maintenant un nettoyage de base (configuration >> _OS/DB)

Et dernier point, quand tu interpelles quelqu’un, mets un @ devant pour qu’il soit notifié de ta réponse @Rdu

[Rdu]

@ngrataloup nettoyage de base déjà lancé !

(Et merci pour la bonne pratique du tag )

Je vais attendre quelques jours avant de marquer le sujet comme solutionné.

Rémi.