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
evtl ein blockierendes modul. http://fhem.de/commandref.html#apptime evtl hilft das
Ich habe bei mir das gleiche Problem seit über einem Jahr und hab auch schon mit apptime und ähnlichem geforscht, aber bisher leider erfolglos.
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.
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...
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
Zitat von: MiWe58 am 06 Dezember 2015, 17:26:05
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).
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?
Schaut mal hier:
das sind die Aufzeichnungen vom Sysmon während der Phase mit fehlendem Zugriff auf fhemweb:
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
Zitat von: MiWe58 am 08 Dezember 2015, 14:48:17
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.
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?
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
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.
Du hast bisher nicht geschrieben, auf was für ein System Dein FHEM läuft:
RasPi, BBB o.Ä.?
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
Die Meldungen aus dem Log sind sicher ein Hinweis, häufig sind aber die Meldungen zeitlich kurz davor interessant, weil sie Hinweise geben könnten, wer hier einen fork machen wollte.
Es wäre interessant zu hören welche Devices/Typen in Betrieb sind, insbesondere wo forks gemacht werden...
Was sind denn bitte forcs? Ich verstehe leider nur "Bahnhof"
Hatte ich zwar oben schon versucht zu erklären, aber hier etwas genauer: https://de.m.wikipedia.org/wiki/Fork_(Unix)
Für mich liegt die Vermutung nahe, dass der beschriebene Fehler mit Fhemweb und SSL im Zusammenhang steht
2015.12.21 18:34:40.076 1: FHEMWEB SSL/HTTPS error:
Das Logfile hat keine weiteren Auffälligkeiten in der "Vorgeschichte" gezeigt.
Diesen Fehler aus dem Logfile habe ich wiederholt erhalten, wenn der Zugriff nicht möglich war.
HTTPS habe ich seither wieder abgeschaltet und seither keine Fehler mehr.
Sollte es neue ERkenntnisse geben, melde ich mich wieder
Gruß
und schöne Feiertage
Michael
Auch bei mir habe ich das Problem aktuell beobachtet.
Raspi2, Raspbian, FHEM 5.7 aber nicht tagesaktuell.
Uptime des Systems bisher ca. 17 Tage, tritt auch erst seit gestern auf, Hänger ca. 5-20 Sekunden, bis wieder eine Seite lädt.
Verwende kein HTTPS.
Kann es sein das der Speicherkarte im Raspberry leicht beschädigt ist und das dies der Ursache ist wenn bestimmte Speicherplatz auf dem Speicherkarte angesprochen werden? Bei mir friert FHEM auch öfter ein Aber der Raspberry lauft weiter
Moin,
wenn ich es richtig gelesen habt nutzt Ihr einen Rpi2 mit SD und es ist noch freier Speicher auf der SD vorhanden.
1. Nutzt Ihr LAN oder WLAN ?
(Bei WLAN gibt es hier im Forum einen Thread, wo die USB-Einstellungen der "/boot/cmdline.txt" genauer erklärt werden. Und im Netz, wie Wlan-Adaptern der Sleep-Modus abgewöhnt werden kann.)
2. Blinkt beim Rpi2 die rote LED?
Sind es Probleme mit der Spannungsversorgung.
3. Habt Ihr mehrere USB-Devices ohne aktives USB-HUB angeschlossen?
4. Habt Ihr den Rpi2 per "sudo raspi-config" hochgetaktet ?
(Damit kommen nicht alle SD, HDD und USB-STICK klar. Hatte mir einen USB-STICK in einer Std. "gekocht".)
5. Bei mir hatte eine Kombination von einem USB-1wire-Adapter mit 2*PROPLANTA, 2*Weather und 2*Twilight (ohne rote LED "Disco") auch zu ähnlichen Effekten geführt.
(Abhilfe F2F oder per at die Updates der Module, die auf externe Daten zugreifen zeitlich versetzen.)
Vielleicht hilf es bei der Fehlersuche...
Viele Grüße
Sunny
Zitat von: Sunny am 29 Januar 2016, 03:32:15
1. Nutzt Ihr LAN oder WLAN ?
(Bei WLAN gibt es hier im Forum einen Thread, wo die USB-Einstellungen der "/boot/cmdline.txt" genauer erklärt werden. Und im Netz, wie Wlan-Adaptern der Sleep-Modus abgewöhnt werden kann.)
LAN
2. Blinkt beim Rpi2 die rote LED?
Sind es Probleme mit der Spannungsversorgung.
Bisher nicht aufgefallen
3. Habt Ihr mehrere USB-Devices ohne aktives USB-HUB angeschlossen?
Kein USB-Device
4. Habt Ihr den Rpi2 per "sudo raspi-config" hochgetaktet ?
(Damit kommen nicht alle SD, HDD und USB-STICK klar. Hatte mir einen USB-STICK in einer Std. "gekocht".)
Nein
5. Bei mir hatte eine Kombination von einem USB-1wire-Adapter mit 2*PROPLANTA, 2*Weather und 2*Twilight (ohne rote LED "Disco") auch zu ähnlichen Effekten geführt.
(Abhilfe F2F oder per at die Updates der Module, die auf externe Daten zugreifen zeitlich versetzen.)
Anbei mein derzeitiger Stand:
Ich habe eher durch einen Zufall einen zeitlichen und reproduzierbaren Zusammenhang während des Betriebes der "Waschmaschine / Trockner" mit diesem Effekt festgestellt.
gewundert hat mich, dass es offenbar kein "elektrischer Störeinfluss war, denn dann hätte der Raspi an sich Fehler zeigen müssen. Es war eben nur der fehlende Zugriff auf die Fhem-Oberfläche zusammen mit hoher Prozessorauslastung, die ich über das Sysmon Modul festgestellt habe
Waschmaschine/Trockner sind "Großverbraucher" die über die Homematik HM-ES-PMSw1-Pl Schaltsteckdose mit Strommessfunktion angeschlossen war. Die Messwerte dieses Adapters werden über das Statistik-Modul verarbeitet.
Nun habe ich die Vermutung, dass die stetige Neuberechnung der Messwerte, während des Laufes der "Großverbraucher) Waschmaschine / Trockner zu einer hohen CPU-Belastung geführt haben, die den RASPI quasi "blockiert" haben.
Ob diese Erklärung so passt, kann ich nicht mit Bestimmtheit sagen.
Was aber reproduzierbar ist, ist der beschriebene Effekt in dem Fall, wenn ein "Großverbraucher " an der HM-ES-PMSw1-Pl Stechdose angeschlossen ist.
Dabei habe ich auch die Steckdosen HM-ES-PMSw1-Pl gewechselt, wodurch der Effekt unabhängig vom einzelnen Gerät auftaucht.
Soweit mein Stand zur Sache
Derzeit habe ich die Steckdose entfernt und seither käuft alles
Hallo,
Ich hätte noch eine Idee bezüglich des Fork. Es kann auch sein das die maximale Anzahl der Prozesse erreicht ist und dann kann auch kein weiterer mehr gestartet werden. Läuft dein fhem als root oder als User?
Schau dir mal dir mal die man Page ulimit an.
ulimit -a
mit dem User der fhem laufen läßt. Dort kann auch der Speicher limitiert werden.
Gruß
Eisix
@Eisix
anbei im Anhang der Screenshot vom "ulimit -a" Leider kann ich mit den Angaben nichts anfangen. Aber vielleicht gibt es Dir Hinweise
Moin Michael,
hast Du bei Deinen Verbrauchern, mit "event-on-change-reading", "event-on-update-reading und ""event-min-interval" die "Gesprächigkeit" reduziert?
Dann wird auch die "Grundlast der CPU" reduziert.
Wobei für mich "event-on-change-reading" mit "<readingA>:<SchwelleA>,<readingB>:<SchwelleB>", der beste Filter ist.
z.B.
ZitatAmpere:0.1,state,Temperatur:1,Volt:5,Watt:0.5,wh:5
Vielleicht hilft es Dir...
Viele Grüße
Sunny
max user processes ist 7339
Ein top sollte dir zeigen wieviele Prozesse laufen und ob du in die Nähe des Wertes kommst. Natürlich nur kurz vor oder während des einfrieren.
Kann eventuell auch mit dem Modul sysmon überwacht werden. Habe ich aber noch nie benutzt.
Gruß
Eisix
Hallo,
bevor ich das Thema als "gelöst" markiere, wollte ich sicher sein, dass es das auch ist.
Daher die Zeitverzögerung bis zu dieser Meldung.
verbaut habe ich in meiner Installation:
5* HM-ES-PMSw1-Pl
2* HM-ES-TX-WM
auf diese Devices wird das "statistics" Modul angewandt.
Diese Kombination hat offenbar, inbesondere bei Aktivirung von stromfressenden Verbrauchern, wie z.B. Waschmaschine, zu einer zeitweise sehr hohen CPU-Belastung durch das Auflaufen von Logs im Logfile gesorgt. Dieses wiederum führte zu den beschriebenen Ausfällen:
Kein Zugang zum FHEMWEB.
Oft war dieser Effekt nur temporär, jedoch für Zeitspannen von 30 Minuten bis nahezu 2 Std. zu beobachten.
Oft hat das System nach dieser Zeit wieder "normal" reagiert
Bisherige Lösung:
Drastisches Einschränken der produzierten Logs im Logfile
Soweit läuft bisher alles sehr gut und auch sehr performant
Ich beobachte bei mir Ähnliches. Ich habe das SHM Modul im Verdacht. Als neulich das Sunny Portal nicht erreichbar war, war die Weboberfläche komplett blockiert sobald nach FHEM Start die erste SHM Abfrage kam. FHEM war aber komplett blockiert. Abhilfe brachte nur killen von Perl per SSH Konsole und Neustart von FHEM. Hatte dann dann SHM komplett aus der config rausgenommen, dann lief es. BananaPi mit COC
Gesendet von iPhone mit Tapatalk
Zur Not kann man blokierende Module auch in eine eigene FHEM Instanz verbannen und über FHEM2FHEM anbinden.
Mal eine ganz andere Theorie:
Nutzt ihr eine Fritzbox? Wenn ja mal einen Reboot versuchen.
Das hat schon in einigen Faellen zur Loesung solcher Probleme beigetragen.
Gruß
Markus
Bei den Messadaptern die Messschwellen und den Delay für die Messwertübertragung anpassen.
stromer on tour