fhem haengt sich auf =(

[micomat]

Hallo zusammen,

ich hab seit gestern das Problem, dass ein paar Minuten nach dem Start von FHEM, wenn ich beispielsweise "list" eingebe, keine Reaktion des WebGUI mehr kommt
Nur noch ein Neustart auf der Konsole hilft dann weiter.
Im Log ist soweit nichts, was auf einen Fehler hindeutet.... Ein update von fhem hab ich schon gemacht, den RPi neu gestartet, ebenso HMLAN. Leider brachte nichts den gewuenschten Erfolg Ein paar Minuten nach dem Start, ists wieder tot.

Konfigurationsaenderungen sind in den letzten Tagen keine erfolgt.

Gruß
Markus

[isy]

Hi Markus,
Ich würde mal mit Austausch der SD Karte starten. Ich in nach genügend Abbrüche auf Jessie umgezogen. Bis auf meine aktuellen SSL  Themen ging das ganz gut.

Im Fhem selber habe ich zur Zeit Ärger mit SSL. Habe beispielsweise ein Nexus 5 Tablet im Dauerbetrieb, dass nach der Erkenntnis jetzt auf einem Port ohne SSL funkt. Ohne Probleme.
Wenn bei mir "genug" SSL Fehler im Log stehen, hängt, wenn ich Glück habe das Web GUI,  wenn ich Pech habe muss ich das Netzteil vom PI ziehen.

Bleibt ein Zugriff über Telnet (7072) möglich?

Gruß Helmut

[micomat]

das mit telnet muss ich mal probieren... danke fuer den tip.
ich habe auch vorhin mal im verbose 5 log gesehen, dass das statistics modul wahnsinnig viel "macht"... seitdem ich das deaktiviert hab, scheint es aktuell besser zu sein.

gruß
markus

[micomat]

Okay, eben wieder abgekackt... HMLAN blinkt, telnet geht nicht.
Das Log scheint einfach aufzuhoeren:

Code Auswählen Erweitern

2015.11.07 11:24:56 5: HMLAN_Parse: HMLAN1 R:E303AFC   stat:0000 t:00EAB3D7 d:FF r:FFB1     m:E1 865A 303AFC 000000 A4DE33
2015.11.07 11:24:56 5: HMLAN1 dispatch A0CE1865A303AFC000000A4DE33::-79:HMLAN1
2015.11.07 11:24:56 5: Triggering RT_Schlafzimmer_Climate (4 changes)
2015.11.07 11:24:56 5: Notify loop for RT_Schlafzimmer_Climate desired-temp: 20.5
2015.11.07 11:24:56 5: rg_temphum: not on any display, ignoring notify
2015.11.07 11:25:04 4: Connection accepted from FHEMWEB:192.168.178.159:38458
2015.11.07 11:25:04 4: FHEMWEB:192.168.178.159:38458 GET /fhem/images/KindleDisplay_SZ.png; BUFLEN:0

Kein Fehler, Keine Nachricht, nix...

[micomat]

SD Karte geklont, leider auch ohne Erfolg
Hat denn niemand eine Idee?

[Icinger]

Platz is noch genug auf der Karte?

[micomat]

die is/war halb leer...
bin in meiner verzweiflung nun dabei einen neuen RPi2 aufzusetzen und dann ein backup einzuspielen, in der hoffnung das das dann funktioniert.

[isy]

Hast du mal apptime gestartet? Gibt evtl Hinweise auf Funktionen, dev zu viel Zeit brauchen.
Gruß  Helmut

[viegener]

Die Vermutung wäre, dass es vermutlich ein Modul gibt, dass sich nicht "ordentlich" verhält (Endlosschleife / etc). Wenn es gar keine Hinweise gibt Log / Änderungen etc würde ich 2 Varianten empfehlen:

1) fhem.cfg teilweise deaktivieren und wenn sicher ist, dass es noch funktioniert, erst dann weitere Devices hinzufügen.

2) Zurückgehen auf die alte Version (vor dem Update / etc) und einzeln Dateien aus dem Update hinzufügen.

Zumindest unter der Annahme, dass Du bereits global verbose 5 eingeschaltet hast...

[micomat]

Danke fuer eure Antworten.
Ich hab gestern wie gesagt einen komplett neuen Pi2 mit neuer SD aufgesetzt. Sah auch soweit gut aus. Aber der Fehler ist wieder aufgetaucht.
Einen Verdacht hab ich inzwischen:
Ich konvertiere mittels ImageMagick SVGs zu PNGs und zeige diese auf Kindles als Screensaver an.

Nun habe ich gestern dieses PNG aufgerufen, http://meinfhem:8083/fhem/www/images/bild.png und schon war die Kiste tot.
Der Perl Prozess von fhem laeuft noch, reagiert aber nicht mehr.
Irgendeine Idee wie ich das debuggen kann?

Apptime werde ich versuchen
Restore von vor einer Woche habe ich bereits gemacht.

Danke,
Markus

[viegener]

Ich konvertiere mittels ImageMagick SVGs zu PNGs und zeige diese auf Kindles als Screensaver an.

Nun habe ich gestern dieses PNG aufgerufen, http://meinfhem:8083/fhem/www/images/bild.png und schon war die Kiste tot.
Der Perl Prozess von fhem laeuft noch, reagiert aber nicht mehr.
Irgendeine Idee wie ich das debuggen kann?

Apptime werde ich versuchen
Restore von vor einer Woche habe ich bereits gemacht.

Wie konvertierst Du denn mit imagemagick, hast Du ein zusätzliches FHEM-modul oder läuft imagemagick als separater Prozess.

Generell sollte der Zugriff auf ein Bilddatei nichts anderes machen als die Datei öffnen und den Inhalt an den Browser zurückliefern. Allerdings läuft dies meines Wissens nach in fhemweb blocking ab. Wenn mir auch erstmal keine Begründung einfällt, warum das in eine Endloschleife laufen sollte.

Ich würde mal hingehen und Debugausgaben in fhemweb einbauen (vorzugsweise in FW_returnFileAsStream) um zu schauen, ob du sehen kannst, dass der Hänger dort passiert. Ansonsten kann ich mir nur vorstellen, dass die beiden Vorgänge konvertieren nach png und Ausliefern der Datei sich irgendwie ins Gehege kommen (deadlock ?)

Johannes

[micomat]

Hallo Johannes,

danke fuer den Tip. Aber mit "blocking" kann ich jetzt nicht wirklich was anfangen. Bin kein Softwareentwickler.

Fuer die Konvertierung verwende ich das FileReplacer Modul. Hier wird dann ImageMagick getriggert.
Wobei mir mein Bauchgefuehl sagt, es liegt eher am Webzugriff.
Werde mal mit den Debug-Ausgaben und Verbose Level 5 versuchen den Fehler zu reproduzieren.

Gruß
Markus

[viegener]

Hallo Markus,
mit blocking meinte ich, dass während des Transfers der Daten für eine Datei nichts anderes stattfinden kann, allerdings ohne jetzt ein Experte in FHEMWeb zu sein.

Die Frage, die mich noch beschäftigt ist die Frage, ob ImageMagick oder FReplace vielleicht auf dieselbe Datei zugreifen und dadurch die Situation entsteht?
Ist es jeweils dieselbe Datei, die überschrieben wird?
Wenn Du Debug einbaust macht es vielleicht Sinn hier auch FReplace einzuschliessen.

Gruss,
Johannes