FHEM Absturz auf Raspberry PI

Archimedes · 17 November 2017, 16:51:28

Hallo,
aktuell untersuche ich den Absturz meines FHEM Servers auf einem Raspberry PI. Hierzu habe ich einige Fragen, mit der Hoffnung auf Antwort oder Anregung zum weiteren Vorgehen.
Nach dem nächtlichen Absturz des Servers, wohl ausgelöst durch ein Ereignis eines Watchdogs, konnte FHEM nicht mehr gestartet werden. TOP meldete einen FHEM Prozess mit knapp 100% CPU Last, Neustarts des Dienstes oder des Servers brachten nichts, was mich zu einer Neuinstallation des gesamten Systems bewegte, es ist ja schon 4 Jahre in Betrieb. Auch eine komplette Neuinstallation mit stretch lite half nichts. 3 Tage vorher habe ich noch ein weiteres Device angebunden, was die fhem.cfg auf ca. 50KB brachte, der Watchdog griff die besagte Nacht das erste Mal, lief die letzten Monate ansonsten super.
TOP meldet zwar eine hohe CPU Last des Tasks, aber ansonsten ca. 300MB freies RAM, womit ich somit auch auf dem von mir verwendeten PI B+ keine Ressourcenprobleme sehe (oder evtl. doch

)

Und nun meine Frage: Gibt es die Möglichkeit festzustellen, ob das Perl Skript FHEM in einen Memory Overflow kommt und sich deshalb weghängt, oder ob andere vom System bereitgestellte Ressourcen das Problem verursachen ?

Mittlerweile läuft ein 2ter Pi B3 als FHEM Server, der Keller, Aussen und Erdgeschoss übernimmt, der bisherige PI steuert (noch) das Obergeschoss. Ich möchte natürlich alles auf dem neuen PI konsolidieren, habe aber Angst, dass FHEM auch auf dem PI B3 ein Ressourcenproblem bekommt.
Gruß Axel

Wernieman · 18 November 2017, 14:55:38

Bei 100% CPU beim starten fällt mir immer ein:
1) initialUsbCheck eingeschaltet? Bitte mal disablen.
2) Funktioniert es, wenn Du FHEM nach dem booten erst (manuell) startest?
Bitte prüfen, ob es vorher auch wirklich beendet ist

Code Auswählen

ps aux | grep fhem

herrmannj · 18 November 2017, 16:00:54

ZitatUnd nun meine Frage: Gibt es die Möglichkeit festzustellen, ob das Perl Skript FHEM in einen Memory Overflow kommt und sich deshalb weghängt,

auf der shell

Code Auswählen

while true; do free >> memory.log; sleep 30; done
Mit screen detach damit das weiter läuft wenn Du abgemeldet bist. Sleep 30 schreibt alle 30 Sekunden, was das log groß macht. Mglw also hoch setzen.

Zitatoder ob andere vom System bereitgestellte Ressourcen das Problem verursachen ?

bitte spezifizieren. Wenn Du etwas überwachen möchtest musst Du sagen was genau.

Archimedes · 20 November 2017, 16:30:49

Hallo, soviel habe ich herausgefunden: Wenn sich FHEM weghängt, dann sofort, egal ob nach einem Neustart oder durch manuelles starten. Ich schaue vorab in der Tasklist und beende FHEM mit kill - kill PID.
Es liegt definitiv an der Anzahl der definierten Objekte in der fhem.cfg. Starte ich mit der demo.cfg oder mit einer alten Version, die weniger Objekte hält, ist alles in Ordnung. Somit hilft mir eine regelmäßige Protokollierung alle 30Min. offensichtlich wenig.
Ich werde wohl mal ein Testsystem aufsetzen, die 48KB große FHEM.cfg hineinschieben und schauen, wie er sich verhält. Leider kenne ich mich so gut in Linux nicht aus, wenn ich von anderen Ressourcen spreche. Aber wieviel Ressourcen (Speicher ? Anzahl Objekte ?, keine Ahnung....) darf ein Perl Skript benutzen ?

Wernieman · 20 November 2017, 17:00:06

Was für eine Installation hast Du drauf? Mit oder ohne Desktop?

Thorsten Pferdekaemper · 20 November 2017, 18:00:19

Hi,
also meine fhem.cfg ist 78kB groß und das ganze läuft auf einem alten RasPi 1. Ich würde eher mal davon ausgehen, dass es ein Problem mit einem bestimmten Modul gibt und nicht mit der Größe an sich. Die Größe ist ja nicht der einzige Unterschied zwischen einer "echten" und einer Demo-Konfiguration.
Wenn Du den "Hänger" nachvollziehen kannst, dann kannst Du mit dem Perl-Debugger vielleicht was finden: Zuerst "attr global nofork 1" setzen (zur Not halt doch mal direkt in der fhem.cfg), dann fhem per commandline als root starten:

Code Auswählen


cd /opt/fhem
perl -d fhem.pl fhem.cfg

Wenn's das erste Mal stoppt einfach mit "c" weiter.
...dann warten bis der Kram hängt (dauert mit dem Debugger ggf etwas länger). Dann per Ctrl+c in den Debugger gehen und dort nachsehen, was Sache ist (siehe auch https://perldoc.perl.org/perldebug.html).
Gruß,
Thorsten

Archimedes · 21 November 2017, 16:31:26

Hi, supi, das werde ich die kommenden Tage realisieren und mich dazu wieder melden. Die alte Installation, auf der das Problem auftrat, war noch mit Desktop, alle anderen sind ohne. Aktuell ist hierfür noch ein Testsystem im Zulauf. Dieses WE muss ich arbeiten, es wird somit leider etwas dauern. Natürlich hängt es mit Sicherheit auch von den verwendeten Komponenten ab, wie groß die fhem.cfg sein kann. Bei der fehlerhaften Konfiguration wurde von mir eine Homematic Funksteckdose und 4 weitere Timer hinzugefügt. Als dann Nachts noch ein Watchdog ansprang, war das Thema gegessen.

Wernieman · 21 November 2017, 19:06:01

Code Auswählen

war noch mit Desktop
Mit laufenden?

Dann würde es ziemlich fiel erklähren ...

Archimedes · 21 November 2017, 20:04:50

Auch nach einer kompletten Neuinstallation mit stretch-lite änderte sich das Verhalten nicht. Ich sehe somit aktuell keine Abhängigkeiten bei den verwendeten Betriebssystemen.

Thorsten Pferdekaemper · 21 November 2017, 20:38:03

...das hätte mich auch sehr stark gewundert.
Gruß,
Thorsten

Archimedes · 26 Dezember 2017, 13:15:17

Hallo, der Umzug von Raspberry PI B+ auf den PiB3 wurde von mir abgeschlossen. Eine Anleitung dazu habe ich auf meintechblog.de veröffentlicht (vielen Dank an Jörg). http://www.meintechblog.de/download/12994/ .
Abschliessend habe ich festgestellt, dass der Pi B3 mit stretch lite anscheinend ohne Probleme funktioniert, ein frisch aufgesetzter Pi B+ mit strech lite bei meiner Konfiguration allerdings Probleme bereitet. Das ganze ist somit wohl den eingeschränkten Ressourcen des älteren Systems zuzuschreiben. Gruß Axel