Comment interpréter un crashdump ?

[f-d-m]

Bonjour,

Voici ma config:
Rpi 3B, SSD, Debian 10.6, Domoticz 2020.1, PiZigate 030f, plugin 4.11.011, MQTT, Buienradar, SMA Sunny Boy.

J'ai eu un crash ce matin, et je voudrais bien essayer de comprendre si c'est reproductible, si c'est la faute à pas de chance, ou bien parce qu'un rayon cosmique baladeur est passé par là

Voici le crash.
Je copie ci-dessous la section récapitulative. Le crash complet est posté sur https://pastebin.com/3emy8rb7 .

Code : Tout sélectionner

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
__GI___nanosleep (remaining=0x7ebf89d8, requested_time=0x7ebf89d8) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
28      ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
  Id   Target Id                                       Frame
* 1    Thread 0x76046010 (LWP 15215) "domoticz"        __GI___nanosleep (remaining=0x7ebf89d8, requested_time=0x7ebf89d8) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
  2    Thread 0x75b6d220 (LWP 15216) "Watchdog"        __GI___nanosleep (remaining=0x75b6cbd0, requested_time=0x75b6cbd0) at ../sysdeps/unix/sysv/linux/nanosleep.c:28
  3    Thread 0x7536c220 (LWP 15217) "SQLHelper"       syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37
  4    Thread 0x74b6b220 (LWP 15218) "PluginMgr"       syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37
  5    Thread 0x73dc0220 (LWP 15219) "InfluxPush"      syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37
  6    Thread 0x735bf220 (LWP 15220) "Webem_ssncleane" 0x76aa29d0 in epoll_wait (epfd=<optimized out>, events=0x735be378, maxevents=128, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
  7    Thread 0x72dbe220 (LWP 15221) "WebServer_80"    0x76aa29d0 in epoll_wait (epfd=<optimized out>, events=0x72dbd348, maxevents=128, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
  8    Thread 0x723ff220 (LWP 15222) "Webem_ssncleane" 0x76aa29d0 in epoll_wait (epfd=<optimized out>, events=0x723fe378, maxevents=128, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
  9    Thread 0x71bfe220 (LWP 15223) "WebServer_443"   0x76aa29d0 in epoll_wait (epfd=<optimized out>, events=0x71bfd348, maxevents=128, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
  10   Thread 0x711ff220 (LWP 15224) "Scheduler"       syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37
  11   Thread 0x709fe220 (LWP 15225) "TCPServer"       0x76aa29d0 in epoll_wait (epfd=<optimized out>, events=0x709fd378, maxevents=128, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
  12   Thread 0x701fd220 (LWP 15226) "MainWorker"      syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37
  13   Thread 0x6f9fc220 (LWP 15227) "MainWorkerRxMsg" __waitpid (options=0, stat_loc=0x6f9fa2a8, pid=8949) at ../sysdeps/unix/sysv/linux/waitpid.c:30
  14   Thread 0x6e5fe220 (LWP 15229) "MQTT"            0x76a9b7cc in __pselect (nfds=35, readfds=0x6e5fda90, writefds=<optimized out>, exceptfds=<optimized out>, timeout=<optimized out>, sigmask=0x0) at ../sysdeps/unix/sysv/linux/pselect.c:69
  15   Thread 0x6ddfd220 (LWP 15230) "Domoticz_HBWork" syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37
  16   Thread 0x6d5fc220 (LWP 15231) "BuienRadar"      syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37
  17   Thread 0x6cdfb220 (LWP 15232) "NotificationSys" futex_abstimed_wait_cancelable (private=<optimized out>, abstime=0x6cdfabcc, expected=0, futex_word=0x8f401c <m_mainworker+2860>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
  18   Thread 0x6c1ff220 (LWP 15233) "Plugin_ASIO"     0x76aa29d0 in epoll_wait (epfd=<optimized out>, events=0x6c1fe350, maxevents=128, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
  19   Thread 0x6b636220 (LWP 15234) "Plugin_Zigate"   syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37
  20   Thread 0x6accd220 (LWP 15235) "Plugin_SMASunny" syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37
  21   Thread 0x6a3cc220 (LWP 15256) "PluginMgr"       0x76aa29d0 in epoll_wait (epfd=<optimized out>, events=0x6a3cb360, maxevents=128, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
  22   Thread 0x69b4b220 (LWP 15257) "EventSystem"     syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37
  23   Thread 0x6934a220 (LWP 15258) "EventSystemQueu" futex_abstimed_wait_cancelable (private=<optimized out>, abstime=0x69349af8, expected=0, futex_word=0x8f363c <m_mainworker+332>) at ../sysdeps/unix/sysv/linux/futex-internal.h:205

Si Domoticz commence à crasher quand je ne suis pas à la maison, c'est madame qui ne va pas être contente... Par où aiguiller mes recherches ?

Merci d'avance à tous

[Keros]

Qu'est ce que tu appelles un crashdump ? Je ne reconnais pas ton rapport : c'est quoi ?

Tu peux nous en dire un peu plus sur le soucis que tu as eu : C'est seulement DomoticZ ou tout le pi ? Quels étaient les symptômes ? C'est reparti après un redémarrage ? Tu as dû faire une réinstallation ?

[f-d-m]

Qu'est ce que tu appelles un crashdump

C'est un plantage du/des process Domoticz, , ce dump se trouve dans le ficher domoticz_crash.log dans le répertoire de Domoticz.
Le Rpi et le daemon mosquitto ont bien survécu, eux.

Comme j'ai installé un SSD au lieu d'une carte SD, je pourrais me payer le luxe d'écrire les logs domoticz sur le disque, mais je ne suis pas certain que ça m'aurait aidé.

Ca s'est planté à 11h45 et des secondes, il n'y avait aucune action sur timer à ce moment-là.

Frédéric

[Keros]

Essaye peut-être d'installer Monit : ça monitore le processus et le relance s'il ne répond plus.

[f-d-m]

installer Monit

Merci pour ta proposition.
Pour ce qu'on lui demande de faire, ceci peut tenir en une ligne dans un cron * * * *

Code : Tout sélectionner

ps aux|grep -v grep|grep -q domoticz || service domoticz restart

Mais bof. Quand il y a une fuite, je préfère réparer plutôt que de mettre un seau en-dessous.

[lost]

Quand il y a une fuite, je préfère réparer plutôt que de mettre un seau en-dessous.

Surtout que là, il n'y a même pas d'eau à récupérer!
Je commencerais par désactiver les plugins pour confirmer que c'est bien l'un d'eux qui pose pb, avant de les remettre un à un pour identifier celui qui pose pb.

Attention à cette remarque ici concernant les plugins python:
https://www.domoticz.com/wiki/Developin ... hon_plugin

All threads started within the plugin (either directly or by imported modules) must be terminated by the plugin prior to the plugin stopping ('onStop' is the recommended place for this). Failure to do this will result in Python aborting Domoticz during hardware 'Stops' &/or 'Updates'. The Plugin Framework cannot enumerate threads started by the plugin or stop them (Python limitation) and any active threads when the plugin interpreter is destroyed will cause Python to abort. YOU HAVE BEEN WARNED !

[f-d-m]

Je commencerais par désactiver les plugins

Merci de ta réponse.
Je suppose que ça ne concerne pas les scripts dzVents ?

Frédéric

[boum]

Le problème de ce dump, c'est qu'il ne fournit qu'un début de piste.
La plupart des threads sont en attente d'événement, donc probablement hors de cause.
Celui qui a provoqué le crash est le thread 13.
C'est l'envoi d'un message MQTT qui est la cause. Sans avoir de debugger connecté, c'est plus dur de savoir pourquoi la publication du message plante.
La seule autre info visible dans la pile d'appel est que c'est dû à une requête d'information de dispositif. Impossible ici de connaitre la source (JSON, MQTT, autre plugin…)

Code : Tout sélectionner

Thread 13 (Thread 0x6f9fc220 (LWP 15227)):
#5  raise (sig=11) at ../sysdeps/unix/sysv/linux/raise.c:50
#6  <signal handler called>
#7  0x00620a2c in packet.queue ()
#8  0x00623a18 in send.real_publish ()
#9  0x0061b838 in mosquitto_publish ()
#10 0x000ed2b0 in mosqdz::mosquittodz::publish(int*, char const*, int, void const*, int, bool) ()
#11 0x003072c8 in MQTT::SendMessage(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#12 0x00308fe4 in MQTT::SendDeviceInfo(int, unsigned long long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned char const*) ()
#13 0x000ec3c0 in boost::signals2::detail::signal_impl<void (int, unsigned long long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned char const*), boost::signals2::optional_last_value<void>, int, std::less<int>, boost::function<void (int, unsigned long long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned char const*)>, boost::function<void (boost::signals2::connection const&, int, unsigned long long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned char const*)>, boost::signals2::mutex>::operator()(int, unsigned long long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned char const*) ()
#14 0x000d9c24 in MainWorker::ProcessRXMessage(CDomoticzHardwareBase const*, unsigned char const*, char const*, int) ()
#15 0x000dd0f0 in MainWorker::Do_Work_On_Rx_Messages() ()

[f-d-m]

Merci boum pour cette analyse.
J'ai lancé un mqtt client qui souscrit à tout, pour un peu voir qui publie quoi et quand.

J'ai par exemple ajouté assez récemment 3 prises zigbee, et (ce qui n'était pas un critère d'achat) ces prises peuvent indiquer la consommation en watts. Mais pour cela il faut qu'on les questionne.

Ce polling des prises est fait par le plugin Zigate (en protocole Zigbee donc) et je constate qu'il n'y a pas de message MQTT domoticz/out qui publie les mises à jour d'état.

Je laisse tourner le mosquitto_sub dans un process détaché, les sonoff Tasmota s'occupent de laisser des 'time stamps' assez régulièrement.

Yapluka que ça crashe maintenant