Guten Abend die Runde,
nachdem ich die Sysmon Erweiterung erfolgreich auf meiner Test VM testen konnte wollte ich es heute auf meinem Livesystem versuchen, jedoch wird mein Log mit folgenden Warnungen/Fehlermeldungen gefüllt:
2015.08.29 13:13:35 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem//FHEM/Blocking.pm line 107.
2015.08.29 13:13:35 1: CallBlockingFn: Can't connect to localhost:: IO::Socket::INET: Bad hostname 'localhost:'
Can't use an undefined value as a symbol reference at /opt/fhem//FHEM/Blocking.pm line 125.
Und davor kommt keine Meldung, z.B. diese:
ZitatCallBlockingFn: No telnet port found and cannot create one.
?
Nein, erhalte keinerlei Fehlermeldungen in dieser Art.
Interessant finde ich jedoch den Doppelpunkt hinter dem Hostname
Bad hostname 'localhost:'
Da fehlt der Port, der steht normalerweise hinter dem :
Hast du ein telnet device in fhem definiert? wenn nicht mach mal das als erstes => http://fhem.de/commandref.html#telnet
Die Ursache des Problems (WARNING und localhost:) ist das schiefgelaufene BlockingCall (No telnet ...), was vmtl. vom Aufrufer von BlockingCall ignoriert wurde. Vor "Not telnet" sollte im Log die Ursache auf loglevel 1 protokolliert worden sein, diese Ursache muss behoben werden.
Ich habe Blocking.pm angepasst, dass die "No telnet" Meldung auch die Fehlermeldung von define telnet enthaelt, das ist aber nur kosmetisch, bzw. hilft nur dann, falls der BlockingCall Aufrufer loglevel auf 0 setzt.
Zitat von: rapster am 29 August 2015, 20:33:06Hast du ein telnet device in fhem definiert? wenn nicht mach mal das als erstes => http://fhem.de/commandref.html#telnet
Sysmon erhält nachdem ich den Telnet eingerichtet habe zumindest schon mal Daten. Und nach einigen Neustarts auch keine neuen Fehlermeldungen mehr im Log. Danke!
Zitat von: rudolfkoenig am 30 August 2015, 10:02:27
Die Ursache des Problems (WARNING und localhost:) ist das schiefgelaufene BlockingCall (No telnet ...), was vmtl. vom Aufrufer von BlockingCall ignoriert wurde. Vor "Not telnet" sollte im Log die Ursache auf loglevel 1 protokolliert worden sein, diese Ursache muss behoben werden.
Ich habe Blocking.pm angepasst, dass die "No telnet" Meldung auch die Fehlermeldung von define telnet enthaelt, das ist aber nur kosmetisch, bzw. hilft nur dann, falls der BlockingCall Aufrufer loglevel auf 0 setzt.
Sollte ich den verantwortlichen Maintainer hexenmeister verständigen, da dieser laut MAINTAINER.txt im Bereich "Unterstuetzende Dienste" aktiv ist?
Soweit ich sehe, verstellt SYSMON verbose nicht, insofern duerfte der Maintainer unschuldig, und die Fehlermeldung fuer die schiefgelaufene Telnet-Definition im Log zu finden sein.
Ich habe auch das Problem und bekomm es einfach nicht hin... bei mir funktioniert wegen dieses Fehlers das "checkConfig" für das hm device nicht direkt im device (witzigerweise aber, wenn ich es aus den web-cmds aufrufe).
Meine Fehlermeldung:
2015.12.12 20:38:01 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at FHEM/Blocking.pm line 105.
2015.12.12 20:38:01 1: CallBlockingFn: Can't connect to localhost:: IO::Socket::INET: Bad hostname 'localhost:'
Die Einträge in fhem.cfg sind:
define tPort telnet 7072 global
attr tPort SSL 1
attr tPort globalpassword xxxxx
Das telnet device habe ich lt. der FHEM reference neu aufgesetzt und in der fhem.cfg wieder an die alte Stelle oben im Kopf gesetzt.
Was kann ich jetzt noch machen? Irgendwas hat es mit "telnetForBlockingFn" zu tun...
Zitat von: AndyMu am 12 Dezember 2015, 20:41:42
Was kann ich jetzt noch machen?
Einen Eintrag in /etc/hosts für localhost, der die Adresse nach 127.0.0.1 auflöst.
Zitat von: betateilchen am 12 Dezember 2015, 20:45:34
Einen Eintrag in /etc/hosts für localhost, der die Adresse nach 127.0.0.1 auflöst.
Das wäre zu einfach... nein, ein "ping localhost" wird auch sauber aufgelöst.
Meine /etc/hosts sieht so aus:
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.1.1 raspberrypi
SSL Zertifikate hast Du erstellt? Wenn nicht, dann das SSL weglassen.
SSL habe ich jetzt mal rausgenommen und nen shutdown restart durchgeführt... funktioniert!
Besten Dank!
Irgendwie war ich der Meinung, dass das mit SSL funktioniert, nachdem meine GUIs mit https laufen.
Sind aber wohl doch zwei unterschiedliche Themen.
Blocking.pm setzt eine Telnet-Instanz ohne SSL voraus.
Zitat von: AndyMu am 13 Dezember 2015, 08:49:30
SSL habe ich jetzt mal testweise rausgenommen, leider auch nichts gebracht.
Und es wäre nett gewesen, wenn Du den Betrag nicht still und leise komplett geändert hättest, dann hätte ich weniger Zeit verschwendet.
Zitat von: dev0 am 13 Dezember 2015, 09:08:09
Und es wäre nett gewesen, wenn Du den Betrag nicht still und leise komplett geändert hättest, dann hätte ich weniger Zeit verschwendet.
Nachdem ich das so zeitnah festgestellt hatte, dachte ich mir es ist einfacher ich korrigiere das...
Sorry, dass sich das überschnitten hatte.