FHEM (Mein Cubie) startet unmotiviert neu

[Puschel74]

Nun hänge ich auch mal wieder mit meinem Latein am langen Seil.

Ab und zu hängt mein FHEM, warum weiß ich leider (noch) nicht.
Meist passierte das in der Nacht und zur schnellen Abhilfe hab ich dann eben den Cubie neu gestartet.
Unschön aber um 5 Uhr morgens habe ich selten mehr Zeit.

Da mich dann das in den Keller laufen und Stecker ziehen doch etwas gestört hat habe ich nach betateilchens How-To den Hardware-Watchdog installiert und eingerichtet.
Alles gut und schön, fast.
Nun ist mir aufgefallen das FHEM (oder doch der Cubie ?? ) öfters neu gestartet wird als ich mir das erwartet hatte.
Logischerweise findet sich im FHEM-Logfile nur die Startsequenz von FHEM und danach die ganz normalen Logeinträge.

Heute morgen war es dann wieder soweit allerdings war ich da bereits auf dem Weg zur Arbeit:

2015.08.10 05:53:49 3: CUL_HM set EG_Vorraum_Licht_HM on
2015.08.10 05:53:58 3: FS20 set EG_Bewegungsmelder_Eingang_innen off
2015.08.10 05:55:33 2: Perfmon: ready to watch out for delays greater than one second
2015.08.10 05:55:33 1: Including fhem.cfg
2015.08.10 05:55:33 3: telnetPort: port 7072 opened

Knapp 1 1/2 Minuten nach dem letzten Logeintrag wurde FHEM neu gestartet - um 05:53:38 habe ich wohl das Haus verlassen.
Das scheint FHEM (oder der Cubie) gnadenlos ausgenutzt zu haben 

In der watchdog.conf habe ich allerdings eine change = 600 eingetragen (was nach Adam Riese eigentlich 10 Minuten sein sollten).

Per at lasse ich FHEM die fhem.heartbeat minütlichen "betatschen".

Code Auswählen Erweitern

define heartbeat at +*00:01:00 {qx(touch /media/HDD/fhem/log/fhem.heartbeat)}

Die Zugriffszeit der Datei ändert sich auch minütlich (wenn ich mir das mal ein paar Minuten über Putty anschaue) aber irgendwie beschleicht mich das dumpfe Gefühl das der Watchdog dennoch zuschlägt denn eine andere Möglichkeit FHEM automatisch neu zu starten habe ich nirgends eingebaut.
Bis heute morgen lief FHEM auch knapp über 5 Tage durch aber heute morgen eben wieder der Neustart.

Nun würde ich das ganze gerne ergründen - weiß aber leider nicht wo ich ansetzen soll und bin für jeden Tipp dankbar.

Nachtrag: Das war der letzte Reboot vor rund 5 Tagen

2015.08.04 21:08:11 3: CUL_HM set OG_Flur_Licht off
2015.08.04 21:08:13 1: CUL_WS UNDEFINED temp/hum sensor detected, code 5
2015.08.04 21:10:10 2: Perfmon: ready to watch out for delays greater than one second
2015.08.04 21:10:10 1: Including fhem.cfg
2015.08.04 21:10:11 3: telnetPort: port 7072 opened

Hier waren es knapp 2 Minuten bis FHEM neu gestartet hat.

[tobias.gj]

Ich hatte den Effekt auch und habe die Ursache nicht gefunden.
Am Ende habe ich das neueste Igor Image installiert und das System neu aufgesetzt.
Seitdem alles wieder perfekt und stabil.

[Puschel74]

Danke schonmal für die Antwort.
Dann werd ich auf meinen 2.ten Cubie mal das aktuelle Igor-Image draufwerfen.
Wusste doch das der nochmal für was gut sein wird 

[marvin78]

Ich persönlich denke ja, dass ein Neustart, nur weil FHEM abstürzt, ein absoluter Overkill ist. FHEM neu starten reicht doch (in den meisten Fällen).

[Puschel74]

Da geb ich dir recht.
Mir würde ja schon genügen wenn ich wüsste warum FHEM vermutlich die fhem.heartbeat nicht mehr per at anfasst - und das länger als 10 Minuten lt. watchdog.conf.
Vermutlich deshalb weil es die einzige (von mir eingebaute) Möglichkeit ist.

perfmon wirft mir im Log ja auch nichts auffälliges aus.
Hier mal eine Sekunde da mal eine Sekunde aber das at triggert minütlich und der watchdog sollte erst nach 10 Minuten greifen (und nicht nach ~ 2 Minuten den Cubie neu starten).

Edith: Ich werd mich wohl doch wieder mal mit den Linux"untiefen" vertraut machen (müssen).

[Dr. Boris Neubert]

Hallo,

ich hatte und habe ggf. immer noch das Problem, dass sich FHEM im Laufe einer Woche mit soviel Speicher vollfrisst, dass der Prozess wegen Out-of-Memory gekillt wird bzw. nicht mehr in der Lage ist, noch irgendwelche Aktivitäten auszuführen.

Um der Sache auf die Schliche zu kommen, könntest Du periodisch die Prozessliste nebst Timestamp loggen und Dir anschauen, was um den Zeitpunkt des Crashs herum mit dem fhem.pl-Prozess los war.

Viele Grüße
Boris

[Puschel74]

Hm ok.
Das klingt erstmal nicht so schlecht resp. ist ein Anhaltspunkt.

Das System inkl. FHEM läuft auf dem Cubie im NAND und die Daten (Logfile und Datenbank) sind auf einer SSD.
micro-SD ist keine im Cubie verbaut.

Danke Boris, da werd ich mich mal einlesen.

[Dr. Boris Neubert]

Bash:

Code Auswählen Erweitern

while sleep 60; do 
date
ps -fle
done > /tmp/log

[Wernieman]

eventuell noch memory (free) oder andere Daten mitloggen ...

[Puschel74]

Danke Boris und Wernieman.
Ich bin grad auf meinem jungfräulichen Cubietruck das System auf den nand am installieren damit ich ein Ersatzsystem habe.
Dann werde ich auf meinem Produktivsystem eure Tipps mal einwerfen und hoffen das der watchdog wieder zuschlägt.

[Tion]

Hast du mal mit Sysmon nach der Cpu Temperature geschaut?
Ich hatte meinen 2. Cubie mit Gehäuse bestellt aber dort war die Temperatur über 40°C.
Das System war absolut unstabil.Also raus aus dem Gehäuse. Ist dann bei ~37° über ein halbes Jahr ohne Absturz gelaufen.
Bis zu Sommer,  dann haben die Abstürze bei ~39°C wieder angefangen.
Habe mir jetzt einen 80er 12v lüfter draufgemacht , der an der 3,3v gpio Versorgung hängt.
Läuft jetzt mit max 31°C seit 3 Wochen wieder ohne Probleme.
Gruß Volker

[moonsorrox]

Hast du mal mit Sysmon nach der Cpu Temperature geschaut?

das denke ich ist nicht das Problem, mein Cubie läuft seit eh und je und ich habe fast immer um die 50° momentan 52,10°
Ich hatte mal gelesen das die CPU Frequenz Probleme gemacht obwohl die wohl variiert, wenn ich machmal schaue liegt sie um 480 MHz momentan aber bei 1008 MHz.
betateilchen hatte da mal irgendwo etwas zu geschrieben, weil der auch diese Probleme hatte

[Puschel74]

So, nachdem der Cubie dank des Watchdog gestern Nacht wieder einen restart hingelegt hat habe ich mal Boris Vorschlag in ein Skript gepackt.
@werniemann - free wird mit Boris Vorschlag auch mitgeloggt resp ich habe das in das Skript mit eingebaut.
@Tion
Ein Temperaturproblem hatte ich früher schon ausgeschlossen.
Frei stehend ohne Gehäuse im Keller bei max 22 °C Raumtemperatur sollte kein Problem sein.

Wobei mir das ps -fle so doch einiges an Daten liefert - aber ich denke mal Boris kann damit sicher was anfangen 
Die manpage zu ps hab ich mir natürlich angeschaut und weiß nun auch was -fle bedeutet - und die Einträge hab ich mir vorher auch angeschaut.
Nun warte ich mal ab was in den Logfiles so aufschlägt.
Wenn Fragen auftauchen meld ich mich sicher wieder 

Edith: So, nachdem FHEM gestern um 19:57:55 wieder neu gestartet wurde und ich das nichtmal bemerkt hatte (das Skript habe ich aber leider erst um 20:59:34 gestartet) viel mir doch ein das ich
den Hauptspeicher ja bereits mitlogge und als Plot anzeige.
Ich werd das at mit dem heartbeat wohl mal nicht nur touchen lassen sondern date in die Datei schreiben lassen.

[Virgon]

Ich hatte mal ein ähnliches Problem mit meinem Cubietruck. Er hing sich sporadisch komplett auf.
Es war keinerlei Kommunikation oder Bedienung mehr möglich.
Damals hatte Ich den Watchdog nicht aktiv geschaltet, daher gab es keine Neustarts/Reboots.
Die Spannungsversorgung war laut Logdatei von Sysmon stabil.

Bei einem gewollten Reboot hat sich die (etwas ältere) SSD (FHEM Datenlaufwerk inkl. MySQL-Daten) verabschiedet.
Nach dem Austausch (ist diesmal eine Festplatte) gab es keine Probleme mehr.

Vielleicht hilft dir das weiter.

[Puschel74]

Nein, aber dennoch danke.