Fhem abgestürzt

[maci]

Hallo,

Gestern abend ist mein Fhem abgestürzt.
die letzten Einträge im Logfile waren:

Code Auswählen Erweitern

2017.09.10 21:02:36 3: Photovoltaik: Read callback: Error: connect to http://10.0.0.210:80 timed out
malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at ./FHEM/23_VOLKSZAEHLER.pm line 110.

Meine Fragen:
Wie kann ich verhindern dass dies wieder passiert?
Wo kann die Ursache liegen?

Jedenfalls überlege ich mir ob ich mir nicht ein bash script bastle, dass überprüft ob fhem läuft.
Oder gibt es so etwas bereits?

[CoolTux]

Wenn Du Perl programmieren kannst dann kannst Du das Modul verbessern und den Fehler abfangen. Ansonsten Mail an den Modulauthor.
Scheint auch kein offizielles Modul zu sein, habe es im SVN nicht gefunden.
Ich gehe davon aus das er beim Aufruf der json_decode() Funktion abgeschmiert ist weil der JSON String nicht korrekt war.
Abfangen kann  man das in dem man den Aufruf in einem eval macht

Code Auswählen Erweitern


$json = eval{decode_json($data)};
if($@){
   return "error while request: $@"; 
}


[CQuadrat]

Jedenfalls überlege ich mir ob ich mir nicht ein bash script bastle, dass überprüft ob fhem läuft.
Oder gibt es so etwas bereits?

Schau mal hier:
https://forum.fhem.de/index.php/topic,20553.0.html

Und dabei diesen Hinweis beachten:
https://forum.fhem.de/index.php/topic,20966.msg154310.html#msg154310

[maci]

Wenn Du Perl programmieren kannst dann kannst Du das Modul verbessern und den Fehler abfangen. Ansonsten Mail an den Modulauthor.
Scheint auch kein offizielles Modul zu sein, habe es im SVN nicht gefunden.
Ich gehe davon aus das er beim Aufruf der json_decode() Funktion abgeschmiert ist weil der JSON String nicht korrekt war.
Abfangen kann  man das in dem man den Aufruf in einem eval macht

Code Auswählen Erweitern


$json = eval{decode_json($data)};
if($@){
   return "error while request: $@"; 
}


Danke für den Hinweis. Ich habe einen neue Version gefunden und diese nun installiert.
Mal sehen ob dies nun funktioniert.
bis jetzt keine Fehlermeldungen im Log nach Neustart von Fhem.

[efyzz]

Moin,
ich will mich hier mal dranhängen. FHEM auf RPi3B ist heute Nacht bei mir erstmalig nach über 5 Jahren Betrieb abgestürzt. Der Raspi selbst lief allerdings noch, bzw. wurden andere Dienste weiter ausgeführt.

Hier die Log-Einträge kurz vor Ende:

Code Auswählen Erweitern

2021.12.18 03:48:31 1: ERROR: Select error -1 (9), error count= 0
2021.12.18 03:48:31 1: PERL WARNING: Use of uninitialized value in vec at fhem.pl line 740.
2021.12.18 03:48:31 1: Found and deleted bad fileno for Staubsauger
FATAL: input size not equal to blocksize (16) at /usr/local/share/perl/5.20.2/Crypt/CBC.pm line 492.

Deutet das möglicherweise auf eine sterbende SD-Karte hin?

Danke!

[Otto123]

Hi,

möglicherweise ...

5 jahre alt bedeutet auch es wird Zeit das OS zu aktualisieren? Solange es noch geht ...
Ich hätte hier Hilfestellung dazu.
Falls es doch nicht mehr geht und kein aktuelles Backup da ist, hätte ich hier noch was.


Gruß Otto

[efyzz]

Moin Otto,

wie darf ich denn Dein "möglicherweise" interpretieren? Heißt das, Du hast keine Ahnung und kannst es daher nicht ausschließen oder meinst Du eher: ja, solche Fehler können durch eine defekte SD-Karte hervorgerufen werden?

Glücklicherweise habe ich vor wenigen Tagen noch ein Image der SD-Karte gezogen. Es wäre also kein Problem, auf eine neue SD-Karte zu wechseln.

Ja, ein Update des Debian Jessie wäre sicherlich mal angesagt. 
Dann aber eher über ein

Code Auswählen Erweitern

sudo apt dist-upgrade
wie beispielsweise hier beschrieben: https://phoenixnap.com/kb/update-raspberry-pi

[MadMax-FHEM]

Kann nach 5 Jahren vieles sein.

SD kann sein...
Evtl. aber auch Probleme von "neuen" Schlüssel(längen) und "alten" Verschlüsselungsbibliotheken...

Wenn z.B. die letzte Meldung der Absturzgrund sein sollte...

Und Jessie sollte man ja wirklich nicht mehr haben...
...von dist-upgrade halte ich nichts...

Gerade zwischen Jessie und Stretch kam der Umstieg von initd auf systemd...

Ich würde (und mache ich immer so) neu aufsetzen.
Ist doch wie normales Backup/Restore?

Und wenn es wirklich eine defekte SD ist, ist fraglich ob das Image tatsächlich noch "sauber" ist oder nicht auch schon Fehler hat (die nur noch nicht aufgefallen sind)...

Aber das nur meine Meinung...

Gruß, Joachim

[Otto123]

wie darf ich denn Dein "möglicherweise" interpretieren? Heißt das, Du hast keine Ahnung und kannst es daher nicht ausschließen oder meinst Du eher: ja, solche Fehler können durch eine defekte SD-Karte hervorgerufen werden?

Kann man doch so nicht mit Bestimmtheit sagen, aber wie Joachim sagt nach 5 Jahren ...
Unklare Fehler (so wie Deiner) deuten uU auf eine defekte "platte" hin. Wenn die sich jetzt häufen steigt die Sicherheit für eine solche Aussage.

Auf einem Image kann schon ein Fehler drauf sein, Du kannst das Image ja mal prüfen (Mein link mit crash...)

Von einem "dist-upgrade" wie in deinem Link halte ich nicht viel, von jessie wirst Du baden gehen.

Nutze die Zeit und beschäftige Dich mit einem neuen System, Dokumentation und backup/restore

Gruß Otto

[Wernieman]

Eigentlich währen die Meldungen genau vor dem "Fehler" interessanter.
Auch sollte man zu dem Zeitpunkt die üblichen Verdächtigen wie /var/log/kern.log oder syslog kontrollieren. Bei 5 Jahren ist auch das Netzteil ein Blick wehrt. Gibt beim Pi viele Möglichkeiten ...

ABER .. ich würde auch "ein" Absturz innerhalb von 5 Jahren noch nicht als Kritisch sehen. Beim 2. oder 3. würde ich sehr hellhörig werden.

Unabhängig davon würde ich auch ein Update empfehlen. Da Basis Jessi würde ich auch Neuinstallation mit aktuellen System (auf neuer SD) als Ziel sehen. Schließlich liegen 2 Versionen dazwischen. Bei einem direktem Update könnte auch ein dist-upgrade sinnvoll sein .. wenn man weiß, was man tut.

[MadMax-FHEM]

Eigentlich währen die Meldungen genau vor dem "Fehler" interessanter.
Auch sollte man zu dem Zeitpunkt die üblichen Verdächtigen wie /var/log/kern.log oder syslog kontrollieren. Bei 5 Jahren ist auch das Netzteil ein Blick wehrt. Gibt beim Pi viele Möglichkeiten ...

Ja, warum?

Die habe ich auch ab und an in Verbindung mit meinen Xiaomi-Saugern (so nehme ich an)...
...führen aber (bei mir) nicht zu einem Absturz...
...und auch sonst zu keiner Fehlfunktion, zumindest nicht, dass mir etwas aufgefallen wäre...

Hatte aber bislang keine Zeit (Anlass) das genauer zu untersuchen...
...evtl. über Weihnachten...

Und ja: ein Absturz in 5 jahren ist kein Ding... Und seit systemd wird ja auch autom. gestartet... (sofern so eingestellt)... (dumm nur, wenn man noch auf initd ohne zusätzliche Massnahmen läuft -> noch ein Grund "hochzurüsten" )...

Gruß, Joachim

[Wernieman]

Um zu wissen, was das System genau vorher gemacht wird. Habe auch beruflich zu häufig, das mir "nur" die Fehlermeldung präsentiert wird und man damit den "Background" nicht erkennt. Also mehrere Zeilen VOR einem Fehler sind meistens interessanter als der Fehler selber

Edit:

Code Auswählen Erweitern

input size not equal to blocksize .... Crypt/CBC.pm
Das könnte so viel sein ...

[efyzz]

Nabend und vielen Dank für die zahlreichen Antworten!

Ja, ein Update bzw. Neuinstallation ist sicherlich mal sinnvoll. Allerdings macht der RasPi einiges mehr, als nur FHEM ausführen. Es wird Wochen dauern, bis alles wieder richtig funktioniert. Ich habe zwar vieles dokumentiert, aber einiges wird schlichtweg nicht mehr kompatibel sein, auch wenn ich "nur" ein dist-upgrade durchführe (schon allein wegen initd -> systemd). Also habt ihr Recht, ich kann auch gleich alles komplett neu aufsetzen.

Also mehrere Zeilen VOR einem Fehler sind meistens interessanter als der Fehler selber

Ich habe alle Zeilen zur relevanten Zeit gezeigt. Der nächstältere Eintrag war eine Stunde davor und hat nichts mit dem Fehler zu tun.

Xiaomi-Saugern (so nehme ich an)...
...führen aber (bei mir) nicht zu einem Absturz...

Genau, Xiaomi
Ich vermute auch fast, dass der Eintrag im Log letztlich gar nichts mit dem Absturz zu tun hat. Hast Du denn auch die Meldung mit blocksize dabei?

Auch sollte man zu dem Zeitpunkt die üblichen Verdächtigen wie /var/log/kern.log oder syslog kontrollieren. Bei 5 Jahren ist auch das Netzteil ein Blick wehrt. Gibt beim Pi viele Möglichkeiten ...

ABER .. ich würde auch "ein" Absturz innerhalb von 5 Jahren noch nicht als Kritisch sehen. Beim 2. oder 3. würde ich sehr hellhörig werden.

Das Netzteil bzw. die USV ist ein Eigenbau. Trafo, Gleichrichter, Bleiakku, Regler ... unkaputtbar   Aber klar, ausschließen kann man es natürlich nicht. Werde ich mal prüfen.

Ich mache mir bei dem einen Absturz auch noch keine ernsthaften Sorgen, es ist nur so ungewohnt und war daher erst mal ein Schock.  Bisher gab es auch keine weiteren Probleme. Dachte nur, ich frage lieber mal, bevor es tatsächlich zum Problem wird.

In /var/log/kern.log und syslog gibt es zum fraglichen Zeitpunkt leider keine relevanten Einträge.

Ich werde als Workaround wohl erst mal den Watchdog einbauen, wie hier beschrieben:
https://forum.fhem.de/index.php/topic,20553.0.html
Dann sollte nächstes Mal wenigstens die Heizung morgens wieder anspringen

Danke euch nochmal bis hier hin. Falls es wieder auftritt, werde ich mich melden. Ansonsten beschäftige ich mich nebenbei mal mit dem Neuaufsetzen des Systems.

Edit:

Du kannst das Image ja mal prüfen (Mein link mit crash...)

Das probiere ich natürlich auch nochmal!

[efyzz]

Moin,

heute Nacht ist es wieder passiert:

Code Auswählen Erweitern

2022.03.10 02:42:01 1: a1optpg91s0ydf-ats.iot.eu-west-1.amazonaws.com:8883 disconnected, waiting to reappear (MQTT_Worx)
2022.03.10 02:42:02 1: a1optpg91s0ydf-ats.iot.eu-west-1.amazonaws.com:8883 reappeared (MQTT_Worx)
2022.03.10 03:48:33 1: ERROR: Select error -1 (9), error count= 0
2022.03.10 03:48:33 1: Found and deleted bad fileno for Staubsauger
FATAL: input size not equal to blocksize (16) at /usr/local/share/perl/5.20.2/Crypt/CBC.pm line 492.

Irgendein Fehler vom Staubsauger (Xiaomi) trat auf, dann stürzte FHEM ab.

@MadMax: Konntest Du schon herausfinden, warum (scheinbar) das Xiaomi-Modul diesen Fehler verursacht?

[Otto123]

Moin,

das klingt schon nach einem Fehler im Dateisystem.

Gruß Otto