Plus d'acces à Jeedom le matin un jour sur deux depuis deux jours!

OK effectué la commande

Au reboot :

pi@jeedom:~ $ reboot
Failed to set wall message, ignoring: Interactive authentication required.
Failed to reboot system via logind: Interactive authentication required.
Failed to open initctl fifo: Permission denied
Failed to talk to init daemon.
pi@jeedom:~ $

Je vais arrêter le RPI par Jeedom.

@naboleo

Pour info :
Au moment du reboot (Failed) du RPI j’ai eu ça dans le log http.error :
Je ne sais pas si c’est intéressant comme info !

[Tue Nov 24 20:29:46.261274 2020] [core:notice] [pid 589] AH00052: child pid 27550 exit signal Segmentation fault (11)
[Tue Nov 24 20:29:46.526297 2020] [core:notice] [pid 589] AH00052: child pid 12224 exit signal Segmentation fault (11)
[Tue Nov 24 20:29:46.526939 2020] [core:notice] [pid 589] AH00052: child pid 642 exit signal Segmentation fault (11)
[Tue Nov 24 20:29:46.527667 2020] [core:notice] [pid 589] AH00052: child pid 2515 exit signal Segmentation fault (11)
[Tue Nov 24 20:29:46.527882 2020] [mpm_prefork:notice] [pid 589] AH00169: caught SIGTERM, shutting down
[Tue Nov 24 20:29:59.410347 2020] [mpm_prefork:notice] [pid 590] AH00163: Apache/2.4.38 (Raspbian) configured -- resuming normal operations
[Tue Nov 24 20:29:59.412590 2020] [core:notice] [pid 590] AH00094: Command line: '/usr/sbin/apache2'

Et merci pour le temps passé pour essayer de régler mon Pb.

Le reboot raté, c’est normal, tu es pas root donc sans sudo, ça fonctionne pas en ligne de commande.
Quant aux erreurs dans apache, si c’est avant le reboot, on s’en fiche un peu => reboot c’est un peu sauvage
Là en théorie, ton swappiness est à 10.

Pour @jpp38 JPP38, toutes les commandes Linux qui nécessitent les droits d’administration, doivent être précédées de sudo dans une session normal (ce qui est une bonne pratique)
Pour le reboot, il faut donc saisir ;
sudo reboot

Pour les lignes d’Apache dans la log de Jeedom, nous devons tous avoir cela au redémarrage de Jeedom.

@Fabrice,

Merci encore pour ces précisions
Salutations

Jean-Paul

@naboleo,

Oui le swappiness est à 10


Merci beaucoup pour le temps consacré a régler ce Pb de swappiness.
Salutations

2 « J'aime »

Bonjour à tous,

Après avoir corriger hier le swap et le swapiness de mon système (conseil de @iPapy) et l’aide précieuse de @naboleo, @Fabrice, @lone,ce matin mon Jeedom est encore planté (un jour sur deux).
Je constate dans un premier temps le blocage de Jeedom car ma femme va sur l’application mobile et pas d’accès !
J’ai fais les manip suivantes :
Ping de mon RPI résultat OK
Acess SSH résultat OK
Dans l’administration de la Freebox le RPI est actif.
Avec mon navigateur (Firefox V 83) je me connecte sur Jeedom et j’ai le message comme avant hier : SQLSTATE[HY00][2002] Connection refused.
Jeedom a l’air de fonctionné car je reçois des SMS de mes scénarios ?
Le seul moyen pour retrouver l’accès à mon Jeedom c’est de couper l’alim du RPI 3B+ et je balise chaque fois !

Bonjour @jpp38

Pour ma part, toujours pas de soucis ce matin.
Log http.error vide et système parfaitement fonctionnel.

J’ai eu le même soucis que toi une seule fois finalement.

A ta place, je refais une fresh install afin de repartir via un backup qui fonctionne.

Avec la nouvelle procédure d’installation de Jeedom, je n’hésite plus pour ma part.
En cas de plantage suite à une mauvaise manip’ ou à des tests de plugins par exemple, je réinstalle tout en quelques minutes et ça fonctionne à merveille !

Bien sûr, ça n’explique pas ce qu’il s’est passé mais ça vaut le coup d’essayer vu que chez moi tout est stable, et qu’on a la même config’.

Bonne journée!

Bonjour @Xboss06,

Merci du message

Si ça continue je crois que ça va finir par une fresh install !
Salutations

Hello

Là ce message n’a rien à voir avec le swappiness ou le reste. C’est un souci de base de données.
Support HS (ça arrive aussi sur les SSD, surtout avec un débranchement electrique) ou contenu de la base corrompue.
L’explication que j’ai en tête, c’est que lors du processus de sauvegarde comme on accède à toute la base, alors ça plante.
Et il est probable que certaines parties du fonctionnement, n’ai pas besoin d’un accès en base (du moins dans la zone pourrie) et qu’ils fonctionnent donc.

Le problème c’est que si la base est sauvegardé corrompue, peu importe la méthode de réinstallation, le backup risque d’avoir les même soucis.
La seule piste qui me semble intéressante, c’est

  • tenter de faire une vérification de la base et un nettoyage des données
  • chercher dans tous les logs jeedom s’il n’y a pas un indice, y compris les scénario
  • faire le nettoyage des historiques
3 « J'aime »

Bonjour @naboleo,

Merci pour la réponse.

Je suis bien conscient que ce message n’a rien à voir avec le swappiness.
Et merci encore de l’aide apportée hier pour régler ce Pb
Je vais tenter :
1- Une vérification de la base
2- Un nettoyage des données comme proposé.

@naboleo

Vérification de la base de données : tout est Ok (vert)

Nettoyage de la base de données : Nettoyage lancé avec succès. Pour suivre l’avancement merci de regarder le log cleaningdb

Je regarde

Ah tiens, je ne sais pas si c’est un hasard, mais l’heure m’interpelle un peu car c’est la 17ième minute !

Cela fait des mois que j’ai toujours le souci du Jeedom planté et complètement inaccessible de façon aléatoire de temps en temps.

Ouais, mais impossible de le faire à distance.

Ha oui…là ça devient franchement problématique effectivement!

@naboleo

J’ai pas mal fouiné dans les logs de Jeedom, les scénarios rien trouvé comme indice !
J’ai aussi nettoyé les historiques
@Domatizer, @Xboss06 Merci pour ces infos !
je vois que je ne suis pas le seul à avoir ce problème ?

Et c’est toujours mieux de ne pas être tout seul dans la galère…

Est-ce que tu peux regarder tes fichiers log dans /var/log pour voir si le Pi a redémarré de lui-même avant que Jeedom ne se mette en rade si tu vois des lignes comme ceci ?

Nov 17 19:34:48 RPi4b-Jeedom kernel: [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd083]

Ça c’est sûr :+1:
De mon côté, rien d’anormal dans les logs (pas de redémarrage auto)

J’ai lu avec intérêt ton topic (très technique) qui expose ton problème, vraisemblablement lié à un soucis d’horloge.
Tu as pu avancer un peu ou c’est toujours pareil ?

Bonne nouvelle pour toi.

Oui et non. En remettant tout sur la carte SD à la place du SSD, je croyais être sorti d’affaire puisque le système a tenu 2 mois. Mais là, j’ai eu 3 plantages complets en quelques jours : il n’y a plus rien qui marche.
Je pense plus à un problème hardware, il faudrait que je teste une autre alim, un autre Pi et un autre hub USB. Je n’ai pas très envie de racheter encore du matériel inutilement.

Je suis en train d’essayer les idées de @naboleo. Je croise encore les doigts…

1 « J'aime »

Une piste a ne pas négliger, l’alimentation du rpi qui est peut etre limite et, en fonction du nombre de periph USB , peut disjoncter !!! Prevoir une 3A .

Vous avez fait ça ?