"telnetPort: Can't open server port at 7072: Address already in use. Exiting."

[amberman]

Hallo,
ich betreibe FHEM auf einem Raspberry PI. Installation und Konfiguration funktionieren auf einer "sauberen" aktuellen Debian-Installation einwandfrei.
Nach dem Reboot des Systems ist jedoch das FHEM-Webfrontend nicht mehr erreichbar.
Ein Blick ins /opt/fhem/log zeigt: "telnetPort: Can't open server port at 7072: Address already in use. Exiting."

Soweit ich es mit
netstat -lpn |grep :7072
festellen kann, wird Port 7072 dauerhaft von einem Perl Prozess blockiert, der FHEM-Initialisierungsprozess der fhem.cfg bricht deshalb bereits bei der Einrichtung des Telnet-Ports ab.

Workaround: FHEM in der shell stoppen, den mit "netstat -lpn |grep :7072" ausgeworfen Prozess per "kill -9 [Prozess]" abschießen und FHEM neu starten.
Danach ist das Webfrontend wieder erreichbar.

Das kann jedoch ja keine dauerhafte Lösung sein. Wie verhindere ich, dass der Port 7072 beim Boot von dem anderen Prozess blockiert wird? Auf dem Rasberry läuft als (installierte) Anwendung ausschließlich FHEM.
Deshalb habe ich den Verdacht, dass sich die fhem.pl den Port 7072 beim boot "greift" und nicht mehr hergibt.
Googeln von "7072 fhem.pl" ergibt einige Treffer, offenbar kann man damit Updates ausführen. Wozu ist dieses Script gut und wie kann man verhindern, dass es beim Booten Ärger macht?

Herzlichen Dank für Hinweise! 

[herrmannj]

Herzlich Willkommen!

fhem wird vmtl 2 mal gestartet.

Deshalb habe ich den Verdacht, dass sich die fhem.pl den Port 7072 beim boot "greift" und nicht mehr hergibt.

Arbeitet wie geplant. Auf 7072 läuft der fhem telnet Zugang - das soll er ja auch. Das anschließend startende zweite fhem (das gehört da nicht hin) möchte den telnet auf 7072 ebenfalls öffnen. Das scheitert weil ja fhem bereits läuft ..

Welche Mechanismus zum automatischen Start von fhem hast Du eingerichtet ?

vg
joerg

[viegener]

Wenn das Webfrontend nicht mehr erreichbar ist, aber der Port 7072 noch blockiert ist (wohl von FHEM) hast Du neben dem bereits vermuteten Doppelstart von FHEM noch ein anderes Problem. Und nur zur Sicherheit der telnetport ist nicht nur fürs update.

Wenn Du das Doppelstartproblem gelöst hast, solltest Du das eigentliche Probleme versuchen zu analysieren, warum FHEMWeb nicht mehr erreichbar scheint. Möglicherweise helfen PerformanceMonitor und Apptime weiter. Dazu gibt es auch eine ganze Reihe von Hinweisen im Net.

[amberman]

Hallo,

herzlichen Dank für die Anworten!

Welche Mechanismus zum automatischen Start von fhem hast Du eingerichtet ?

Ich habe FHEM lediglich aus den Paketquellen auf einem Raspberry installiert. Darüber hinaus habe ich selbst aktiv keine weiteren Autostart-Einträge vorgenommen.

Mittlerweile habe ich herausgefunden: Der Fehler tritt nur auf, wenn ich vor dem Neustart des Raspi die FHEM-Instanz händisch in der shell mit "stop" beende.
Wenn ich den Raspi dagegen einfach durchstarte (und FHEM also von Betriebssystem beendet wird), startet auch FHEM wieder korrekt.
Auch wenn ich lediglich FHEM stoppe/starte, läuft alles korrekt.

Irgendwas wird beim manuellen "stop" von FHEM in Kombination mit einem Neustart des Raspi also ausgelöst... Nur was?

Mit dem jetzt so vorliegenden Fehlerbild und dem Workaround kann ich leben, aber schön ist anders...

[maci]

Auch wenn der Thread schon etwas zurückliegt.

Ich hole in trotzdem hervor, weil mein Thema da genau dazu passt.

Ich habe genau das gleiche Phänomen, hervorgerufen durch das Nicht erreichen der 2. Fhem Installation.

Es stellt sich also so dar: wenn die 2. Fhemserver nicht per Telnet erreichbar ist, hängt auch der 1. Server.

Richtig wäre für mich:
2. Server nicht erreichbar -> Fehlermeldung im Log, aber 1. Server läuft weiter nur ohne den aktuellen Daten des 2. Servers.
2. Server wieder erreichbar, alles wieder Normal.

Meine Frage: Wie kann dieser Verhalten erreich werden?