8083/fhem nicht mehr erreichbar

mfeske · 17 März 2022, 22:18:44

Hallo zusammen,
von einem Moment auf den anderen war fhem per web nicht mehr erreichbar. Es gab am raspi kein update und auch keins für fhem.
Neustart vom raspi hilft auch nicht.
fhem arbeitet aber, rolladen fahren hoch und runter etc.
wenn ich fhem anhalte und neustarte
sudo service fhem stop
Stopping fhem...
pi@raspyfhem ~ $ sudo service fhem start
Starting fhem...
Daemon with PID 8287 started!

erhalte ich eine Meldung
Can't bind socket: Address already in use

Kann es sein das ein anderer Dienst sich an den Ports bedient ?
Wie kann das passieren ?
Gruß
Micha

Logs habe ich auch befragt:

Code Auswählen

2022.03.17 22:23:31 1: reload: Error:Modul 01_FHEMWEB deactivated:
 Attempt to reload TcpServerUtils.pm aborted.
Compilation failed in require at ./FHEM/01_FHEMWEB.pm line 7, <$fh> line 51.
BEGIN failed--compilation aborted at ./FHEM/01_FHEMWEB.pm line 7, <$fh> line 51.

und

Code Auswählen

2022.03.17 22:22:02 3: hmusb: Unknown code A0F6C861062E9DE0000000A90C30B0000::-101:hmusb, help me!

SirMarco · 17 März 2022, 22:54:55

Schau mal hier:
https://forum.fhem.de/index.php?topic=65770.0

Hoffentlich hilft dir das

Grüsse

postman · 18 März 2022, 11:25:58

Hallo zusammen,
nach einem update von FHEM ist die Webseite nicht mehr erreichbar.
Ale Fehlermelung im log steht:

Code Auswählen

2022.03.18 11:13:29 1: reload: Error:Modul 98_telnet deactivated:
 Attempt to reload TcpServerUtils.pm aborted.
Compilation failed in require at ./FHEM/98_telnet.pm line 10.
BEGIN failed--compilation aborted at ./FHEM/98_telnet.pm line 10.

2022.03.18 11:13:29 0: Attempt to reload TcpServerUtils.pm aborted.
Compilation failed in require at ./FHEM/98_telnet.pm line 10.
BEGIN failed--compilation aborted at ./FHEM/98_telnet.pm line 10.

2022.03.18 11:13:29 1: BlockingCall (BlockingStart): No telnet port found and cannot create one: Cannot load module telnet

Ich habe mal das TCPServerutil.pm alt und neu verglichen. Dabei stellte ich fest, dass anscheinend diverse Subroutinen das Problem verursachen. Versuchsweise habe ich diese mal gelöscht und festgestellt, dass wenn ich die folgenden Routinen lösche, alles wieder funktioniert:
1. TcpServer_MCastAdd...
2. TcpServer_SetLoopbackMode...
3.. TcpServer_MCastRecv...
4. TcpServer_MCastSend...
5. TcpServer_MCastRemove...
Da scheint irgendwo das Problem zu liegen.
Verwenden tue ich übrigens als BS das Wheezy.
Das möchte ich derzeit aber nicht updaten, da meine Installation mittlerweile so umfaangreich ist, dass ich den derzeiteigen Stand wohl nicht mehr zusammenbringe.

Gruß
Uwe

CoolTux · 18 März 2022, 11:35:01

https://forum.fhem.de/index.php/topic,126290.0.html

Ich habe Andre und Rudi einmal gebeten sich Deinen Beitag an zu schauen. Besser wäre allerdings einen eigenen Thread zu eröffnen das dieder hier augenscheinlich mit Deinem Problem nichts zu tun hat.

rudolfkoenig · 18 März 2022, 12:04:31

Da ich kein wheezy zur Verfuegung habe: kannst du bitte das komplette Log zeigen?

Wenn ich meine Version von TcpServerUtils mit Absicht verunstalte, dann sind die letzten Zeilen des Logs so wie in deinem Beispiel, aber davor kann man die eigentlichen Probleme sehen.

frank · 18 März 2022, 13:09:02

vor 3 tagen gab es ebenfalls das problem in verbindung mit wheezy.
dort gibt es etwas mehr log:
https://forum.fhem.de/index.php/topic,126789.msg1213586.html#msg1213586

mfeske · 18 März 2022, 19:53:58

also ich erreiche die Instanz auf keinem der Ports

Code Auswählen

netstat -na |grep LISTEN|grep
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:1234            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN

auch nach einem kill -all besteht das Problem weiterhin

Code Auswählen


sudo killall -9 perl
pi@raspyfhem ~ $ sudo service fhem status
fhem is not running
pi@raspyfhem ~ $ sudo service fhem start
Starting fhem...
Daemon with PID 7811 started!
Can't bind socket: Address already in use

Gruß
Micha

frank · 18 März 2022, 20:07:24

versuche es mit der alten TcpServerUtils.pm

mfeske · 18 März 2022, 20:25:56

Hallo Frank,
aus dem git repo laden vorher fhem stoppen und dann reinkopieren und neu starten ?
Gruß
Micha

Code Auswählen

-rw-r--r-- 1 fhem dialout 17506 Mär 16 22:13 TcpServerUtils.pm

die wurde wohl vor kurzem geändert

Das hat wohl leider nicht geklappt:

Code Auswählen



pi@raspyfhem ~ $ sudo mv /opt/fhem/FHEM/TcpServerUtils.pm /opt/fhem/FHEM/TcpServerUtils_off.pm
pi@raspyfhem ~ $ sudo cp /opt/fhem/restoreDir/update/2022-03-16/FHEM/TcpServerUtils.pm /opt/fhem/FHEM/
pi@raspyfhem ~ $ sudo service fhem start
Starting fhem...
Daemon with PID 8098 started!
Can't bind socket: Address already in use

Nach raspi Neustart sieht es etwas besser aus

Beim nächsten Update fliegt mir dann wieder alles um die Ohren ?

Code Auswählen


 netstat -na |grep LISTEN
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:1234            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8083            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8084            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8085            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8086            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:7072            0.0.0.0:*               LISTEN

rudolfkoenig · 18 März 2022, 21:24:16

ZitatBeim nächsten Update fliegt mir dann wieder alles um die Ohren ?

Yepp, es sei denn Du traegst TcpServerUtils in "attr global exclude_from_update" ein.
Ich versuche noch eine Loesung fuer olle Systeme zu finden, bin gespannt, ob ich damit durchkomme, fuer Entwickler sind alte Systeme laestig.

Was mir nicht klar ist: wieso bestehst Du auf ein FHEM update aber nicht auf ein OS update?

frank · 18 März 2022, 23:05:09

ZitatNach raspi Neustart sieht es etwas besser aus

passen rechte/owner/gruppe nach dem tausch noch?

CoolTux · 19 März 2022, 06:12:47

Zitat von: rudolfkoenig am 18 März 2022, 21:24:16
Was mir nicht klar ist: wieso bestehst Du auf ein FHEM update aber nicht auf ein OS update?

Das würde mich auch Interessieren. Ich bin im übrigen so ein Entwickler

Ich würde ja alle User zwingen wenigstens auf Jessie zu gehen.

Beta-User · 19 März 2022, 07:31:36

Zitat von: rudolfkoenig am 18 März 2022, 21:24:16
bin gespannt, ob ich damit durchkomme, fuer Entwickler sind alte Systeme laestig.

M.E. geht es gar nicht sooo sehr um "lästig", sondern v.a. darum, dass veraltete Betriebssysteme halt schlicht und ergreifend nicht mehr einen hinreichenden Sicherheitslevel gewährleisten können. Wenn wir User dazu "ermuntern", das so beizubehalten, ist das m.E. einfach der falsche Weg...

Von daher kann ich auch nicht so ganz nachvollziehen, wenn jemand hier nicht klar sagt, dass jemand, der jetzt updated, doch bitte die aktuellste "stable" nehmen sollte, also aktuell "bullseye". Nach meiner möglicherweise lückenhaften Kenntnis ist mehr oder weniger die einzige wirklich kritische Baustelle das "unescaped left brace"-Thema, und das sollte sich in 97,8% der Fälle in 20 Minuten lösen lassen (vorausgesetzt, man kennt die Lösung, die ja einfach zu finden ist).
Wer so eine "Uralt-Murmel" sein Eigen nennt, muss halt (eigentlich: sowieso) in einen neuen Datenträger investieren und mal eine "Software-Inventur" machen, that's all... Aber dann bitte weitermachen mit dem aktuellsten Stand! Nicht "Minimalinvasiv". Der Aufwand ist doch mehr oder weniger gleich...

frank · 19 März 2022, 10:13:10

grundsätzlich ist wheezy wirklich schon sehr alt und ein upgrade auf dem pi funktioniert ja auch ohne probleme.
allerdings hat dieses problem eigentlich nichts mit einem veralteten os zu tun, finde ich. es hätte ja auch schon damals beim wechsel auf jessie passieren können.

"komfortabler" wäre es, wenn fhem vor einem update die perl version des os checken würde und ggf ein komplettes update verhindert oder nur bestimmte module vom update ausschliesst.
ein entsprechendes popup im webif wird sicherlich viele user zum os-update animieren.
theoretisch müsste das doch mit einem zusätzlichen versions parameter in der "$Id:...." zeile machbar sein.

fhem.pl legt die ältest mögliche version fest und in den modulen kann zusätzlich eine neuere version vorausgesetzt werden.
module ohne versionsangabe übernehmen die mindestversion von fhem.pl.
core module wie TcpServerUtils.pm sollten dann möglichst auch mit der mindestversion funktionieren.

rudolfkoenig · 19 März 2022, 10:36:20

Zitat"komfortabler" wäre es, wenn fhem vor einem update die perl version des os checken würde und ggf ein komplettes update verhindert oder nur bestimmte module vom update ausschliesst.

Das ist ohne Zweifel wahr fuer den Benutzer, bedeutet aber, dass der Entwickler alle denkbaren Features mit allen Perl-Versionen testen muss.

Strenggenommen muesste jedes Modul die kleinste und groesste gepruefte Version fuer perl und alle verwendeten Module (rekursiv?) angeben. Fuehrt dazu, dass der Gelegenheits-Modulentwickler die gerade verwendeten Versionen angibt, und das Modul schnell unbrauchbar wird. Auch fuer mich ist das keine Option: statt 15 Minuten fuer ein Fetaure muesste ich Stunden mit Testen verbringen.

Man kann auch eine weniger perfekte Variante einfuehren, fraglich ist, ob das unter dem Strich besser ist, als die aktuelle Variante, wo der Benutzer nach dem schiefgelaufenen update restore durchfuehren kann.