Plantage nocturne jeedom

Bonjour à tous,

je suis actuellement sur une version jeedom 3.3.39 installée sur un Raspberry Pi 3B.
Depuis quelques mois, je constate un plantage aléatoire de mon système certaines nuits.
Je m’explique :

  • certains matins, je constate que ma jeedom ne répond plus
  • impossible d’accéder à la mire de connexion de jeedom (même via l’IP directe)
  • je ne vois plus jeedom connecté sur mon interface d’administration de mon routeur
  • ma clé USB Z-Waze Z-Stick Gen5 relié au boitier clignote normalement par contre.
  • après redémarrage électrique du raspberry, jeedom se relance normalement et je vois que mes scénarios de la nuit ne se sont pas déclenchés (et que la sauvegarde automatique jeedom de 2H ne s’est pas faite par exemple)
  • mes variables heliotrope sont parfois vides donc je pense que le plugin n’a pas été déclenché (mais je ne sais pas à quelle heure il se met à jour d’habitude)
  • tout mon jeedom et plugins est à jour.
  • je peux passer 2 semaines sans avoir de problème et parfois, je peut avoir le pb au bout de 3 jours.
  • l’heure du plantage dans la nuit semble être aléatoire
  • je ne constate rien d’anormal la veille dans l’onglet santé (je le surveille régulièrement du coup)
  • à noter que j’avais déjà le problème en version 3.3.24

N’ayant pas pu isoler un moment/événement particulier ni de trace log jeedom me mettant sur la piste, je fais donc appel au forum pour savoir si cela parle à quelqu’un ou si vous auriez une procédure d’analyse qui me permettrait de comprendre d’où vient le pb.

D’avance merci pour votre aide.

Desactive le backup quelques jours pour voir si ça ne vient pas de la

Quand elle plante arrives-tu encore à te connecter en ssh ?

Je pense que tu devrais regarder les logs dans debian car si la box ne réponds plus du tout, c’est plus sous linux que tu verras si tu as eu un kernel panic ou un freeze ce genre de chose.

OK merci pour cette proposition rapide, je vais faire cela.

Bonjour,

tout d’abord, un grand merci à toi pour ta réponse rapide !
une fois en ssh (si cela répond), pourrais-tu me donner les commandes à passer pour avoir les infos (je suis novice sous Linux) ?

Un peu de lecture :wink:

https://wiki.debian-fr.xyz/Consulter_les_logs_:_quoi,o%C3%B9_et_comment_chercher%3F

je commencerai par celui là /var/log/dmesg
more /var/log/dmesg une fois connecté ou même maintenant car si il y a eu plantage c’est forcement ecrit dans les logs

Apres assure toi que la box ne chauffe pas… ca peut etre cela aussi

Bonjour et bonne année à tous.
Juste pour vous signaler que depuis que j’ai désactivé la sauvegarde automatique le 26/12, je n’ai pas eu de plantage. Je vais continuer à surveiller encore quelques jours avant de conclure que le pb venait de là. Si c’est le cas, je ne comprends pas trop pourquoi mais attendons encore… je vous tiendrais au courant.
En tout cas, merci pour vos infos qui me permettent d’en apprendre tous les jours :slight_smile:

Alors, il suffisait de dire que le pb a disparu pour qu’il revienne.
Je viens d’avoir un nouveau plantage (mais en pleine journée).
Quelques compléments d’infos:

  • après plantage, impossible de me connecter en ssh

Après redémarrage du rbpi:vers 19H06 :

  • j’avais créé un scenario qui se déclenchait toutes les 30 min et je vois dans la log qu’il s’est exécuté pour la dernière fois à 10H30 puis plus rien
    image
  • ci-joint les traces lorsque j’ai pu récupérer (par contre je n’ai pas réussi à lire le dmesg)
    dmesg.txt (47 Octets)
    messages.txt (97,2 Ko)
    kern.log (145,6 Ko)
    syslog.txt (86,8 Ko)
  • ce qui est étrange c’est que malgré l’arrêt du scenario après 10H30, je me rappelle que j’ai pu me accéder au dashboard jeedom après 14H mais ce n’était plus possible à 16H30.
  • Certains fichiers log s’arrêtent à 10H17 et d’autres continuent d’écrire
  • dans le fichier syslog, la chronologie des écritures n’est pas correcte (j’ai des lignes à 13H26 avant celles de 10H17) mais c’est peut être parce que j’ai ouvert les fichier avec la commande ‹ cat ›

En synthèse, j’ai l’impression qu’il s’est passé qq chose à 10H17 mais que le rbpi a continué à fonctionner partiellement avant de planter complètement plus tard.

Par exemple dans le fichier daemon.log

Perso, je suis perdu et je ne sais pas lire les log.
→ Quelqu’un pourrait-il m’aider à détecter le pb via les logs ?

peut-etre ici dans le fichier kern.log (j’ai une Internal error: Oops: 5 [#1] SMP ARM) ?

Jan  7 10:29:12 jeedom ovpn-client[365]: UDPv4 link remote: [AF_INET]164.132.45.159:1194
Jan  7 10:30:01 jeedom CRON[15890]: (root) CMD (/usr/bin/php /var/www/html/install/update/../../core/php/watchdog.php >> /dev/null)
Jan  7 10:30:01 jeedom CRON[15893]: (root) CMD (su --shell=/bin/bash - www-data -c '/usr/bin/php /var/www/html/core/php/jeeCron.php' >> /dev/null)
Jan  7 10:30:01 jeedom systemd[1]: Starting Session c17525 of user www-data.
Jan  7 10:30:01 jeedom systemd[1]: Started Session c17525 of user www-data.
Jan  7 10:30:05 jeedom kernel: [1049350.603980] Unable to handle kernel NULL pointer dereference at virtual address 00000013
Jan  7 10:30:05 jeedom kernel: [1049350.605241] pgd = 80004000
Jan  7 10:30:05 jeedom kernel: [1049350.605833] [00000013] *pgd=00000000
Jan  7 10:30:05 jeedom kernel: [1049350.606420] Internal error: Oops: 5 [#1] SMP ARM
Jan  7 10:30:05 jeedom kernel: [1049350.607009] Modules linked in: xt_multiport iptable_filter ip_tables x_tables nfsd rpcsec_gss_krb5 brcmfmac brcmutil cdc_acm sg cfg80211 rfkill snd_bcm2835 snd_pcm snd_timer snd bcm2835_gpiomem bcm2835_wdt uio_pdrv_genirq uio ipv6
Jan  7 10:30:05 jeedom kernel: [1049350.609062] CPU: 0 PID: 16232 Comm: grep Not tainted 4.4.26-v7+ #915
Jan  7 10:30:05 jeedom kernel: [1049350.609762] Hardware name: BCM2709
Jan  7 10:30:05 jeedom kernel: [1049350.610434] task: b3466d40 ti: 95fc8000 task.ti: 95fc8000
Jan  7 10:30:05 jeedom kernel: [1049350.611146] PC is at unfreeze_partials+0x34/0x1c4
Jan  7 10:30:05 jeedom kernel: [1049350.611838] LR is at unfreeze_partials+0x108/0x1c4
Jan  7 10:30:05 jeedom kernel: [1049350.612512] pc : [<801476d0>]    lr : [<801477a4>]    psr: a0000093
Jan  7 10:30:05 jeedom kernel: [1049350.612512] sp : 95fc9cf0  ip : 00000000  fp : 95fc9d6c
Jan  7 10:30:05 jeedom kernel: [1049350.613934] r10: 8010000b  r9 : bc801d00  r8 : bd66fc60
Jan  7 10:30:05 jeedom kernel: [1049350.614704] r7 : bc800ec0  r6 : 00000000  r5 : bb8c5800  r4 : ffffffff
Jan  7 10:30:05 jeedom kernel: [1049350.615484] r3 : bc800ec0  r2 : bd7987ac  r1 : bd799ba4  r0 : 00000000
Jan  7 10:30:05 jeedom kernel: [1049350.616290] Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Jan  7 10:30:05 jeedom kernel: [1049350.617909] Control: 10c5383d  Table: 3afbc06a  DAC: 00000055
Jan  7 10:30:05 jeedom kernel: [1049350.618698] Process grep (pid: 16232, stack limit = 0x95fc8210)
Jan  7 10:30:05 jeedom kernel: [1049350.619442] Stack: (0x95fc9cf0 to 0x95fca000)

→ C’est une kernel panic ?

Je n’ai rien mis à jour de particulier (à part les mises à jour standard des plugins jeedom) donc je ne comprends pas trop d’où cela pourrait provenir.
Personne n’a d’idée du coup ?

Bonjour ,
À tout hasard, combien de clé sur l’usb ? Quid d’une alimentation qui commence à faiblir ?
Essayé une autre alim et/ou un hub usb alimenté.

Es tu sur sd ? Perso je n’ai jamais eu de problème avec les cartes sd (certains doivent avoir 10 ans) mais c’est assez répandu.

Bonjour,

mon système est sur une SD changée il y a un an (l’autre m’avait lâchée).
Sur les USB, j’ai uniquement ma clé Z-wave et mon SSD hébergeant jeedom.