NEWS
[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:
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:8081Synology 918+ 16GB - ioBroker in Docker v9 , VISO auf Trekstor Primebook C13 13,3" , Hikvision Domkameras mit Surveillance Station .. CCU RaspberryMatic in Synology VM .. Zigbee CC2538+CC2592 .. Sonoff .. KNX .. Modbus ..
-
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 sagte in Frischer Docker Container lässt sich nicht starten:
sondern ein Netzwerkproblem
wegen ipv6 vielleicht?
@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.
-
@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:8081beim 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!
Synology 918+ 16GB - ioBroker in Docker v8.0.1 | KNX | Homematic | Homemanager | evcc | SMA WR
-
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
Synology 918+ 16GB - ioBroker in Docker v9 , VISO auf Trekstor Primebook C13 13,3" , Hikvision Domkameras mit Surveillance Station .. CCU RaspberryMatic in Synology VM .. Zigbee CC2538+CC2592 .. Sonoff .. KNX .. Modbus ..
-
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:
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.
kein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@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
@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.
-
@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.
@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
Synology 918+ 16GB - ioBroker in Docker v8.0.1 | KNX | Homematic | Homemanager | evcc | SMA WR
-
@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
Support us
773
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge