Hej FHEM-Gemeinde,
ich habe immer wieder das Problem bei meinen FHEM-Installationen, dass diese hängen bleiben.
Gefühlsmäßig passiert es immer, wenn während des Ladevorganges (Refresh alle 180 Sekunden, Longpoll ebenfalls aktiviert), zB ich den Laptop zuklappe, somit in Standby schicke und die laufende Übertragung dadurch abgebrochen wird.
Leider tritt es sehr unregelmäßig auf (meistens einmal alle paar Tage, aber gerade in den letzten 24 Stunden waren es 3x).
Im Logfile konnte ich bislang nur diese beiden Zeilen finden:
2014.01.20 09:41:54 1: FHEMWEB SSL/HTTPS error: Network is unreachable
2014.01.20 09:58:37 1: FHEMWEB SSL/HTTPS error: Interrupted system call
Ich muss aber gestehen, aufgrund der Seltenheit des Auftretens habe ich bislang noch nie lange genug das Loglevel auf 5 gesetzt gehabt, um möglicherweise mehr zu sehen, falls der Fehler wieder auftritt.
Kann es sein, dass wenn FHEM die angeforderten HTTPS-Daten nicht los wird, in einer Routine hängen bleibt und somit nicht mehr ansprechbar ist?
Instanz läuft zu dem Zeitpunkt immer noch und lässt sich mit einem normalen kill ${PROCESSID} beenden, was dann zu der zweiten Zeile aus meinem Logfile führt. Bei Versuch, eine Konsolenverbindung aufzumachen, ist der Socket zwar noch offen, aber bis zur Eingabe ( fhem> ) komm ich nicht. Sämtliche anderen Funktionen kann die Instanz auch nicht mehr verarbeiten.
Ich hab gestern Nacht noch versucht, den Fehler zu reproduzieren, was mir allerdings leider nicht gelungen ist. FHEM läuft jetzt wieder auf verbose 5 und ich hoffe, der Fehler tritt bald wieder auf, um mehr Daten liefern zu können. Es ist auf alle Fälle unabhängig davon, ob die Verbindung aus dem LAN stammt oder über das Internet kommt.
Vielleicht hat auch jetzt schon jemand eine Idee was ich probieren könnte bzw. hat selbst schon einmal diesen Fehler gehabt?
Vielen Dank im Voraus! :-)
Welche Version hast du, zu dem Thema gab es vor einigen Wochen einen fix
Vg
Jörg
Ahja... ich ahnte schon, dass ich etwas vergessen habe, wodurch eine Glaskugel notwendig wird.
Habe eigentlich beinahe immer die aktuelle Version am laufen (letztes Update wurde gestern Vormittag durchgeführt).
# $Id: fhem.pl 4663 2014-01-16 09:45:15Z rudolfkoenig $
# $Id: 01_FHEMWEB.pm 4648 2014-01-14 19:23:34Z rudolfkoenig $
Tritt das Problem auch ohne longpoll auf?
Hej,
Zitat von: rudolfkoenig am 20 Januar 2014, 10:56:47
Tritt das Problem auch ohne longpoll auf?
hab es jetzt einmal bei einer Instanz deaktiviert, bei der anderen drinnen gelassen und lasse den verbose hochgedreht.
Sobald ich neue Infos habe, melde ich mich wieder.
Thx a lot! :-)
So... Ich weiß nicht, ob das noch Nachwehen von vor dem Abschalten von longpoll sein könnten, aber habe vorhin gerade einen meiner Rechner aus dem Standby geholt und musste feststellen, dass ich die Seite nicht mehr laden konnte. Das Problem ist also erst beim Resume aus dem Standby aufgetreten. Kurzer Hand versucht, auf die Konsole zu verbinden und selbes Bild wie immer.
In dem Moment kommt FHEM offensichtlich auch nicht mehr dazu, etwas ins Log zu schreiben.
Erst bei kill gibt es wieder ein paar Zeilen. Diesmal ein paar mehr, da verbose 5 gesetzt, aber wohl kaum hilfreicher als beim letzten Mal:
2014.01.20 23:16:58 1: FHEMWEB SSL/HTTPS error: Interrupted system call
2014.01.20 23:16:58 5: Triggering global (1 changes)
2014.01.20 23:16:58 5: Notify loop for global SHUTDOWN
2014.01.20 23:16:58 0: Server shutdown
2014.01.20 23:16:58 4: CUL_send: myHMX0 0
@Rudi - meinst du, könnte das Verhalten noch damit zu tun haben, dass longpoll erst abgeschalten wurde, nachdem ich den Rechner in Standby geschickt habe? In dem Fall wäre es wohl eindeutig ein "Signal", das vom Client aus geht.
Das Aendern des longpoll Attributes wirkt erst nach dem naechsten Laden der Seite.
Der Fix, was herrmannj anspricht, packt alle Daten in einem Puffer, und sendet diese erst, wenn das Betriebsystem meint, es waere ohne verklemmen moeglich. Ich habe das auch geprueft, deswegen bin ich z.Zt. der Ansicht, dass longpoll nicht der Verursacher ist.
Auf welchem Hardware/OS laeuft FHEM?
Bist Du in der Lage "strace -p <fhem-pid>" zu verwenden?
Hej Rudi,
ganz richtig. Longpoll kann man als Verursacher ausschließen. Selbst nach einem Neustart von FHEM und neu laden der Seite im Browser, ist der Fehler heute morgen nach dem Einschalten des Rechners wieder aufgetreten.
Meine Instanzen laufen alle auf RPis mit Raspbian und aktuellstem Kernel (was git halt so her gibt).
Habe leider erst nach dem erneuten Auftreten deine Nachricht gelesen. Jetzt läuft alles wieder inkl. einem im screen laufenden strace, der alles brav in ein File schreibt.
So oft, wie das jetzt seit kurzem auftritt, sollte ich heute wohl noch Neuigkeiten haben. ;-)
So, hab den gewünschten strace-Output.
Hab es einmal auf die letzten 1000 Zeilen gekürzt, knapp über der Hälfte ist dann der Übeltäter daheim. Einfach nach "Terminated" greppen.
Bin schon gespannt, was du dazu sagst!
Vielen Dank! :-)
Hast mir etwas schwer gemacht, da strace ohne Zeitstempel lief.
Vor dem kill -TERM <FHEMPID> gab es eine ca 4-Minuten lange Pause. Ursache war eine Verbindungs-Anfrage von der IP-Adresse 213.143.122.35 auf einem FHEM-Port, welches weiss ich nicht, das steht am (abgeschnittenen) Anfang der strace Datei. FHEM faengt eine SSL-Verhandlung an, leider ohne Timeout, und die andere Seite sagt nix.
Evtl. hilft, wenn man in TcpServerUtils.pm unter die Zeile
SSL_cert_file => "$mp/certs/server-cert.pem",
folgendes einfuegt:
Timeout => 4,
Zitat von: rudolfkoenig am 21 Januar 2014, 21:22:44
Hast mir etwas schwer gemacht, da strace ohne Zeitstempel lief.
Hast natürlich recht, hätte ich auch darauf achten können. Hab ohne groß nachzudenken nur copy & paste gemacht.
Zitat von: rudolfkoenig am 21 Januar 2014, 21:22:44
Vor dem kill -TERM <FHEMPID> gab es eine ca 4-Minuten lange Pause. Ursache war eine Verbindungs-Anfrage von der IP-Adresse 213.143.122.35 auf einem FHEM-Port, welches weiss ich nicht, das steht am (abgeschnittenen) Anfang der strace Datei. FHEM faengt
eine SSL-Verhandlung an, leider ohne Timeout, und die andere Seite sagt nix.
Also doch zu gut gemeint mit dem Beschneiden des Files... aber die Pause passt. Entspricht der Zeit, vom Resume des Rechners bis zu dem Moment, bis ich FHEM dann neu gestartet hab.
Zitat von: rudolfkoenig am 21 Januar 2014, 21:22:44
Evtl. hilft, wenn man in TcpServerUtils.pm unter die Zeile
SSL_cert_file => "$mp/certs/server-cert.pem",
folgendes einfuegt:
Timeout => 4,
Hab das Timeout gestern noch eingebaut und seither den einen oder anderen Rechner schlafen gelegt und wieder aufgeweckt... Bislang keine Probleme mehr. :-)
Werde natürlich weiter testen, aber jetzt einmal die Frage: Welche Vor- bzw. Nachteile können sich durch das Timeout ergeben?
Und nochmals Danke für den Support! :-)
Habe das Timeout jetzt eingecheckt.
Was mir eher Sorge macht: wer verbindet sich mit FHEM auf dem SSL-Port, will aber keine Daten austauschen? Das kann ich mit einem zugeklappten Rechner nicht erklaeren.
Zitat von: rudolfkoenig am 23 Januar 2014, 06:59:47
Habe das Timeout jetzt eingecheckt.
Gerade gesehen, vielen Dank! :-)
Zitat von: rudolfkoenig am 23 Januar 2014, 06:59:47
Was mir eher Sorge macht: wer verbindet sich mit FHEM auf dem SSL-Port, will aber keine Daten austauschen? Das kann ich mit einem zugeklappten Rechner nicht erklaeren.
Der zugeklappte Rechner macht auch nichts. Es passiert offensichtlich (wenn es denn passiert) immer beim Resume aus dem Standby. Vielleicht kann der Browser da bereits die Kommunikation starten, aber der Rechner unterbricht nochmals kurz die Verbindung zum Netzwerk. Festgestellt hab ich dieses Verhalten sowohl bei meinem Laptop als auch bei meinem Desktop-PC. Aber wenn du möchtest, kann ich dem noch weiter nachgehen. :-)
Auch von mir mal wieder vielen Dank für die schnelle Lösung.
Ich setzte hier mehrere Raspberrys ein und auch bei mir ist das Problem aufgetreten. Nach dem Update war dann (fast, s.u.) alles wieder in Ordnung.
Wo es nicht funktioniert ist das Modul Sysstat mit der Option "SNMP". Wenn hier ein überwachter Raspberry, oder auch eine andere Maschine nicht erreicht erreichbar ist treten die gleichen Phänomene auf. Ob dies früher auch schon so war kann ich nicht sagen, mir ist vorgestern erstmalig ein Raspberry ausgefallen.
Nochmals vielen Dank und wenn meine Frage hier falsch angesiedelt ist bitte einfach ignorieren, ich mache dann bei Gelegenheit ein neues Thema hierzu auf.
VG Niko
Das Problem mit SYSSTAT bitte in dem richtigen Forums-Abschnitt mit passenden Betreff posten.
Hej Rudi,
wie es scheint, hab ich seit kurzem wieder die selben Probleme mit den Verbindungen. FHEM bleibt hängen.
Wenn ich meinen Updateverlauf so ansehe, könnte es womöglich mit den Änderungen vom 28.04.14 zu tun haben?
Wäre super, wenn du da einmal einen Blick darauf werfen könntest.
Thx a lot! :-)
Ich habe am 24.4 das im http://forum.fhem.de/index.php?topic=22568.new#new gemeldete Problem behoben.
Auch wenn das Deine Probleme eher noch weiter verringern sollte, kannst Du bitte testen, ob mit dem Version davor das Problem noch auftritt? Und in jedem Fall brauche ich mehr Details (strace/etc), da das Problem fuer mich erstmal nicht offensichtlich ist.