Nach Update OS: Can't connect to localhost:7072: IO::Socket::INET: connect: Verb

M_I_B · 11 Oktober 2016, 20:50:45

Hallo liebe Leute,

hatte heute Mittag etwa ein Update des Systems angestoßen. Heute Abend wundere ich mich, das wirklich nichts an Aufgaben ausgeführt wurde. ALso flux mal FHEM aufrufen... Nö... keine Verbindung zu FHEM möglich. Also habe ich mal in das LogFile geschaut:

Code Auswählen

Can't use an undefined value as a symbol reference at ./FHEM/93_RFHEM.pm line 81.
2016.10.11 20:36:36.793 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.793 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.798 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.813 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.843 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.853 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:37.825 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:39.749 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt

Das war's dann auch schon

Die üblichen Hinweise, das Telnet nicht installiert sei, sind natürlich dummfug; ist da und funktioniert.

Frage ist also, wo ich hier anfangen muss zu suchen? Irgendwas muss ja bei im heutigen Debian- Update drin gewesen sein, was Telnet vermeintlich Rechte entzogen hat. Nur mit den Rechten unter Debian bin ich ein absoluter DAU und habe wirklich keinen Schimmer, was ich wo wie überprüfen muss, um FHEM wieder ans Laufen zu bringen.

Wäre super, wenn mir da mal wer zeitnah auf die Sprünge helfen könnte.

rudolfkoenig · 11 Oktober 2016, 20:58:01

Das Problem hat mit telnet nichts zu tun.
Apropos telnet: funktioniert denn "telnet localhost 7072" vom FHEM-Server aus? Was heisst "FHEM aufrufen"?
Was steht am Anfang des logs? Ich meine sowas wie "2016.10.11 20:57:36 3: telnetPort: port 7072 opened"

M_I_B · 11 Oktober 2016, 21:48:53

... Telnet läuft auf dem Server. Ein Aufruf direkt auf dem Server generiert ...

Code Auswählen

Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

Mit "Aufrufen" meine ich den Aufruf der GUI von einem x-beliebigen System aus über Port 8083-5, wobei der hier allseits beliebte Feuervogel stumpf ...

Code Auswählen

Firefox kann keine Verbindung zu dem Server unter xeon1:8083 aufbauen.
...meldet.

Am Anfang sieht alles normal aus, also ...

Code Auswählen

2016.10.11 21:05:09.187 1: Including fhem.cfg
2016.10.11 21:05:11.028 3: telnetPort: port 7072 opened
2016.10.11 21:05:11.557 3: WEB: port 8083 opened
2016.10.11 21:05:11.560 3: WEBphone: port 8084 opened
2016.10.11 21:05:11.561 3: WEBtablet: port 8085 opened
2016.10.11 21:05:11.562 3: geogps: port 9796 opened
....

Daher nehme ich ja auch an, das hier irgendwie direkt Systemrechte verbogen wurden, was ich natürlich nicht nachvollziehen kann; ohne Hilfe zumindest nicht

schka17 · 11 Oktober 2016, 22:14:24

Zitat von: M_I_B am 11 Oktober 2016, 20:50:45
Hallo liebe Leute,

hatte heute Mittag etwa ein Update des Systems angestoßen. Heute Abend wundere ich mich, das wirklich nichts an Aufgaben ausgeführt wurde. ALso flux mal FHEM aufrufen... Nö... keine Verbindung zu FHEM möglich. Also habe ich mal in das LogFile geschaut:

Code Auswählen Erweitern
Can't use an undefined value as a symbol reference at ./FHEM/93_RFHEM.pm line 81. 2016.10.11 20:36:36.793 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt 2016.10.11 20:36:36.793 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt 2016.10.11 20:36:36.798 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt 2016.10.11 20:36:36.813 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt 2016.10.11 20:36:36.843 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt 2016.10.11 20:36:36.853 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt 2016.10.11 20:36:37.825 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt 2016.10.11 20:36:39.749 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt

Das war's dann auch schon
Die üblichen Hinweise, das Telnet nicht installiert sei, sind natürlich dummfug; ist da und funktioniert.

Frage ist also, wo ich hier anfangen muss zu suchen? Irgendwas muss ja bei im heutigen Debian- Update drin gewesen sein, was Telnet vermeintlich Rechte entzogen hat. Nur mit den Rechten unter Debian bin ich ein absoluter DAU und habe wirklich keinen Schimmer, was ich wo wie überprüfen muss, um FHEM wieder ans Laufen zu bringen.

Wäre super, wenn mir da mal wer zeitnah auf die Sprünge helfen könnte.

Anfangen zu suchen? Ich fange immer damit an ob der Prozess aktiv ist und ob die Ports geöffnet sind. wenn ich weiss wo ich zu suchen beginnen soll, probiere ich mal AEG (ausschalten, einschalten, geht). Ich mache nach einem update auch immer sofort shutdown restart und beobachte dabei die logdatei. Keine Ahnung was du davon schon probiert hast.
Du schreibst zu beginn ist alles normal (21:05), die Fehlermeldungen sind von 20:36.
Verwirrt ich bin

rudolfkoenig · 11 Oktober 2016, 22:20:40

Bin etwas ratlos. Kannst du ein "lsof -p <FHEM-Pid>" Ausgabe anhaengen, wobei FHEM-Pid am Anfang des Logs steht. Oder per PS feststellbar ist.

M_I_B · 11 Oktober 2016, 22:21:29

... dann entwirre ich dich mal

Mit Update ist das OS gemeint. Das FHEM- Update lief vorher vollkommen problemlos.
Für das OS- Update habe ich mir ein Script geschrieben, welches den Server nach erfolgreichem Update neu startet.
Das alles lief wie gesagt irgendwann heute umzu Middach. Da das OS- Update offensichtlich keine Fehler generiert hat, habe ich von dem nicht startenden FHEM bis heute Abend nichts mitbekommen.
Die Zeiten des Logfiles sind daher korrekt, da ich erst kurz vor diesem Zeitpunkt Kenntnis vom stehenden FHEM erhalten habe, den Dienst selbst versucht habe neu zu starten, den Server dann neu gestartet und... von dem eitpunkt ist der Log- Auszug...

M_I_B · 11 Oktober 2016, 23:06:35

@rudolfkoenig: versuche ich mal... moment ...

Die FHEM PID ist aktuell 999 (mal gut das nicht 666

)
Ich habe per SSH dann also "lsof -p 999" eingegeben... nix. Keinerlei Ausgabe

BTW: Willst du selber mal drauf zugreifen? Dann mache ich mal einen Port nach außen auf; dann aber per PN o.ä. ...

EDIT:
FHEM per SSH angehalten, Logfile weggesichert und gelöscht, Server neu gestartet, logfile angeschaut... Und nun tauchen die telnet- Fehler gar nicht mehr auf. Es erscheint lediglich noch die Fehlermeldung ...

Code Auswählen

2016.10.11 23:10:20.382 3: CUL_HM set HM1RM3 statusRequest
2016.10.11 23:10:21.386 3: CUL_HM set HM2DI1_1 statusRequest
2016.10.11 23:10:22.390 3: CUL_HM set HM2DI1_2 statusRequest
2016.10.11 23:10:23.394 3: CUL_HM set HM2SD1_1 statusRequest
2016.10.11 23:10:48.463 3: Wetter: 0 result(s) retrieved
Can't use an undefined value as a symbol reference at ./FHEM/93_RFHEM.pm line 81.

... und danach nun nichts mehr ... Komische Sache. Denn vorher kamen ja noch reichlich Fehler mit Telnet hinterher...

schka17 · 11 Oktober 2016, 23:15:22

Zitat von: M_I_B am 11 Oktober 2016, 22:21:29
... dann entwirre ich dich mal

Mit Update ist das OS gemeint. Das FHEM- Update lief vorher vollkommen problemlos.
Für das OS- Update habe ich mir ein Script geschrieben, welches den Server nach erfolgreichem Update neu startet.
Das alles lief wie gesagt irgendwann heute umzu Middach. Da das OS- Update offensichtlich keine Fehler generiert hat, habe ich von dem nicht startenden FHEM bis heute Abend nichts mitbekommen.
Die Zeiten des Logfiles sind daher korrekt, da ich erst kurz vor diesem Zeitpunkt Kenntnis vom stehenden FHEM erhalten habe, den Dienst selbst versucht habe neu zu starten, den Server dann neu gestartet und... von dem eitpunkt ist der Log- Auszug...

Ahja, sorry das kommt davon wenn man drei Sachen gleichzeitig macht.

Das Phänomen das du beschreibst kenne ich, das passiert bei mir auch ab und zu, bei mir wird dann ein child process blockiert, leider habe ich die Ursache noch nicht herausgefunden, seitdem ich versucht habe alle blockierenden Abfragen auf eine andere Instanz auszulagern, tritt es kaum mehr auf.

Sent from my iPad using Tapatalk

M_I_B · 12 Oktober 2016, 14:12:57

... tja, nichts zu wollen

Ich habe dann mal ein Backup von vor drei Tagen zurück gespielt (HD- Image). Nun ist alles wieder schön. Ich werde heute Nacht noch mal einen Versuch unternehmen, erst FHEM und danach das OS auf aktuellen Stand zu bringen. Mal sehen, ob der gleiche Fehler erneut auftaucht.

Code Auswählen

seitdem ich versucht habe alle blockierenden Abfragen auf eine andere Instanz auszulagern
Wie macht man so was? Ich (und sicherlich viele Andere mit ähnlicher Konfig) habe hier z.B. das Problem, das alle per Ser2Net (oder SoCat oder was auch immer) verbundenen Slave- Systeme beim FHEM- Start in Betrieb und erreichbar sein müssen. Ist auch nur einer mal eben weggetreten, kommt FHEM nicht aus'm Knick, da unendlich auf die Verbindung gewartet wird.
Kann man so etwas nicht irgendwie umgehen? Denn wenn ich z.B. nicht im Haus bin und mal ein Netzausfall so lange andauert, das auch die UPS das nicht überbrücken können, benötigen die Systeme natürlich bei Netzwiederkehr unterschiedlich lange beim Booten; es ist kaum kalkulierbar, wer zuerst den Hintern oben hat...

schka17 · 12 Oktober 2016, 15:03:06

Hallo,

also das Problem mit diesen Abhängigkeiten habe ich so nicht, da würde ich aber im startscript entsprechende Wartezeiten oder checks einbauen.
Ich habe ein paar Satelliten Raspis, ein CB und auch auf der Synology eine FHEM Instanz, teils um neue Sachen auszuprobieren oder auch um vom zentralen FHEM einfach verschiedene Dinge zu steuern, das ist alles historisch gewachsen. Diese FHEM's connecten alle zum Mosquitto Server, d.h. die Kommunkiation basiert nur auf MQTT, mit Ausnahme von tts. Auf dem zentralen Gerät habe ich vier FHEM Instanzen, eben ein Test-und Entwicklungssystem, eine Demoinstanz, eine "mach alles was blockieren könnte Instanz" und mein zentrales FHEM.

Code Auswählen

root@HAL9000:/opt/fhem# ps -ef |grep fhem
fhem      1048     1  0 Sep25 ?        00:05:44 perl fhem.pl demo_fhem.cfg
fhem      1568     1  0 Sep25 ?        02:40:40 perl fhem.pl 2_fhem.cfg
root      1983 10956  0 14:36 pts/2    00:00:00 grep fhem
fhem     18015     1  0 Oct09 ?        00:35:09 /usr/bin/perl fhem.pl dev_fhem.cfg
fhem     26192     1 18 Oct11 ?        02:44:40 perl fhem.pl fhem.cfg

alles was blockeiren ist oder sein könnte (soweit ich es erkennen konnte) wird von FHEM2 (oder noch von der Entwicklungsinstanz, da gibts einige longrunning Prototypen) ausgeführt und über ein MQQTDevice im zentralen FHEM dargestellt, angefangen hat das vor langer Zeit mit einem Problem mit 1-wire Server der mir dauernd mein FHEM blockiert hat, mittlerweile funktioniert das ja.

I/O Devices die auch senden sind entweder sowieso Netzwerkdevices oder sonst am zentralen Gerät angesteckt.
Bei reinem Empfängern bzw. Datenlieferanten wie z.B. das OWL Energiemessgerät reicht das das MQTT publishen völlig. Kling jetzt zwar ziemlich kompliziert, funktioniert aber, vor allem da das eine ewige Baustelle ist, sehr gut.

M_I_B · 12 Oktober 2016, 15:18:20

... ganz ehrlich? Ich versteh nur "Bahnhof Kofferklau'n?"

Was ist MQTT ? Noch nie gehört...

Wie gesagt bin ich auf Ser2Net resp. SoCat angewiesen. Der RPi z.B., der zeitnah die komplette Heizungssteuerung (primär, also Brenner, Pumpen, Speicher, ...) übernehmen soll, ist erst mal grundsätzlich autark und hat auch eine eigene UPS (alles Eigenbau; mit'm Lötkolben kann ich um...). Dennoch erhält Dieser von der Hauptinstanz natürlich Informationen, z.B. vom Präsenz- Modul, Umweltdaten, Arbeit-, Feier- und Feriendaten, Weckzeiten, e.t.c. Ebenso meldet der HeizungsPI natürlich auch Stati zurück, im GAU- Fall z.B. Druckabfall (Leck), Brennerstörung, Ölstand Tanks, ...
Ich wüsste jetzt nicht, wie ich das anders realisieren könnte. Und leider sind offensichtlich all diese Module, welche zwei oder mehr Systeme miteinander verbinden können, nicht wirklich blockadefrei...

Wernieman · 12 Oktober 2016, 15:20:26

Automatisiertes Update per eigenscript ..... bist Du sicher, das es sauber durchlief?

Aber mal für eventuelle folgende Fehlersuche:
https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373

M_I_B · 12 Oktober 2016, 15:26:28

... jo, da bin ich ziemlich sicher. In keinem Logfile war irgend was von einem Fehler nach dem Zeitpunkt zu finden.
Wir werden heute Nacht mal sehen, was passiert. Da sicher ich der Übersichtlichkeit wegen mal alle Logfiles weg und lösche die Alten, bevor ich einen neuen Versuch starte. Dann findet man (ich) besser durch, falls was faul ist; ich werde berichten...
Inzwischen läuft es ja wieder mit dem zurück gespielten Backup. Das werde ich heute aber vorher noch mal per Hand anstoßen... besser is das

schka17 · 12 Oktober 2016, 16:06:44

Zitat von: M_I_B am 12 Oktober 2016, 15:18:20
... ganz ehrlich? Ich versteh nur "Bahnhof Kofferklau'n?"

Was ist MQTT ? Noch nie gehört...

Schau mal in der Referenz anch, da sind die enstprechenden FHEM Komponent gut beschrieben, mosquitto kannst auf Debian/Raspian einfach mit apt-get install mosquitto installieren, ich weiss jetzt nicht mehr auswendig ob man die clients extra installieren muss.

Sehr vereinfacht schiebt ein Client (publish) eine Information in einen Messagebus (Topic und Payload) den ein anderer client (subscribed) lesen kann.
Dh. du brauchst beim publishen nur den Topictree und den Inhalt übergeben und das kommt dann beim jedem client der auf dieses Topic subscribed hat, an.

Ich habe z.b. einen Luftdrucksensor, dieser Wert wird gepublisht und in jeder FHEM Instnaz kann ich den verwenden. Oder z.b. habe ich viele OLED/LCD's Displays die auf unterschiedlichste Arten angesprochen werden (eben historisch gewachsen), die Werte dafür kommen von unterschiedlichen FHEM's und werden an der für den Output verantwortlichem FHEM via MQTT subscribe angefragt. Also z.b. Luftdruck bzw. Wetterwerte von yahoo, Temperaturwert vom Pool und pH Wert vom Poolcontroller usw. zu Displayinhalt zusammengestellt und ausgegeben, u.U. auch mit MQTT.

Mosquitto ist der MQTT Server den ich auf meinen DebianServern verwende. Da keine direkte Kommunkation zwischen den FHEM's und anderen MQTT Clients besteht, gibt es auch keine Blockaden, der einzige single point of failure ist halt der zentrale mosquitto. Aber der läuft auf dem zentralen System und wenn der weg ist, dann ist es auch egal wenns keinen mosquitto gibt. Hatte für mich einen riesigen Vorteil, ich hole z.B verschieden Informationen von externen Webseiten (oder Kalender), allerdings nur sehr sporadisch wie z.b. die Wettervorhersage, die ändert sich nicht alle 10 min. Mit FHEM2FHEM bekam ich bei Neustart dieses Device in der zentralen Instanz erst befüllt wenn es denn nächsten Update gibt, mit MQTT bekomm ich sofort den letzten bekannten Stand.

ZitatIch wüsste jetzt nicht, wie ich das anders realisieren könnte. Und leider sind offensichtlich all diese Module, welche zwei oder mehr Systeme miteinander verbinden können, nicht wirklich blockadefrei...

Genau das war für mich der Grund MQTT einzusetzen, und natürlich das ich damit bestehende und zukünftige Plattformen oder Sensoren sehr einfach einbinden kann, wie NodeRed, ESPeasy (bevor es das FHEM Modul gab) meine ehemaliges OPENHAB oder was auch immer da kommen wird.

Also kein socat, FHEM2FHEM oder sonstigen Dinge mehr bei mir. Einzig tts nutze ich noch remote, aber auch nur weil es einfach funktniert und ich noch viele andere Projekt habe, die wichtiger sind.

M_I_B · 12 Oktober 2016, 16:25:01

... ok, erst mal vielen, lieben Dank für die ausführliche Erklärung!
Ich hoffe mal, das ich das jetzt richtig verstanden habe und versuche es mal mit meinen Worten...

Ich installiere auf dem Server (ist ein Xeon, auf dem auch die FHEM- Hauptinstanz läuft) den Mosquito- Server, auf allen anderen Slave- Systemen den Mosquito- Client. Nun übermittle ich nicht mehr per Ser2Net o.ä., sondern teile dem "Stechviech" mit, was für die Slaves bestimmt ist und die Client holen sich dann alles, wenn's für sie bestimmt ist ? So in etwa?

Hast du mal'n Link für DAU's?