[gelöst] FHEMWEB friert sporadisch ein...

[MiWe58]

Hallo,

seit einiger Zeit, "kämpfe" ich mit einem Phänomen, was sich dadurch bemerkbar macht, dass die Fhem - Web-Oberfläche zeitweise nicht erreichbar zu sein scheint. Das mache ich an "unendlich langen" Browser-Ladezeiten fest, die ins Timeout laufen.

Während dieses Phänomens ist der Raspi weiterhin über Putty erreichbar, ohne dass dort etwas auffälliges wahrnehmbar wäre
Sofern der Zugang zum Fhemweb wieder möglich ist, sind bisher keine Auffälligkeiten im Logfile erksichtlich
Weiterhin werden die Steuerungsbefehle von fhem ausgeführt

Aus meiner Sicht scheint es tatsächlich nur der Zugang zum Web-Interface zu sein.
- unanhängig vom Browser
- unabhängig von http oder https


Folgendes habe ich bereits ergebnislos versucht:
- Komplette Neuinstallation auf blanker Speicherkarte
- Das Problem bleibt, wenn eine geklonte Speicherkarte eingesetzt wird
- Nach RasPi Reboot bleibt das Problem


Das Problem liegt nicht dauerhaft vor:
Nach einer "gewissen Wartezeit", einen Zeitraum kann ich hierzu nicht zuverlässig angeben, ist der Zugang wieder da. Alles funktioniert dann perfekt. Kurze Antwortzeiten wie gewohnt. Irgendwann tritt der Effekt wieder auf.

Ich erkenne einfach keine Gesetzmäßigkeit.

Wer hat Tipps zur weiteren Fehlersuche...

Gruß

Michael

[chris1284]

evtl ein blockierendes modul. http://fhem.de/commandref.html#apptime evtl hilft das

[reibuehl]

Ich habe bei mir das gleiche Problem seit über einem Jahr und hab auch schon mit apptime und ähnlichem geforscht, aber bisher leider erfolglos.

[Kharim]

Ganz spontan klingt das für mich nach einem Sleep?
Zumindest hatte ich dieses Verhalten wenn ich in notify und Co versehentlich ein "Fhem-Sleep" eingebaut habe......
Sprich ein Sleep xyz Befehl der nicht nur die Notify warten lässt, sondern das gesamte FHEM.
Dann sollten aber die blockierten Zeiten gleich sein.

[viegener]

Annahme, es ist nicht das Betriebssystem sondern liegt irgendwo in FHEM, wie von Dir dargelegt.

Zur Fehlersuche:

Einen widerkehrenden at-befehl der alle Sekunde / 5 Sekunden einen Eintrag ins fhem log schreibt. Wenn das Problem auftritt sollte erkennbar sein, ob wirklich FHEM in der Zeit sauber weiterläuft (also ob die Einträge alle 5 Sekunden geschrieben werden).
und während des Hängens mal bewusst ein telnet zu FHEM offen haben und Befehl absetzen.

Hast Du mal andere Browser/Systeme probiert vielleicht ist das Problem nicht FHEM sondern der Browser?

Wenn es FHEM ist, dann ist wohlwirklich apptime ein guter Ansatz. Die Ausgabe von apptime hier posten, dann kriegt man geholfen...

[MiWe58]

Fehler ist unabhängig von Browser und Gerät mit dem zugegriffen wird.
Habe ich auch geschrieben.

"sleep" wird nirgends verwendet
Das mit dem "at" werde ich mal beobachten
Apptime werde ich in den kommenden Tagen mal probieren, ob ich da etwas finde

Postings kommen, sobald ergebnisse vorliegen

[viegener]

Fehler ist unabhängig von Browser und Gerät mit dem zugegriffen wird.

Oops, das mit den Browsern hatte ich überlesen, Sorry.

Ansonsten untermauert das die Vermutung, dass FHEM anhält (blockt). Für ein Einfrieren nur von fhemweb fehlt mir ein Ansatz, aber ausser sleep können es natürlich auch noch Module sein, die blockierende Netzzugriffe machen (nicht nur http sondern auch DNS etc).

[reibuehl]

Wenn ich apptime mit dem in der comandref beschriebenen Parameter all für die Ausgabe aller Werte aufrufe, bekomme ich die Fehlermeldung "all undefined field, use one of count,max,total,funktion,average,name,maxDly,clear". Ist das ein Fehler in der Commandref?

[MiWe58]

Schaut mal hier:

das sind die Aufzeichnungen vom Sysmon während der Phase mit fehlendem Zugriff auf fhemweb:

[MiWe58]

Weitere Fehler habe ich bisher nicht finden können:

Durch das Update auf 5.7 sind einige Warnings im Logfile entstanden, die ich nun durch Anpassungen der fhem.cfg beseitigen konnte.
DEnen hatte ich bisher wenig bedeutung beigemessen. ((%EVTPART1) geändert in ($EVTPART1))

Seit diese Warnings beseitigt wurden, läuft das System nun durch, ohne das der beschriebene Effekt seither wieder aufgetaucht ist.
Kann das die Ursache gewesen sein???

Gruß
Michael

[viegener]

Seit diese Warnings beseitigt wurden, läuft das System nun durch, ohne das der beschriebene Effekt seither wieder aufgetaucht ist.
Kann das die Ursache gewesen sein???

Ohne die Änderungen und logs zu kennen ist das eigentlich nicht zu beantworten. Macht aber vielleicht auch keinen Sinn hier zu spekulieren.
Solange es aber nicht mehr reproduzierbar ist und nicht wieder auftritt, erstmal lassen, auch wenn ich verstehe, dass ein ungutes Gefühl bleibt.

[MiWe58]

Mehrere Tage habe ich den beschriebenen Effekt nicht beobachten können.

Heute habe ich diese Zeilen im Log entdeckt. Das könnte zeitlich mit dem Effekt übereinstimmen.
Was bedeutet die Fehlermeldung und wodurch kann sie verursacht werden?

Code Auswählen Erweitern

2015.12.15 16:31:11.596 1: Cannot fork: Cannot allocate memory
2015.12.15 16:31:11.597 1: Cannot fork: Cannot allocate memory
2015.12.15 16:31:11.604 1: Cannot fork: Cannot allocate memory
2015.12.15 16:31:11.604 1: Cannot fork: Cannot allocate memory
2015.12.15 16:31:11.615 1: Cannot fork: Cannot allocate memory
2015.12.15 16:31:11.616 1: Cannot fork: Cannot allocate memory
2015.12.15 16:31:11.623 1: Cannot fork: Cannot allocate memory
2015.12.15 16:31:11.624 1: Cannot fork: Cannot allocate memory
2015.12.15 16:31:11.631 1: Cannot fork: Cannot allocate memory
2015.12.15 16:31:11.632 1: Cannot fork: Cannot allocate memory
2015.12.15 16:31:11.729 1: Cannot fork: Cannot allocate memory

[dev0]

Bedeutet, dass ein zusätzlicher Prozess (plotfork, Sonos, whatever) gestartet werden sollte, aber kein Speicher mehr dafür zur Verfügung stand.
attr global verbose 5 und stacktrace 1 werden Dir bei der Suche helfen.

[Wernieman]

Du hast bisher nicht geschrieben, auf was für ein System Dein FHEM läuft:
RasPi, BBB o.Ä.?

[MiWe58]

Sorry,

das System läuft auf dem RasPi II mit 16GB SD-Speicher. Class 10
Über Sysmon habe ich bisher nie Probleme mit Speichernutzung feststellen können.
Der Fehler ist bisher beim Tausch einer Speicherkarte konstant, dh. unabhängig davon geblieben