[gelöst] Frischer Docker Container lässt sich nicht starten
-
Hardware: Synology DS918+
Software: Portainer mit buanet/iobroker ImageHallo Zusammen,
beim Update meines ioBrokers hatte ich ein paar Probleme. Um Altlasten als Ursache auszuschließen, wollte ich einen neuen Container mit leerem /opt/iobroker Verzeichnis aufsetzen (also eine frische ioBroker Instanz) und über backitup ein Backup einspielen.
Dabei habe ich festgestellt, dass ich auf meiner Synology keinen frischen ioBroker Container starten kann - Fehlermeldungen gibt es allerdings auch nicht. Beim starten des Containers wird dieser normal angelegt und das Log ist unauffällig:
-------------------------------------------------------------------------------- ------------------------- 2023-04-23 16:18:00 ------------------------- -------------------------------------------------------------------------------- ----- ----- ----- ██╗ ██████╗ ██████╗ ██████╗ ██████╗ ██╗ ██╗ ███████╗ ██████╗ ----- ----- ██║ ██╔═══██╗ ██╔══██╗ ██╔══██╗ ██╔═══██╗ ██║ ██╔╝ ██╔════╝ ██╔══██╗ ----- ----- ██║ ██║ ██║ ██████╔╝ ██████╔╝ ██║ ██║ █████╔╝ █████╗ ██████╔╝ ----- ----- ██║ ██║ ██║ ██╔══██╗ ██╔══██╗ ██║ ██║ ██╔═██╗ ██╔══╝ ██╔══██╗ ----- ----- ██║ ╚██████╔╝ ██████╔╝ ██║ ██║ ╚██████╔╝ ██║ ██╗ ███████╗ ██║ ██║ ----- ----- ╚═╝ ╚═════╝ ╚═════╝ ╚═╝ ╚═╝ ╚═════╝ ╚═╝ ╚═╝ ╚══════╝ ╚═╝ ╚═╝ ----- ----- ----- ----- Welcome to your ioBroker Docker container! ----- ----- Startupscript is now running! ----- ----- Please be patient! ----- -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- ----- System Information ----- ----- arch: x86_64 ----- ----- hostname: 643148de1007 ----- ----- ----- ----- Version Information ----- ----- image: v8.0.1 ----- ----- build: 2023-04-18T08:05:40+00:00 ----- ----- node: v18.16.0 ----- ----- npm: 9.5.1 ----- ----- ----- ----- Environment Variables ----- ----- AVAHI: false ----- ----- PACKAGES: nano ----- ----- SETGID: 1000 ----- ----- SETUID: 1000 ----- ----- ZWAVE: false ----- -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- ----- Step 1 of 5: Preparing container ----- -------------------------------------------------------------------------------- Updating Linux packages on first run... Done. PACKAGES is set. Installing the following additional Linux packages: nano nano is not installed. Installing... Done. Registering maintenance script as command... Done. -------------------------------------------------------------------------------- ----- 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 permissions (This might take a while! Please be patient!)... Done. Fixing "sudo-bug" by replacing sudo with gosu... Done. Initializing a fresh installation of ioBroker... Done. Hostname in ioBroker does not match the hostname of this container. Updating hostname to "643148de1007"... The host for instance "system.adapter.admin.0" was changed from "buildkitsandbox" to "643148de1007". The host for instance "system.adapter.discovery.0" was changed from "buildkitsandbox" to "643148de1007". The host for instance "system.adapter.backitup.0" was changed from "buildkitsandbox" to "643148de1007". 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 see ioBroker Docker Image Docs (https://docs.buanet.de/iobroker-docker-image/docs/). -------------------------------------------------------------------------------- ----- Step 5 of 5: ioBroker startup ----- -------------------------------------------------------------------------------- Starting ioBroker... ##### #### ### ## # iobroker.js-controller log output # ## ### #### ##### host.643148de1007 check instance "system.adapter.admin.0" for host "643148de1007" host.643148de1007 check instance "system.adapter.discovery.0" for host "643148de1007" host.643148de1007 check instance "system.adapter.backitup.0" for host "643148de1007"Der Admin Adapter ist allerdings nicht erreichbar. Das ist meine Konfiguration in Portainer:
Der Container läuft in einem macvlan mit eigener IP und Standard-Port 8081. Erreichbar ist er also normalerweise unter 192.168.101.10:8081
Merkwürdig ist, dass der alte Container (v6.0.0) problemlos mit identischer Konfiguration läuft.Was ich bisher bereits getestet habe:
- Anpassung des Host-Namens im Container
- Wechsel des Docker Images, z.B. auf v 7.2.0
- Starten des Containers mit leerem /opt/iobroker Verzeichnis (neuanlage) oder mit Verzeichnisdaten aus dem Backup. Das Docker Image in v8.0.1 ist in keinem der beiden Fälle über das Webinterface erreichbar, v7.2.0 ist erreichbar, wenn die Verzeichnisdaten aus dem Backup hinterlegt sind (nicht ohne Verzeichnisdaten) - allerdings lassen sich Adapter hier nicht aktualisieren (NPM und NodeJs Pfade sind korrekt)
- Anlage des Containers nicht über Portainer, sondern über die Synology DSM Docker Station. Netzwerk in diesem Fall "host", Port 8081 ist bisher noch nicht belegt auf dem Host.
Kein Versuch führte zum Erfolg, in allen Fällen (Ausnahme Punkt 3: Image v7.2.0 mit nicht-leerem /opt/iobroker Verzeichnis) ist das Webinterface gar nicht erreichbar
Hat jemand Ideen oder Tipps, was ich noch prüfen könnte? Die Ausgangslage ist ja eigentlich recht einfach - es soll zunächst einfach nur ein neuer ioBroker Container ohne Altdaten gestartet werden können
Viele Grüße,
Percy
-
@percy sagte in Frischer Docker Container lässt sich nicht starten:
Hat jemand Ideen oder Tipps, was ich noch prüfen könnte? Die Ausgangslage ist ja eigentlich recht einfach - es soll zunächst einfach nur ein neuer ioBroker Container ohne Altdaten gestartet werden können
was sagt im Container
iob status adminund
netstat -an|grep 8081 -
@marc-berg said in Frischer Docker Container lässt sich nicht starten:
netstat -an|grep 8081
root@643148de1007:/opt/iobroker# iob status admin Instance "admin.0" is running root@643148de1007:/opt/iobroker# netstat -an|grep 8081 tcp6 0 0 :::8081 :::* LISTEN -
@percy
Dann ist es aber kein iobroker - sondern ein Netzwerkproblem -
@marc-berg sagte in Frischer Docker Container lässt sich nicht starten:
sondern ein Netzwerkproblem
wegen ipv6 vielleicht?
-
sieht mir eher aus , das du mit deinem macvlan Probleme hast .
Teste mal mit :
Image :
stefanwalther/docker-test:latestBeispiel :
dann sollte das raus kommen : http://192.168.178.229:3000
-
@marc-berg auf einen Ping bekomme ich eine Antwort vom Container, grundsätzlich ist er also erreichbar:
C:\Users\percy>ping 192.168.101.10 Ping wird ausgeführt für 192.168.101.10 mit 32 Bytes Daten: Antwort von 192.168.101.10: Bytes=32 Zeit<1ms TTL=64 Antwort von 192.168.101.10: Bytes=32 Zeit<1ms TTL=64 Antwort von 192.168.101.10: Bytes=32 Zeit<1ms TTL=64 Antwort von 192.168.101.10: Bytes=32 Zeit<1ms TTL=64 Ping-Statistik für 192.168.101.10: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 0ms, Maximum = 0ms, Mittelwert = 0msIch habe noch weitere Container mit identischen Einstellungen laufen, die ebenfalls erreichbar sind
-
@percy sagte in Frischer Docker Container lässt sich nicht starten:
Erreichbar ist er also normalerweise unter 192.168.101.10:8081
gib den Container einen andere IP , und öffne Sie in einem anderen Browser
HTTP
http://192.168.101.11:8081 -
-
OK ..
dann siehe den Beitrag von mir oben ! -
@homoran sagte in Frischer Docker Container lässt sich nicht starten:
@marc-berg sagte in Frischer Docker Container lässt sich nicht starten:
sondern ein Netzwerkproblem
wegen ipv6 vielleicht?
ne, sieht bei mir genau so aus. Damit ist der Host auch unter IPv4 erreichbar
wget -4 http://iobroker:8081liefert von einem anderen Container aus auch eine Antwort.
-
beim Testen mit einer geänderten IP habe ich den Fehler gefunden: mein Aufruf erfolgt stets über HTTPS - das liefert bei den neuen Containern keine Antwort. Ein kurzer Test mit HTTP in der URL führt zu einem Ergebnis in der Admin-Oberfläche. Durch die Verwendung der bisherigen IP-Adresse verwendet der Browser automatisch HTTPS, was aber in Chrome erst sichtbar wird, wenn man die URL manuell editiert.
Ich vermute, der HTTPS Zugang wird erst bei der Einrichtung durch diese Einstellung aktiviert:
Da ich bisher immer die Containerdaten mit migriert habe, ist mir das bisher nie aufgefallen. Bei einem frischen Container aber ein sehr wichtiger Unterschied.
Vielen Dank für eure schnelle Unterstützung - das hat mir sehr weitergeholfen!
-
@percy sagte in Frischer Docker Container lässt sich nicht starten:
Ein kurzer Test mit HTTP in der URL führt zu einem Ergebnis in der Admin-Oberfläche.
Habe ich dann auch schon vermutet , deshalb immer einen anderen Browser nutzen !
deshalb :
@glasfaser sagte in Frischer Docker Container lässt sich nicht starten:
und öffne Sie in einem anderen Browser
HTTP
http://192.168.101.11:8081Ich vermute, der HTTPS Zugang wird erst bei der Einrichtung durch diese Einstellung aktiviert:
richtig ... Standart ist HTTP
-
@percy sagte in Frischer Docker Container lässt sich nicht starten:
mein Aufruf erfolgt stets über HTTPS -
deswegen sehe ich mir gerne
iob list instancesanstelle@marc-berg sagte in Frischer Docker Container lässt sich nicht starten:
was sagt im Container
iob status adminund
netstat -an|grep 8081an.
erstens kann ich kein linux wie in teil 2, zweitens hätte das den secure angezeigt (oder eben nicht)
aber ich arbeite nicht mit Containern, ist mir zu komplex, war mir daher nicht sicher, ob dasda wieder eine Sonderlocke gibt.
-
@glasfaser Der Tipp war gut, nur dadurch ist mir aufgefallen, dass etwas in der URL falsch sein musste. Nachdem ich mir stundenlang den Kopf zerbrochen habe, war die Lösung doch so einfach.
-
@homoran Gerade die Kombination "Docker administriert über Portainer auf Synology" birgt leider einige Fallstricke, deshalb war ich mir ebenfalls unsicher, wo der Fehler liegt. In diesem Fall aber nicht in der Software
-
