Hallo,
mein Systemaufbau: siehe Signatur.
Ich hatte vor einiger Zeit mal das Problem, dass plötzlich sackweise Fehlermeldungen im Log auf dem Cubietruck auftauchten (s.u.) und die HMLAN Adapter auf Disconnect gehen. Auf Verdacht habe ich meine FHEM2FHEM Definition zur Fritzbox rausgenommen. Danach war das Problem weg. Da ich FHEM2FHEM nicht mehr gebraucht habe, ist es draussen geblieben.
Heute tauchte das Problem wieder auf: Fehlermeldung und Disconnect bei den HMLAN. Da ich gar nicht FHEM sondern die Fritzbox im Verdacht habe, ist nun auch die FBAHA Definiton rausgeflogen. Und wieder war Ruhe.
1. Hat das schon mal jemand gehabt? Ich brauche ein stabiles FHEM und daher verwende ich nur was unbedingt notwendig ist.
2. Wenn ich weder FHEM2FHEM noch FBAHA verwende, benötige ich dann überhaupt die telnet Definition?
Grüße
Deudi
2014.09.17 07:08:56 1: Accept failed (telnetPort: Resource temporarily unavailable)
2014.09.17 07:08:58 1: Accept failed (telnetPort: Resource temporarily unavailable)
2014.09.17 07:08:59 1: Accept failed (telnetPort: Resource temporarily unavailable)
2014.09.17 07:08:59 1: Accept failed (telnetPort: Resource temporarily unavailable)
2014.09.17 07:08:59 1: Accept failed (telnetPort: Resource temporarily unavailable)
2014.09.17 07:08:59 1: Accept failed (telnetPort: Resource temporarily unavailable)
2014.09.17 07:09:00 1: Accept failed (telnetPort: Resource temporarily unavailable)
Verwendest du SSL?
FBAHA benoetigt kein telnetPort.
Zitat von: rudolfkoenig am 18 September 2014, 07:52:58
Verwendest du SSL?
Nein
ZitatFBAHA benoetigt kein telnetPort.
Für was brauche ich den telnetPort überhaupt?
Um via telnet sich mit FHEM zu verbinden ?!
Kommandozeile und so'n Zeugs fuer Nerds. FHEM ist eigentlich fuer Nerds gebaut. Deswegen halt.
Zitat von: rudolfkoenig am 18 September 2014, 15:16:30
Um via telnet sich mit FHEM zu verbinden ?!
Das ist mir schon klar. Ok, die Frage war von mir vielleicht falsch gestellt.
Diese Möglichkeit habe ich bisher nicht genutzt. Bin nämlich weder Nerd noch Geek. Daher halt.
Die Frage war dahingehend gemeint, ob ein Modul den telnetPort (mit-)benutzt. Ich frage mich ja was obige Fehlermeldung verursacht, wenn ich telnet nicht wissentlich verwende.
telnetPort kannst du entfernen. FHEM2FHEM legt eins an, wenn es keinen passenden findet.
Hallo,
ich habe die telnet Definition gelöscht. Danach hat fhem oder ein Modul selbst einen "telnetForBlockingFn" angelegt. Ist dann 11 Tage gut gegangen. Heute Morgen war das Problem wieder da:
2014.09.28 08:00:02 3: CUL_HM set Rollladen_Kueche pct 60
2014.09.28 08:00:06 3: CUL_HM set Rollladen_Flur_OG pct 55
2014.09.28 08:00:10 3: CUL_HM set Rollladen_Wohnzimmer_L pct 21
2014.09.28 08:00:14 3: CUL_HM set Rollladen_Wohnzimmer_R pct 20
2014.09.28 08:06:39 1: Accept failed (telnetForBlockingFn: Resource temporarily unavailable)
2014.09.28 08:07:02 1: Accept failed (telnetForBlockingFn: Resource temporarily unavailable)
2014.09.28 08:07:05 1: Accept failed (telnetForBlockingFn: Resource temporarily unavailable)
2014.09.28 08:07:20 1: Accept failed (telnetForBlockingFn: Resource temporarily unavailable)
2014.09.28 08:07:26 1: Accept failed (telnetForBlockingFn: Resource temporarily unavailable)
2014.09.28 08:08:06 1: Accept failed (telnetForBlockingFn: Resource temporarily unavailable)
2014.09.28 08:08:09 1: Accept failed (telnetForBlockingFn: Resource temporarily unavailable)
2014.09.28 08:08:13 1: Accept failed (telnetForBlockingFn: Resource temporarily unavailable)
2014.09.28 08:08:14 1: HMLAN_Parse: HMLAN3 new condition timeout
2014.09.28 08:08:14 1: 192.168.211.73:1000 disconnected, waiting to reappear (HMLAN3)
2014.09.28 08:08:14 1: HMLAN_Parse: HMLAN3 new condition disconnected
2014.09.28 08:08:38 1: 192.168.211.73:1000 disconnected, waiting to reappear (HMLAN3)
2014.09.28 08:08:38 1: HMLAN_Parse: HMLAN3 new condition disconnected
2014.09.28 08:09:14 1: 192.168.211.73:1000 reappeared (HMLAN3)
2014.09.28 08:09:14 1: HMLAN_Parse: HMLAN3 new condition init
2014.09.28 08:09:14 1: HMLAN_Parse: HMLAN3 new condition ok
2014.09.28 08:09:21 1: Accept failed (telnetForBlockingFn: Resource temporarily unavailable)
2014.09.28 08:09:55 1: Accept failed (telnetForBlockingFn: Resource temporarily unavailable)
2014.09.28 08:10:39 1: Accept failed (telnetForBlockingFn: Resource temporarily unavailable)
Das geht dann immer so weiter und in der Folge geht nicht mehr viel.
Was kann ich tun, um heraus zu finden was das Problem auslöst?
Grüße Deudi
In manchen Faellen, die ich noch nicht ganz erklaeren kann, kann diese Fehlermeldung auftreten, allerdings sollte es keine weiteren Folgen haben.
Ich habe die Fehlermeldung in diesen Faellen unterdrueckt, die Aenderung steht ab morgen zur Verfuegung.
Zitat von: rudolfkoenig am 29 September 2014, 09:55:54
... sollte es keine weiteren Folgen haben.
Tatsächlich startet mit der ersten Meldung dieser Art eine Abfolge von Disconnects aller drei HMLAN mit dadurch bedingten Missing-Ack, nicht ausgeführten Befehlen, fehlenden Messwerten im Plot etc. Das wird dann auch über Stunden nicht besser und ist erst nach einem Neustart wieder ok.
Ich hatte mir die Codestelle gestern auch mal angeschaut und überlegt, wie ich das Logging noch erweitern kann, um den Schuldigen zu finden. Hast du einen Vorschlag?
Da das System bei mir dann nicht mehr zu gebrauchen ist, überlege ich mir da ein "die" einzubauen, damit der Watchdog neu bootet.
Der Server-Fd der Telnet-Instanz ist (wie alle anderen) in nonblocking Mode. Wenn das Server-Socket-Accept mit EAGAIN (Resource temporarily unavailable) zurueckkommt, dann heisst das, dass es vorher aus dem select sinnloserweise aufgeweckt wurde, weil doch nichts zu tun ist. Warum das passiert, verstehe ich nicht, ich sehe es aber ein, dass es kein Fehler ist, und man soll einfach warten, bis select wieder sich ruehrt. Aus diesem Grund wird beim EGAIN beim Accept keine Fehlermeldung ausgegeben.
Warum nachfolgend zu HMLAN disconnects kommt, ist mir auch schleierhaft, da diese mit dem vorherigen Accept-Versuch nichts zu tun haben, dein HMLAN ist doch ueber eine ganz andere, bereits hergestellte TCP Verbindung mit FHEM verbunden.
Kannst Du versuchen in TcpServerUtils.pm, die Zeile
Blocking => ($^O =~ /Win/ ? 1 : 0), # Needed for .WRITEBUFFER@darwin
entfernen, und schauen, ob es hilft? EAGAIN Faelle sollten dadurch jedenfalls verschwinden.
Danke dir für die Erklärung. Ich ändere das mal und warte was passiert. Zu gegebener Zeit melde ich mich dann wieder und werde berichten.