Hallo,
ich habe vor kurzem ein Online Update von FHEM gemacht. Da ich eine längere Zeit keine Updates durchgeführt habe, wurde sehr viel geupdatet. Das Problem ist, dass ich seit dem ca 1 mal am Tag FHEM beendet. Dies passiert nach keinen Muster was ich erkennen kann.
Was habe ich bisher getan: Ich habe das Loglevel in global auf 5 gestellt, jedoch wird immer noch keine Meldung angezeigt die zum Absturz geführt haben könnte. Auch die Meldungen kurz vor den Abstürzen scheinen keine Gemeinsamkeiten zu haben. Ganz plötzlich ist FHEM einfach nicht mehr da. :/
Meine Frage nun: Wie kann ich weitere Nachforschungen anstellen? Welche Möglichkeiten zum Troubleshooten habe ich noch, um den Fehler oder ggf. das fehlerhafte Modul ausfindig zu machen?
Hm, klingt schwierig...
vielleicht zurück auf das Backup - und dann nach und nach die einzelnen updates reinnehmen..?
Was sagen den Perfmon und apptime zu deiner Konfiguration..?
Hi Siggi,
wenn du FHEM beendest und dann von der Konsole (Putty) aus startest, siehst du live die aktuellen Meldungen in der Shell. Zusätzlich kannst du das Attr. "global verbose" auf 4 oder 5 setzten. Ich würde in deinem Fall noch ein "update force" hinterherschieben (vielleicht wurde noch nicht alles geholt) oder die eigenen Daten sichern und FHEM neu aufsetzen.
Gruß
Frank
Warum immer gleich so drastisch? Falls es wirklich am update liegt, sieht man da Problem normalerweise im Log (spätestens bei verbose 5). Falls gar nicht weiter kommt und es tatsächlich an einem defekten Modul liegt, ein restore machen (siehe commandref).
Hallo,
bist Du dir sicher, dass der Rechner weiterläuft, wenn sich fhem verabschiedet? Startest du dann manuell neu? Welche Hardware verwendest Du?
schöne Grüße
Jo
Also FHEM läuft bei mir auf einem Raspberry Pi 2 unter raspbian. Bei einem Absturz starte ich fhem über "/etc/init.d/fhem start" als root. Das Log habe ich bereits auf verbose 5 laufen, jedoch ist leider kein Absturzgrund erkennbar. Auch die verbose 5 Logs mehrerer Abstürze besitzen keine Gemeinsamkeiten. Das Betriebssystem ist nicht abgestürzt, da FHEM bei einem Neustart mitstarten würde und in den Betriebssystemlogs nichts derartiges erkennbar ist.
@marvin: Meinst du mit restore ein Backup wieder einspielen?
@Lolo: Habe gerade kurz im Wiki über perfmon gelesen. Ist perfmon standardmäßig aktiv?
Also ein Backup wieder einspielen wäre natürlich ein Weg. Vorher wollte ich jedoch alle Möglichkeiten der Eingrenzung auslooten. :)
Hi,
Zitat@Lolo: Habe gerade kurz im Wiki über perfmon gelesen. Ist perfmon standardmäßig aktiv?
Nein, musst Du händisch reinkopieren und fhem neu starten. Ist aber auch kein Werkzeug zur Absturzanalyse sondern hilft dabei Verursachen zu finden die fhem blockieren.
Ich würde fhem über die cmd line starten und den Output beobachten.
vg
joerg
Zitat von: siggi85 am 06 Juni 2015, 18:10:08
@marvin: Meinst du mit restore ein Backup wieder einspielen?
Nein. Den FHEM Befehl restore. Deshalb schrieb ich "siehe commandref" dazu. Dort wird nämlich erklärt, was der macht.
Zitatrestore list []
restore []
Restore the files saved previously by the update command. Check the available files with the list argument. See also the update command and its restoreDirs attribute. After a restore normally a "shutdown restart" is necessary
Aber wie ich schon schrieb, muss das nur gemacht werden, wenn das Problem nicht anderweitig behebbar ist.
Also ich habe momentan das XBMC Modul im Verdacht, aber bevor ich das im jeweiligen Thread verbreite, teste ich gerade mit einer alten XBMC Modul Version. Mal schauen ob es was bringt. Ich halte euch auf dem Laufenden. Bis hier schon mal danke für eure Hilfe! :)
Ich habe seit einer Woche das gleiche Problem, bin aber auch noch nicht schlauer geworden
Zitat von: drdownload am 07 Juni 2015, 08:03:43
Ich habe seit einer Woche das gleiche Problem, bin aber auch noch nicht schlauer geworden
Nutzt du auch das XBMC Modul?
Also heute morgen lief mein FHEM mit der alten Version des XBMC Moduls noch. Mal gucken ob das die nächsten Tage so bleibt. :)
Ja, ich habe auch zwei XBMC Instanzen über das Modul angebunden. Aber *aufholzklop* seit Samstag rennt FHEM wieder stabil.
Zitat von: drdownload am 08 Juni 2015, 09:33:02
Ja, ich habe auch zwei XBMC Instanzen über das Modul angebunden. Aber *aufholzklop* seit Samstag rennt FHEM wieder stabil.
Hast du was geändert? Gab es ein Update vom XBMC Modul? (ich glaube es wurde eine Version mit geändertem Pollingverfahren hochgeladen)
Ich lasse es erst mal mit der alten Version testweise weiterlaufen. :)
Ich habe eigentlich nichts geändert außer bei den meisten Devices ein event-on-update dazuzugeben.
Gestern ist allerdings FHEM kapital abgestürzt und hat sogar die FHEM cfg mit in den Abgrund gerissen.
Ich habe im Terminal gerade noch ein Meldung XBMC.pm unexpected whatever in line 603 gesehen.
Hallo,
ich habe seit ca. 4 - 5 Tagen ein ähnliches Problem.
fhem beendet sich nicht, sondern steht still. Aus dem log ist auch nicht ersichtlich, woran es liegen könnte. Äußere Ereignisse spielen keine Rolle.
XBMC nutze ich nicht.
Ich habe einen Überwachungsprozess zusätzlich laufen der nach 15 Minuten fhem beendet, wenn das nicht mehr aktiv ist und es dann neu startet.
Was ich aber gehäuft im log habe, sind Meldungen, dass http-Zugriffe auf meine Heizungsanlage, auf Netachmo usw. gelegentlich (so 5 - 10 Mal am Tag) nicht erfolgreich waren.
Und einmal habe ich kurz vor dem Stillstand von fhem einen Aufruf von blocking-Call !!!! im log gesehen.
Wer da blocking und nicht nonblocking verwendet, weiß ich nicht.
Werde aber mal in die Richtung versuchen weiter zu forschen.
Elektrolurch
Das Kalendermodul ist zB glaube ich noch blocking.
Was mir aufgefallen ist, dass zu dem Zeitpunkt als FHEM sich verabschiedet haben muss auch das Netzwerk gerade down war. uU gibt es da ein Modul dass den Fall nicht gut verträgt.
Genau, dass habe ich ja im Beitrag darüber auch geschrieben. Wohl mehr Störungen im Netzwerk / Internetzugriff und möglicherweise gibt es ein Modul, welches blocking calls macht und dann bleibt fhem hängen.
Das ist aber erst seit so ca. 4 Tagen. Ich müsste mal nachschauen, was da aktualisiert wurde und was ich davon verwende.
Vielleicht sind es die httputils?
Möglicherweise wurde da aber auch schon was früher aktualisiert und es fiel nicht auf, da Internet / Netzwerk ok liefen.
Gestern hatte ich vier Hängenbleiber, heute erst einen um 0:02 Uhr.
Und jetzt läuft es mit verbose 4 und schreibt die Platte voll....
Mal kurz den Stand zu meinem Problem: Also mit dem alten XBMC Modul läuft es bei mir mittlerweile. :)
ALso ich denke ich habe den Bösewicht gefunden, seitdem ich das EM (Elektromonitor) Modul von Elektrolurch entfernt habe ist mir zumindest nicht mehr die Konfig zerschossen worden uns seit ca. 1 Woche kein Absturz
Das EM sichert einmal je Stunde seine Daten, wenn das Attribut "autosave" = 1 gesetzt ist.
Ansonsten wird nichts geschrieben und somit auch die Konfig nicht angerührt.
Ich habe eher eine andere Beobachtung gemacht: Auf der FB7390 wird es mit fhem mit dem Speicher bei mir knapp. Ich habe Module mal herausgenommen, die ich nicht unbedingt brauche -> und siehe da, die völlig unmotivierten Abstürze sind weg.
Elektrolurch
Ich habe die zerschossenen fhem.cfgs verglichen und sie brechen immer bei der EM reading group ab und seitdem ich das Modul rausgenommeen habe bin ich auch absturzfrei. Eigentlich sollte FHEM hier keine Performance Probleme habe da es auf einem Atom mit 2GB RAM rennt.