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

[viegener]

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...

[MiWe58]

Was sind denn bitte forcs? Ich verstehe leider nur "Bahnhof"

[dev0]

Hatte ich zwar oben schon versucht zu erklären, aber hier etwas genauer: https://de.m.wikipedia.org/wiki/Fork_(Unix)

[MiWe58]

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

[heikoh81]

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.

[Von-XS1-Nach-FHEM]

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

[Sunny]

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
   

[MiWe58]

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

[Eisix]

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

[MiWe58]

@Eisix

anbei im Anhang der Screenshot vom "ulimit -a" Leider kann ich mit den Angaben nichts anfangen. Aber vielleicht gibt es Dir Hinweise

[Sunny]

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.

Ampere:0.1,state,Temperatur:1,Volt:5,Watt:0.5,wh:5

Vielleicht hilft es Dir...

Viele Grüße
Sunny

[Eisix]

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

[MiWe58]

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

[Waldmensch]

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

[dev0]

Zur Not kann man blokierende Module auch in eine eigene FHEM Instanz verbannen und über FHEM2FHEM anbinden.