IPS Absturz

Hallo,

nach Upgrade auf 5.1 erlebe ich unerklärliche Abstürze von IPS auf einem Raspi 3. In der Logdatei sehe ich, dass um 13 h nach Zeitplan ein Thermostat angesteuert wird. Dann keinerlei Fehlereinträge, Dienst stürzt ab, lässt sich manuell wieder starten.

System besteht aus einem Raspi mit ZWave Modul und ausschließlich ZWave Aktoren/Sensoren.

Frage: Wie kann ich gezielt den Fehler nachstellen bzw. analysieren?

Viele Grüße
Andreas

Am einfachsten, wenn du dies hier machst: Debugging für Experten (Raspberry Pi, Linux)

Wenn du dann einen Backtrace für mich hast, kann ich bestimmt recht schnell die Ursache finden.

paresy

Hallo Paresy,

ich teste dies einmal, vielen Dank,

Andreas

Hallo Paresy,

gdb gibt folgende Fehlermeldung:


(gdb) bt
#0  0x00a034fc in ZWaveBattery::ReceiveData(std::vector<unsigned char, std::allocator<unsigned char> >) ()
#1  0x00a7b6c0 in ZWaveDevice::ReceiveData(IPSData const&) ()
#2  0x00a7b370 in ZWaveDevice::ReceiveData(IPSData const&) ()
#3  0x00fffb34 in IPSFlowHandler::SendDataToChildren(unsigned short, IPSData const&) ()
#4  0x00a8fed4 in ZWaveGateway::ProcessRequest(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) ()
#5  0x00a937c8 in ZWaveGateway::ParseBuffer() ()
#6  0x00a93d34 in ZWaveGateway::ReceiveData(IPSData const&) ()
#7  0x00fffb34 in IPSFlowHandler::SendDataToChildren(unsigned short, IPSData const&) ()
#8  0x01172320 in IOSerialPort::completedReading(std::shared_ptr<std::array<char, 4096u> >, std::error_code const&, unsigned int) ()
#9  0x01175728 in asio::detail::descriptor_read_op<asio::mutable_buffers_1, std::_Bind<std::_Mem_fn<void (IOSerialPort::*)(std::shared_ptr<std::array<char, 4096u> >, std::error_code const&, unsigned int)> (IOSerialPort*, std::shared_ptr<std::array<char, 4096u> >, std::_Placeholder<1>, std::_Placeholder<2>)> >::do_complete(void*, asio::detail::scheduler_operation*, std::error_code const&, unsigned int) ()
#10 0x008d8e44 in asio::detail::epoll_reactor::descriptor_state::do_complete(void*, asio::detail::scheduler_operation*, std::error_code const&, unsigned int)
    ()
---Type <return> to continue, or q <return> to quit---  
#11 0x0116e2b4 in std::thread::_State_impl<std::_Bind_simple<IOSerialPort::Connect()::{lambda()#1} ()> >::_M_run() ()
#12 0x026765d8 in execute_native_thread_routine ()
#13 0x76f81fc4 in start_thread (arg=0x6cffe8a0) at pthread_create.c:458
#14 0x76d6e038 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:76
   from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

PS: Mein 4.3 Backup läuft problemlos.

Ein Gerät scheint beim Batteriestatus nicht ganz korrekte Daten zu senden. Ich werde zum nächsten Update dort ein paar zusätzliche Checks einbauen.

paresy

Hallo Paresy,

ok, danke, hatte auch beobachtet das der Batteriestatus mit Vorsicht zu genießen ist. Bis wann ist denn mit einem Update zu rechnen?

PS: Die erweiterten Statusvariablen machen in 5.1 insgesamt einen sehr guten Eindruck.

Viele Grüße
Andreas

Hallo,

gibt es hierzu bereits eine Fehlerkorrektur?

Danke,
Andreas

Leider noch nicht. Kommt diese Woche. Danke für deine Geduld!

paresy

Hallo Paresy,

ist der Fix im neuen Stable-Release berücksichtigt oder kann/muss ich auf gezielte Suche gehen, um den Aktor ggf. neu anzulernen?

Danke,
Andreas

Fix kommt zum nächsten Update. (Heute oder spätestens Morgen)

paresy

Hallo paresy,

habe jetzt einmal die neue Beta-Version installiert und teste den Fix.

Vielen Dank,
Andreas

Hallo Paresy,

leider scheint der Fehler nicht behoben worden zu sein, IPS ist heute an Vormittag wieder abgestürzt. Scheint nicht zu einem festen Zeitpunkt, sondern nach einer gewissen Zeit.zu passieren. Wie kann der Fehler weiter lokalisiert zu werden?

Grüße Andreas

Hallo paresy,

hat anscheinend doch nichts mit der Zeitdauer zu tun. Wenn ich das Logfile bzw. meine Tagesreports anschaue, scheint der Fehler beim Auslesen des Batteriestatus, was ich einmal täglich zwischen 23:00 und 23:15 h vornehme zu passieren. Ein Gerät scheint ‚Null‘ zurückzuliefern. Ich lese dabei den Prozentwert, nicht den Batteriestatuswert (Boolean), aus.

Viele Grüße,
Andreas

Hallo Paresy,
So einfach scheint es nicht zu sein, IPS lief gestern Nacht an diesem Zeitpunkt durch, um Mitternacht scheint es ein Problem gegeben zu haben, da der Tagesreport einige Minuten später als geplant generiert wurde. Habe mir zuvor einen cronjob eingerichtet, der IPS automatisch wieder startet, wenn es nicht läuft, sowie jeden Montag früh ein reboot durchführt. Muss jetzt noch das logfile vor dem reboot sichern, um Absturzzeitpunkte nachvollziehen zu können.

Keine Dauerlösung, aber es tut für den Übergang.

Viele Grüße,
Andreas

Hast du die Möglichkeit noch einmal das Debugging zu starten und den Absturz zu provozieren? (Du weißt ja vermutlich welches Gerät dies tut)

Eigentlich habe ich die notwendigen Prüfungen hinzugefügt. Aber ich würde das mit dem Backtrace dann noch einmal abgleichen.

paresy

Mit dem Logging, was ich eingebaut habe, kann ich hoffentlich den Zeitraum eingrenzen und dann das Debugging noch einmal laufen lassen. Wird aber etwas dauern, da ich einige Zeit unterwegs bin, dann poste ich hier wieder.

Ich weiß aktuell leider nicht, ob oder welcher Aktor dies provoziert. Habe zuletzt nur einen Aeon Switch wieder in Betrieb genommen, sowie einen Fibaro Switch neu hinzugenommen.

Viele Grüße
Andreas

Hallo Paresy,

mit Ausnahme des zuvor berichteten Absturzes lief IPS bislang durch, ich beobachte weiter.

Viele Grüße,
Andreas

Hallo Paresy,

heute gab es zwischen 19:30 und 20:00 h wieder einen Absturz, hatte die cronjob Zeitintervallen auf 30 Minuten erhöht. Ich kann ggf. nach dem Feiertag einmal den Debug-Modus testen. Da es zuletzt immer zu unterschiedlichen Zeiten passierte, habe ich keine Idee welcher Aktor die Ursache sein kann.

Gruß Andreas

Hallo paresy,

ich habe nun einmal weiter die Stabilität über die letzte knappe Woche beobachtet und es kam kein weiterer Absturz hinzu.

Was mit aufgefallen ist, ist dass beim Upgrade auf 5.1 einige Wochenskripts anscheinend nicht korrekt umgesetzt worden sind. Ich hatte bei zwei Schaltern den Zustand über die Funktion ZW_SwitchMode geändert. Das Ziel erschien nach dem Update als „undefined“. Ist mir aufgefallen, dass die Aktion nicht mehr erfolgte. Habe dies dann über die Webkonsole, ich glaub das heisst hier einfache Aktion, umgestellt.

Letzteres war die einzige Änderung die erfolgte, neben der Umstellung wieder auf den Stable Kanal.

Viele Grüße,
Andreas