Hallo Markus,
seit ich das PRESENCE-Modul einsetze, werde ich leider mit einem sporadisch auftauchenden Fehler in dem Modul Blocking.pm konfrontiert. (Ich dachte ja, ein FHEM-Update hätte das schon behoben, aber leider kommt das Problem immer wieder ...)
Ab und an funktionieren bei mir der lan-ping-Modus und der shellscript-Modus von PRESENCE nicht mehr (pings werden nicht als erfolgreich erkannt). Immer, wenn das der Fall ist, finde ich im fhem-nnnn-nn.log ein oder mehrere Einträge der folgenden Art:
Use of uninitialized value in concatenation (.) or string at /usr/share/fhem/FHEM/Blocking.pm line 105.
2013.04.18 01:43:17 1: CallBlockingFn: Can't connect to localhost:
Can't use an undefined value as a symbol reference at /usr/share/fhem/FHEM/Blocking.pm line 116.
Use of uninitialized value in concatenation (.) or string at /usr/share/fhem/FHEM/Blocking.pm line 105.
Ein Restart von FHEM behebt das Problem, aber nach einiger Zeit (in aller Regel jedenfalls weniger als ein Tag) taucht es wieder auf.
Von außen kann ich leider nicht einmal beurteilen, ob das nun ein Fehler in Blocking.pm oder PRESENCE ist; auf jeden Fall ist es problematisch, da ich mich auf den PRESENCE-Status so nicht verlassen kann.
Uli
Kannst du mal ein Log mit verbose 5 anhängen, damit man genaueres erkennen kann?
Vielen Dank
Gruß
Markus
Ich hab' Log 5 aktiviert, jetzt muss nur noch das Problem auftreten ...
Wie schon mehrmals beschrieben tritt dieses Problem nach "rereadcfg" auf.
Hier ein Log mit Verbose 5:
2013.05.18 02:44:42 5: PRESENCE_DoLocalPingScan: Rudi|192.168.125.2|0
2013.05.18 02:44:45 5: PRESENCE (Rudi) - ping command returned with output:
PING 192.168.125.2 (192.168.125.2): 56 data bytes
64 bytes from 192.168.125.2: seq=0 ttl=64 time=1.564 ms
64 bytes from 192.168.125.2: seq=1 ttl=64 time=1.251 ms
64 bytes from 192.168.125.2: seq=2 ttl=64 time=1.489 ms
64 bytes from 192.168.125.2: seq=3 ttl=64 time=1.513 ms
--- 192.168.125.2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1.251/1.454/1.564 ms
Use of uninitialized value in concatenation (.) or string at FHEM/Blocking.pm line 105.
2013.05.18 02:44:45 1: CallBlockingFn: Can't connect to localhost:
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 116.
Und dieser Log, nach einem Restart:
2013.05.18 02:57:24 5: PRESENCE_DoLocalPingScan: Rudi|192.168.125.2|0
2013.05.18 02:57:27 5: PRESENCE (Rudi) - ping command returned with output:
PING 192.168.125.2 (192.168.125.2): 56 data bytes
64 bytes from 192.168.125.2: seq=0 ttl=64 time=1.741 ms
64 bytes from 192.168.125.2: seq=1 ttl=64 time=1.170 ms
64 bytes from 192.168.125.2: seq=2 ttl=64 time=1.181 ms
64 bytes from 192.168.125.2: seq=3 ttl=64 time=1.169 ms
--- 192.168.125.2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 1.169/1.315/1.741 ms
2013.05.18 02:57:27 4: Connection accepted from telnet:127.0.0.1:55276
2013.05.18 02:57:27 5: Cmd: >{PRESENCE_ProcessLocalScan('Rudi|0|present')}<
2013.05.18 02:57:27 5: PRESENCE_ProcessLocalScan: Rudi|0|present
Zitat von: Uli Zappe schrieb am So, 21 April 2013 23:29Ich hab' Log 5 aktiviert, jetzt muss nur noch das Problem auftreten ...
Und, wie es immer so ist, seit genau dieser Zeit trat es nie mehr auf ... Deswegen (und weil viel anderes los war) habe ich mich so lange nicht gemeldet, sorry. Ich lasse bis auf weiteres aber Loglevel 5 bestehen, so dass ich sofort Genaueres beichten kann, falls nochmal ein Problem auftritt. Aber wie gesagt, im Moment sieht es nicht so aus.
Zitat von: Dragonfly schrieb am Sa, 18 Mai 2013 02:50Wie schon mehrmals beschrieben tritt dieses Problem nach "rereadcfg" auf.
Oh, danke für die Info! Das hatte ich nicht gefunden/übersehen. Das macht es ja noch wahrscheinlicher, dass, selbst wenn da noch ein Problem mit
PRESENCE wäre, es jedenfalls nicht mit dieser Meldung zusammenhinge.
Uli
> Use of uninitialized value in concatenation (.) or string at FHEM/Blocking.pm line 105.
Das Problem tritt auf, wenn man keine passwortlose telnet Instanz definiert hat, und man waehrend BlockingFn laeuft, ein rereadcfg durchfuehrt. rereadcfg loescht alle in-memory-strukturen, und legt alles an was im fhem.cfg ist. Da BlockingFn eine temporaere telnetverbindung oeffnet, falls sie keine passwortlose alternative findet, geht dieser beim rereadcfg verloren.
Loesung
- kein rereadcfg durchfuehren (dies ist ein weiteres Argument, um rereadcfg abzuschaffen :)
- BlockingFn sollte Telnet mit Passwort unterstuetzen (mittelfristig), und keine temporaere Ports anlegen.
Workaround:
- eine auf localhost begrenzte passwortlose telnet Instanz anlegen.
Zitat von: rudolfkoenig schrieb am Sa, 18 Mai 2013 12:43Das Problem tritt auf, wenn [...]
Danke für die genaue Erklärung!
Uli
Zitat von: rudolfkoenig am 18 Mai 2013, 12:43:02
Workaround:
- eine auf localhost begrenzte passwortlose telnet Instanz anlegen.
Und wie macht man das?
Danke/Gruss
Stephan
Zitat von: Stephan am 20 Oktober 2013, 17:03:58
Und wie macht man das?
Danke/Gruss
Stephan
z. B:
define localTelnet telnet 7075
Ein Telnet Server der nur lokal lauscht (localhost only)
Der Parameter "global" dahinter macht den Server erst öffentlich zugänglich:
define localTelnet telnet 7075 global
Gruß
Markus
Man kann also zwei Instanzen definieren? Eine nur für localhost, eine global?
Gesendet von meinem Nexus 4 mit Tapatalk
du kannst beliebig viele instanzen definieren. sie müssen nur alle einen anderen port haben.
oder du kannst eine einzige instanz verwenden und das password nur für den remote zugriff setzen in dem du das attribut globalpassword statt password verwendest.
gruss
andre
Ah danke!
Gesendet von meinem Nexus 4 mit Tapatalk
Klappt auch! Super und danke!
Gesendet von meinem Nexus 4 mit Tapatalk