[RESOLU]Mémoire disponible en baisse depuis passage en V4

Bonjour à tous,

Jusqu’à pas très longtemps, j’étais encore sous Jessie avec un jeedom V3 qui tournait pas trop mal (mais étant novice, j’avais peur de refaire une install propre).

Je me suis enfin décider à me mettre à la page en mettant à jour mon OS sur mon RPI 3+ (car j’avais régulièrement des kernel panic sans comprendre d’où cela pouvait provenir).
→ Je suis maintenant sous Buster + jeedom V4.

Après 2 jours (j’ai migré le 25/01 au soir), j’ai quelques messages d’erreurs et constats qui m’inquiètent :

  1. Dans mon rapport « Jeedom Watcher » que je reçoit (qui n’apparait plus d’ailleurs dans le Market, je pense qu’il n’est plus compatible V4), j’ai ce message d’erreur « Attention le répertoire tmp n’est en mémoire »
  2. Au niveau de ma page Santé, j’ai la ligne « mémoire disponible » qui baisse rapidement (ici 39%)
  3. Mon historique de la mémoire confirme que j’ai un soucis depuis l’installation
  4. Dans le log cron_execution, je vois ces messages générés lors de l’installation
2021-01-25 20:47:03 starting Jeedommkdir: cannot create directory ‘/tmp/jeedom/cache’: File exists
Enable scenario : OK
Enable task : OK
[Erreur] scenario::check() : [MySQL] Error code : 42S02 (1146). Table 'jeedom.scenario' doesn't exist  : SELECT `id`, `name`, `isActive`, `group`, `mode`, `schedule`, `scenarioElement`, `trigger`, `timeout`, `object_id`, `isVisible`, `display`, `order`, `description`, `configuration`, `type`
FROM scenario
WHERE `mode` != "provoke"
AND `mode` != ""
AND `schedule` != ""
AND isActive=1
PHP Fatal error:  Uncaught InvalidArgumentException: The directory "/tmp/jeedom/cache" is not writable. in /var/www/html/vendor/doctrine/cache/lib/Doctrine/Common/Cache/FileCache.php:92
Stack trace:
#0 /var/www/html/vendor/doctrine/cache/lib/Doctrine/Common/Cache/FilesystemCache.php(37): Doctrine\Common\Cache\FileCache->__construct('/tmp/jeedom/cac...', '.doctrinecache....', 2)
#1 /var/www/html/core/class/cache.class.php(116): Doctrine\Common\Cache\FilesystemCache->__construct('/tmp/jeedom/cac...')
#2 /var/www/html/core/class/cache.class.php(146): cache::getCache()
#3 /var/www/html/core/class/cron.class.php(575): cache::byKey('cronCacheAttr32...')
#4 /var/www/html/core/class/cron.class.php(490): cron->setCache('state', 'error')
#5 /var/www/html/core/php/jeeCron.php(148): cron->setState('error')
#6 {main}
thrown in /var/www/html/vendor/doctrine/cache/lib/Doctrine/Common/Cache/FileCache.php on line 92
PHP Fatal error:  Uncaught InvalidArgumentException: The directory "/tmp/jeedom/cache" is not writable. in /var/www/html/vendor/doctrine/cache/lib/Doctrine/Common/Cache/FileCache.php:92
Stack trace:
#0 /var/www/html/vendor/doctrine/cache/lib/Doctrine/Common/Cache/FilesystemCache.php(37): Doctrine\Common\Cache\FileCache->__construct('/tmp/jeedom/cac...', '.doctrinecache....', 2)
#1 /var/www/html/core/class/cache.class.php(116): Doctrine\Common\Cache\FilesystemCache->__construct('/tmp/jeedom/cac...')
#2 /var/www/html/core/class/cache.class.php(146): cache::getCache()
#3 /var/www/html/core/class/cron.class.php(575): cache::byKey('cronCacheAttr32...')
#4 /var/www/html/core/class/cron.class.php(490): cron->setCache('state', 'error')
#5 /var/www/html/core/php/jeeCron.php(148): cron->setState('error')
#6 {main}
thrown in /var/www/html/vendor/doctrine/cache/lib/Doctrine/Common/Cache/FileCache.php on line 92
warning: commands will be executed using /bin/sh
job 1 at Mon Jan 25 19:58:00 2021
/var/www/html/plugins/googlecast/core/class/../../resources/install_check.sh: line 24: echo: write error: Broken pipe
warning: commands will be executed using /bin/sh
job 2 at Mon Jan 25 20:00:00 2021
warning: commands will be executed using /bin/sh
job 3 at Mon Jan 25 20:00:00 2021
warning: commands will be executed using /bin/sh
job 4 at Mon Jan 25 20:05:00 2021
warning: commands will be executed using /bin/sh
job 5 at Mon Jan 25 20:05:00 2021
2021-01-25 21:07:03 starting Jeedom
Enable scenario : OK
Enable task : OK
warning: commands will be executed using /bin/sh
job 6 at Mon Jan 25 20:08:00 2021
2021-01-25 23:32:03 starting Jeedom    Enable scenario : OK
Enable task : OK
sh: 1: cannot create /var/www/html/core/class/../../log/cloudsyncpro.#5070: Permission denied
sh: 1: cannot create /var/www/html/core/class/../../log/cloudsyncpro.#5071: Permission denied
sh: 1: cannot create /var/www/html/core/class/../../log/scenarioLog/scenario164.log: Permission denied

J’ai pourtant suivi le manuel d’installation Jeedom en repartant d’une installation vierge et je n’avais pas ce pb avant.
Voici ce que j’ai fait :

  • Utilisation de Raspberry PI Imager pour installer l’OS sur une carte SD neuve et sur un SSD
  • Modification du fichier config.txt pour permettre de booter sur le SSD
  • Retrait de la carte SD et boot sur le SSD (avant je bootais sur la SD et j’avais jeedom sur un SSD)
  • Installation de jeedom V4 (sur le SSD donc) en suivant les instructions jeedom (j’aurais dû peut-être installer Jeedom V3 vu l’étape d’après, je n’y ai pas pensé sur le coup)
  • Restauration de ma sauvegarde Jeedom faite en V3
  • Mise à jour de jeedom pour repasser en V4
    → Depuis donc j’ai tout retrouvé (en plus beau :slight_smile:

Ce message de pb d’écriture sur le « /tmp/jeedom/cache » est sûrement une piste mais je ne comprends pas ce que j’ai fait de mal ou ce que j’ai oublié de faire.

Avez-vous déjà eu ce type de pb ? Auriez-vous une piste ?

Merci à tous par avance !

Bonjour

Quel modification avez vous pu bien faire pour dire à votre Raspberry Pi3B+ pour booter sur SSD ?
=> Car il sait le faire nativement !

Pour l’installation en v4, vous n’avez pas le choix, vous avez bien fait, c’est comme cela qu’il faut faire.

Je ne comprend pas vos problèmes, quel tutoriel avez vous suivit pour faire cette installation ?

Merci Fabrice de vous intéressé à mon pb.
Voici la procédure d’installation que j’ai suivi : https://doc.jeedom.com/fr_FR/installation/rpi
Voici le tuto que j’ai suivi pour booter sur le SSD :
→ J’ai donc passé la commande

program_usb_boot_mode=1

Je ne vois pas le tutoriel, ce qui est certain, c’est que cela ne sert à rien, un Raspberry Pi3B+ sait nativement booter sur les ports USB.

Il y a une charge importante sur votre PI. Vous avez beaucoup d’équipements ? de scénarios ?

Du coup, cette commande « program_usb_boot_mode=1 » peut être à l’origine du pb ou juste, je l’ai passé pour rien ?

D’après le résumé domotique, j’ai 104 équipements et 90 scénario (mais aucun qui tourne en continue à ma connaissance). Ce nombre n’a pas changé par rapport à mon installation en V3 et je n’ai pas téléchargé de nouveaux plugins à l’occasion de la migration.
Que pensez-vous des messages d’erreur concernant le cache ?

Je pense que la commande est la pour rien, supprimez la et redémarrez.

D’après vos informations, vous ne devriez pas du tout avoir cette charge. Vous devez avoir des conneries sur votre installation (des scénarios mal écrit, un plugin pas compatible ect…)
Vous n’avez pas mis de nouveau plugin, mais peut être un TRES vieux qui n’est pas compatible (pas maintenue surtout).

Il faut tester maintenant.

Désactivez vos scénarios (un bouton permet cela en 1 clic) attendez 15 minutes et analysez

Désactivez la moitié de vos plugin tester après 15 minutes
L’autre motié…

Et faire un point (mais redémarrez avant).

Merci beaucoup Fabrice, je vais tester tout cela.
Donc pour vous, les messages d’erreur sur les pb d’accès au répertoire du cache ne sont pas problématiques ?

Vous indiquez qu’il faut attendre 15 min. Comment pourrais-je voir que la charge diminue bien ?
Via cet indicateur de la page santé de jeedom ?
image

Oui, ou via le plugin Monitoring, celui qui a l’icône violet.

Merci Fabrice !

Quelle devraient les valeurs d’une charge normale ? < 0 ? < 1 ? < 2 ?

Inférieur à 1.
Mais cela dépend de votre matériel.

Faites cela aussi :
sudo nano /boot/config.txt

Aller à la fin du fichier et ajouter les 2 lignes suivantes :

# Désactivation de la recherche permanente d'une carte MicroSD (et arrêt de la LED)
dtparam=sd_poll_once

Ctrl + o pour sauver
Ctrl + x pour quitter

Puis :
sudo reboot

Je viens de le faire, on va voir ce que cela donne, merci encore !. Par contre je viens de modifier le fichier et rebooter et j’ai toujours la led rouge allumée.

En attendant, hier soir, j’ai désactivé tout mes scénario et je n’ai laissé que 3 plugins : Z-Wave, Camera et ESPeasy et j’ai déjà perdu 10% de mémoire disponible ce matin alors que ces plugins me semblent indispensables :frowning:

Je viens de voir aussi que j’avais aussi cette erreur dans la log openzwave

Unhandled exception in thread started by <bound method _Timer.__bootstrap of <_Timer(Thread-140936, stopped daemon 1854927968)>>
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 774, in __bootstrap
self.__bootstrap_inner()
File "/usr/lib/python2.7/threading.py", line 789, in __bootstrap_inner
del _limbo[self]
KeyError: <_Timer(Thread-140936, stopped daemon 1854927968)>
[2021-01-28 05:39:17][ERROR] : Critical error on  send_changes_async threads can only be started once
Unhandled exception in thread started by <bound method _Timer.__bootstrap of <_Timer(Thread-298351, stopped daemon 1846535264)>>
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 774, in __bootstrap
self.__bootstrap_inner()
File "/usr/lib/python2.7/threading.py", line 789, in __bootstrap_inner
del _limbo[self]
KeyError: <_Timer(Thread-298351, stopped daemon 1846535264)>

Je ne sais pas si c’est grave…

La led rouge, cela signifie qu’il y le courant sur le Raspberry Pi (normal donc).

Pour le message d’erreur Z-Wave, c’est un message que nous avons tous, il est sans conséquence. Il faut, dans les LOGS, supprimer ce fichier de log (et pas le vider). Ainsi, cette erreur ne sera plus visible.
Mais s’il devait y avoir une autre vraie erreur, le fichier va alors se créer tout seul.

Vous pouvez même, après un redémarrage de Jeedom, supprimer l’ensemble de fichiers de logs. Cela permet d’y voir plus clair (ils se créeront seuls en cas de nécessité).

Alors, que donne la charge depuis le plugin Monitoring ?

Et la mémoire ?

Encore merci Fabrice pour vos retours express !!
Je viens de supprimer le fichier log openzwave comme indiqué : je n’ai plus qu’à surveiller si l’erreur revient (ou une autre).

Pour la charge, comme j’ai désactivé le plugin désactivé, je n’y ai pas accès mais,depuis le passage de la commande « dtparam=sd_poll_once », la page santé de jeedom indique que la charge semble être repassée sous 1 (sauf le premier chiffre qui de temps en temps repasse provisoirement au dessus de 1)

A ce propos, à quoi correspond les 3 valeurs de la ligne « charge » ?

Je vais donc surveiller quelques heures et voir si cela reste stable puis si c’est le cas, je réactiverai progressivement les autres plugins en commençant par Monitoring. Je croise les doigts et je vous tiens au courant bien sûr !

Sinon pas d’idée pour le pb d’accès au répertoire « /tmp/jeedom/cache » ?

Encore merci !

@Fabrice, alors la bonne nouvelle c’est que la charge semble restée stable (< 1). Par contre, la mémoire disponible (je ne sais pas trop à quoi cela correspond) diminue de nouveau (-4% depuis le reboot de ce matin). Pour rappel, la nuit dernière, j’ai perdu plus de 10%

Je ne connais pas trop comment fonctionne la gestion de la mémoire mais j’étais stable (autour des 68%) avant ma migration en V4 et la mise en place du boot sur le SSD donc je pense que j’ai encore un pb quelque part :frowning:

Bonjour,

Quel problème de /tmp/ si c’est juste au démarrage, c’est normal.

68% de mémoire libre, c’est vraiment beaucoup. Moi je suis plutôt vers les 40%

Supprimez l’ensemble de vos logs comme je vous l’ai suggéré et faites un point si vous avez d’autre erreur (cette histoire de /tmp ?)

Oui le pb /tmp/ c’était au démarrage, me voilà rassuré sur le point, merci !!!
Coté log, je n’ai quasiment rien (car j’ai un peu vidé).
Coté erreur, je ne vois que ces points rouge dans la vérification des packages.

Mais je ne sais pas à quoi servent ces pakages, faut-il que je corrige ces erreurs ?

Non, vous ne corrigez pas non plus.
C’est des contrôles qui, je pense, n’ont pas d’importance pour pratiquement tout le monde.

Je ne l’ai pas fait non plus.