FHEM/FHEMWEB hängt sich von Zeit zu Zeit auf

[connormcl]

Ab und zu nach längerer Laufzeit...1-2 Wochen, ist das Webfrontend von FHEM bei mir nicht mehr erreichbar.
Laut Logfile funktioniert alles ganz normal und weiterhin im Hintergrund.

Mein perl ist mit Version 5.22 aufgrund von LEDE etwas veraltet. Werde FHEM bald auf Debian umziehen und hoffe, dass es dann besser läuft.

Da ich aktuell eh kein aussagekräftiges Log habe, wollte ich fragen:

- ist das Problem bekannt?
- benötigt FHEMWEB bestimmte Softwareversionen von Perl u.a., um korrekt zu funktionieren?
- mit welchen Optionen kann ich das Problem Loggen, wenn es erst nach 1-2 Wochen auftritt? (Stichworte Logvolumen und Inhalt)?


EDIT: handelt sich wohl nicht nur um ein FHEMWEB Problem...auch Temperaturdaten vom nanoCUL haben aufgehört geloggt zu werden. Allerdings kamen Statusmeldungen bezüglich CCU2 bis zuletzt durch. Daher bitte um Verschiebung, falls ich hier dann doch nicht richtig bin.

[rudolfkoenig]

- ist das Problem bekannt?

Mir nicht.

- benötigt FHEMWEB bestimmte Softwareversionen von Perl u.a., um korrekt zu funktionieren?

Ich meine FHEMWEB funktioniert mit perl 5.8.3 und neuer, ich teste es regelmaessig nur mit 5.16/5.20/5.24.

- mit welchen Optionen kann ich das Problem Loggen, wenn es erst nach 1-2 Wochen auftritt? (Stichworte Logvolumen und Inhalt)?

Zum debuggen sollte "attr WEB verbose 4" reichen, aber das erzeugt auch einiges an loglevel. Wenn man sicher ist, dass es an FHEMWEB liegt, dann kann man sich ja per telnet anmelden, und dieses Attribut erst nach dem Verklemmen setzen.
Man kann aber auch "telnet fhemhost 80803" absetzen, und da "GET /fhem" und zweimal return tippen, damit kann man das Problem auch etwas einschraenken.

Daher bitte um Verschiebung, falls ich hier dann doch nicht richtig bin.

Gerne, weiss aber nicht wohin

[connormcl]

Nun habe ich den Hänger wieder, auf einem gänzlich neu installierten System.

Es trat auf, nachdem ich ein IODEV Attribut geändert hatte.
Im Log ist nichts zu sehen; hatte auch verbose noch nicht umgestellt.

Der perl Prozess läuft noch:

Code Auswählen Erweitern

6086 root     52832 S    {fhem.pl} /usr/bin/perl /usr/bin/fhem.pl /etc/config
6101 root     51408 S    {fhem.pl} /usr/bin/perl /usr/bin/fhem.pl /etc/config


Per telnet komme ich aber nicht auf die FHEMWEB-Schnittstelle:

Code Auswählen Erweitern

> telnet 192.168.2.23 8083
Trying 192.168.2.23...
Connected to 192.168.2.23.
Escape character is '^]'.


Danach geht es nicht weiter.

Dann alle fhem.pl beendet und fhem ohne Änderung oder Systemreboot neu gestartet und alles läuft wieder als ob nichts gewesen wäre.

[rudolfkoenig]

Danach geht es nicht weiter.

Was auch immer das genau bedeutet. Hast du eine gueltige HTTP Abfrage abgesetzt?

[connormcl]

Was auch immer das genau bedeutet. Hast du eine gueltige HTTP Abfrage abgesetzt?

Eingaben waren im Telnet-Dialog nicht möglich...es kam kein Echo...

Nach FHEM-Restart funktioniert die Telnet-Session und ich kann "GET /fhem" ausführen. Beim hängenden System war dies nicht möglich. System lief wieder ca. 1-2 Wochen. Dateisysteme sind nicht vollgelaufen.

[rudolfkoenig]

Eingaben waren im Telnet-Dialog nicht möglich...es kam kein Echo...

Also erstens ist eine Eingabe ohne echo auch moeglich, zweitens wird echo nicht von FHEMWEB sondern vom telnet Programm realisiert, FHEMWEB selbst macht in keinem Fall ein echo. Aber wenn du sicher warst, dass FHEMWEB sich verklemmt hat, dann haettest Du laut meinem Vorschlag als naechstes ueber dem FHEM-Telnet-Port  "attr TYPE=FHEMWEB verbose 5" setzen koennen.

[connormcl]

Ich kann die Hänger mittlerweile auf einen JeeLink v1 mit EC3000 Sketch zurückführen.
Dieser hängt sich in Zeiträumen von 1-6 Wochen auf.

Danach hängt FHEM teilweise; von aussen kann ich nur noch ins Logfile sehen und dort schreibt weiterhin HMCCU Statusmeldungen.
FHEMWEB und AT-Befehle reagieren aber nicht mehr bzw. werden nicht mehr ausgeführt.

Es hilft bisher nur stromlos machen des Gesamtsystems; Neustart FHEM oder Reboot reichen nicht aus. Auch der JeeLink muss einmal powercyclen.

Der eigentliche Fehler liegt wohl im JeeLink Sketch oder der JeeLink Hardware vergraben (Störeinstrahlung/Spannung u.ä.)
Es gab auch Patches um das JeeLink Modul robuster und JeeLink-Resettend zu gestalten.

Vgl. diesen Thread hier:
https://forum.fhem.de/index.php/topic,23099.msg796132.html#msg796132

Müsste FHEM den Ausfall des JeeLinks nicht ignorieren können und das funktionierende Restsystem sollte weiterhin laufen?

Log-Ausgabe mit teilabgestürztem bzw. nichtreagierendem FHEM und noch weiterlaufenden HMCCU Meldungen:

2018.04.21 02:59:26 0: JeeLink1: RFM12 hang detected
2018.04.21 02:59:26 3: Opening JeeLink1 device 127.0.0.1:10003
2018.04.21 02:59:26 1: 127.0.0.1:10003 disconnected, waiting to reappear (JeeLink1)
2018.04.21 03:19:55 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 03:57:46 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 04:40:20 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 05:18:22 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 05:56:51 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 06:36:52 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 07:15:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 07:55:04 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 08:33:29 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 09:13:18 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 09:54:30 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 10:31:59 3: CCURPC: CB2001 Received 500 events from CCU since last check
2018.04.21 11:09:46 3: CCURPC: CB2001 Received 500 events from CCU since last check

[rudolfkoenig]

Müsste FHEM den Ausfall des JeeLinks nicht ignorieren können und das funktionierende Restsystem sollte weiterhin laufen?

Das haengt davon ab, wie JeeLink abstuerzt.

[connormcl]

Der letzte JeeLink Sketch stammt vom 03.04.2015. Werde jetzt nochmal den JeeLink austauschen, aber da es schon damals Workaround-Versuche gab, um den aufgehangenen Funk-Chip von Zeit zu Zeit zu resetten, gehe ich von "normalem" Verhalten mit dem Sketch aus.

Somit muss ich eine Lösung finden, dass sich FHEM nicht aufhängt bzw. starten lässt, wenn der JeeLink in dem Zustand ist.

Der JeeLink ist bei mir per ser2net angebunden und wird garnicht direkt angesprochen. Dass FHEM sich aufhängt, liegt somit am JeeLink-Modul in FHEM selbst?

Könnte ich das Problem umgehen, indem ich den JeeLink weiter kapsele, d.h. ihn in einer eigenen FHEM-Instanz betreibe (auf der gleichen Maschine) und die Messwerte des JeeLink dann per FHEM2FHEM anbinde? Dann sollte im Fehlerfall nur der JeeLink-FHEM neu starten, aber der Haupt-FHEM würde unbeeindruckt laufen können?

Oder gibt es in einer solchen Situation andere Empfehlungen? (Ich konnte bisher keine andere Hardware finden, die EC3000 Messadapter an FHEM anbindet)

[rudolfkoenig]

Könnte ich das Problem umgehen, indem ich den JeeLink weiter kapsele, d.h. ihn in einer eigenen FHEM-Instanz betreibe (auf der gleichen Maschine) und die Messwerte des JeeLink dann per FHEM2FHEM anbinde?

Ja. Oder man bindet ihn via ser2net (oder socat/etc, siehe wiki) ein.

[connormcl]

Er ist ja derzeit über ser2net an FHEM angehängt. Trotzdem hängt sich FHEM auf und fährt danach nicht hoch, wenn der JeeLink ausgestiegen ist...

[rudolfkoenig]

FHEM2FHEM arbeitet anders, ich gehe davon aus, dass damit keine Verklemmer im Haupt-FHEM gibt.