NEWS
Port 9000/9001 Verbindungsproblem Docker Host Network
-
Hallo zusammen!
Ich versuche ioBroker als Docker Container auf meiner Synology DiskStation laufen zu lassen. Dabei kommt es zu Problemen, wenn ich als Netzwerk dasselbe Netzwerk, wie das der DiskStation auswähle.
Ich verwende als Image
buanet/iobroker:v5.0.0
. Direkt nach der Erstellung ist der Container nicht erreichbar. Ein Aufruf von 192.168.13.10:8081 (IP meiner DiskStation) läuft ins Leere.Hier ist der gesamte Log Output unmittelbar nach der Erstellung des Containers:
------------------------------------------------------------ --------------- 2020-10-26 21:21:47 --------------- ------------------------------------------------------------ ------------------------------------------------------------ ----- Welcome to your ioBroker-container! ----- ----- Startupscript is now running. ----- ----- Please be patient! ----- ------------------------------------------------------------ ------------------------------------------------------------ ----- Debugging information ----- ----- ----- ----- System ----- ----- arch: x86_64 ----- ----- ----- ----- Versions ----- ----- image: v5.0.0 ----- ----- node: v12.19.0 ----- ----- npm: 6.14.8 ----- ----- ----- ----- ENV ----- ----- SETGID: 1000 ----- ----- SETUID: 1000 ----- ------------------------------------------------------------ ------------------------------------------------------------ ----- Step 1 of 5: Preparing container ----- ------------------------------------------------------------ Nothing to do here. ------------------------------------------------------------ ----- Step 2 of 5: Detecting ioBroker installation ----- ------------------------------------------------------------ There is no data detected in /opt/iobroker. Restoring initial ioBroker installation... Done. ------------------------------------------------------------ ----- Step 3 of 5: Checking ioBroker installation ----- ------------------------------------------------------------ (Re)Setting folder permissions (This might take a while! Please be patient!)... Done. Fixing "sudo-bug" by replacing sudo in iobroker with gosu... Done. Looks like this is a new and empty installation of ioBroker. Hostname needs to be updated to ds716... Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! Socket.io Server detected. Please update to js-controller 2.0 or higher! The host for instance "system.adapter.admin.0" was changed from "f426e528c845" to "ds716". The host for instance "system.adapter.discovery.0" was changed from "f426e528c845" to "ds716". The host for instance "system.adapter.info.0" was changed from "f426e528c845" to "ds716". Done. ------------------------------------------------------------ ----- Step 4 of 5: Applying special settings ----- ------------------------------------------------------------ Some adapters have special requirements/ settings which can be activated by the use of environment variables. For more information take a look at readme.md on Github! ------------------------------------------------------------ ----- Step 5 of 5: ioBroker startup ----- ------------------------------------------------------------ Starting ioBroker... host.ds716 check instance "system.adapter.admin.0" for host "ds716" host.ds716 check instance "system.adapter.discovery.0" for host "ds716" host.ds716 check instance "system.adapter.info.0" for host "ds716"
Sehr verwirrend sind die Zeilen mit
Socket.io Server detected. Please update to js-controller 2.0 or higher!
.In einem anderen Thread (https://forum.iobroker.net/topic/37951/hm-rpc-keine-objekte-sichtbar) wurde mit bester Hilfe von @Glasfaser herausgearbeitet, dass die Ports 9000/9001 belegt sind und es so zu einem Konflikt kommt.
Ein SSH auf die DS bringt dann folgendes Bild:
~$ sudo netstat -apn|grep 9000 tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 20668/iobroker.js-c tcp 0 0 172.17.0.1:60178 172.17.0.3:9000 ESTABLISHED 18253/docker-proxy tcp 0 0 172.17.0.1:60225 172.17.0.3:9000 ESTABLISHED 18253/docker-proxy tcp 0 0 172.17.0.1:60179 172.17.0.3:9000 ESTABLISHED 18253/docker-proxy tcp 0 0 172.17.0.1:60226 172.17.0.3:9000 ESTABLISHED 18253/docker-proxy tcp 0 0 172.17.0.1:60218 172.17.0.3:9000 ESTABLISHED 18253/docker-proxy tcp 0 0 172.17.0.1:60217 172.17.0.3:9000 ESTABLISHED 18253/docker-proxy ~$ sudo netstat -apn|grep 9001 tcp 0 0 127.0.0.1:32866 127.0.0.1:9001 TIME_WAIT - tcp 0 0 127.0.0.1:33013 127.0.0.1:9001 TIME_WAIT - tcp 0 0 127.0.0.1:34283 127.0.0.1:9001 TIME_WAIT - tcp 0 0 127.0.0.1:33493 127.0.0.1:9001 TIME_WAIT - tcp 0 0 127.0.0.1:33009 127.0.0.1:9001 TIME_WAIT - tcp 0 0 127.0.0.1:33192 127.0.0.1:9001 TIME_WAIT - tcp 0 0 127.0.0.1:32947 127.0.0.1:9001 TIME_WAIT - tcp 0 0 127.0.0.1:33133 127.0.0.1:9001 TIME_WAIT - tcp 0 0 127.0.0.1:33017 127.0.0.1:9001 TIME_WAIT - tcp 0 0 127.0.0.1:33067 127.0.0.1:9001 TIME_WAIT - tcp 0 0 127.0.0.1:34286 127.0.0.1:9001 TIME_WAIT - tcp 0 0 127.0.0.1:33992 127.0.0.1:9001 TIME_WAIT - tcp 0 0 127.0.0.1:33007 127.0.0.1:9001 TIME_WAIT - tcp6 0 0 :::9001 :::* LISTEN 19642/docker-proxy tcp6 0 0 127.0.0.1:9001 127.0.0.1:34265 TIME_WAIT - tcp6 0 0 127.0.0.1:9001 127.0.0.1:34730 TIME_WAIT - tcp6 0 0 127.0.0.1:9001 127.0.0.1:33382 TIME_WAIT - ... ... ...
Hier ist anscheinend der Prozess
docker-proxy
für die "Störung" verantwortlich. Leider habe ich überhaupt keine Idee, was es damit auf sich haben könnte. Es handelt sich auf jeden Fall nicht um einen anderen Container.Wenn ich den Prozess kille und den Container dann neu starte, lässt sich die ioBroker Oberfläche aufrufen. Nach einem Reboot der DiskStation ist das Problem jedoch wieder da. Ein manueller Kill ist also auf keinen Fall eine Lösung!
Hier noch der
netstat
Output nach dem Kill und Container Neustart:~$ sudo netstat -apn|grep 9000 tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 8370/iobroker.js-co tcp 0 0 127.0.0.1:42305 127.0.0.1:9000 ESTABLISHED 8869/io.discovery.0 tcp 0 0 127.0.0.1:9000 127.0.0.1:42295 ESTABLISHED 8370/iobroker.js-co tcp 0 0 192.168.13.10:39771 192.168.13.1:49000 TIME_WAIT - tcp 0 0 127.0.0.1:42297 127.0.0.1:9000 ESTABLISHED 8594/io.admin.0 tcp 0 0 127.0.0.1:9000 127.0.0.1:42305 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:9000 127.0.0.1:42296 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:9000 127.0.0.1:42306 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:9000 127.0.0.1:42297 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:42306 127.0.0.1:9000 ESTABLISHED 8869/io.discovery.0 tcp 0 0 127.0.0.1:42304 127.0.0.1:9000 ESTABLISHED 8869/io.discovery.0 tcp 0 0 127.0.0.1:42296 127.0.0.1:9000 ESTABLISHED 8594/io.admin.0 tcp 0 0 127.0.0.1:42295 127.0.0.1:9000 ESTABLISHED 8594/io.admin.0 tcp 0 0 127.0.0.1:9000 127.0.0.1:42304 ESTABLISHED 8370/iobroker.js-co ~$ sudo netstat -apn|grep 9001 tcp 0 0 127.0.0.1:9001 0.0.0.0:* LISTEN 8370/iobroker.js-co tcp 0 0 127.0.0.1:9001 127.0.0.1:37008 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:37013 127.0.0.1:9001 ESTABLISHED 9015/io.info.0 tcp 0 0 127.0.0.1:37006 127.0.0.1:9001 ESTABLISHED 8869/io.discovery.0 tcp 0 0 127.0.0.1:37014 127.0.0.1:9001 ESTABLISHED 9015/io.info.0 tcp 0 0 127.0.0.1:9001 127.0.0.1:37015 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:9001 127.0.0.1:36997 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:36997 127.0.0.1:9001 ESTABLISHED 8594/io.admin.0 tcp 0 0 127.0.0.1:37007 127.0.0.1:9001 ESTABLISHED 8869/io.discovery.0 tcp 0 0 127.0.0.1:37008 127.0.0.1:9001 ESTABLISHED 8869/io.discovery.0 tcp 0 0 127.0.0.1:36998 127.0.0.1:9001 ESTABLISHED 8594/io.admin.0 tcp 0 0 127.0.0.1:9001 127.0.0.1:36998 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:9001 127.0.0.1:36999 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:9001 127.0.0.1:37006 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:9001 127.0.0.1:37007 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:36999 127.0.0.1:9001 ESTABLISHED 8594/io.admin.0 tcp 0 0 127.0.0.1:9001 127.0.0.1:37013 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:9001 127.0.0.1:37014 ESTABLISHED 8370/iobroker.js-co tcp 0 0 127.0.0.1:37015 127.0.0.1:9001 ESTABLISHED 9015/io.info.0
Hier noch die Container Details aus Portainer (Portainer ist bei mir auf Port 8999 gemappt, nur zur Info )
Das wirklich verrückte (zumindest aus meiner Sicht) ist, dass sich derselbe Container starten lässt, wenn ich ihn im Bridge Mode laufen lasse (also nicht im selben Netzwerk wie die DiskStation). Ich frage mich, warum es dann anscheinend keine Probleme mit den Ports 9000/9001 gibt.
Wer hat so etwas schon einmal gesehen? Wo kann ich eventuell nach der Ursache des Fehlers suchen?
Besten Dank...
Kraxelhuber