(gelöst) Fehler mit Restore bei Docker auf Synology
-
@iobroker_Rainer
Da liegt ein Fehler vor, er startet nicht .Hast du bei deinem Admin ( Backup ) irendwelche Einstellungen drin .... anderen Port ... feste IP !?
Zeige mal die Ausgabe von
iobroker list adapters iobroker list instances -
@iobroker_Rainer
Ich habe gerade das System neu eingerichtet. Admin-Oberfläche war aufrufbar. Danach restore. Danach Admin-Oberfläche wieder nicht mehr aufrufbar.root@iobroker2:/opt/iobroker/backups# iobroker list adapters system.adapter.admin : admin - v4.0.10 system.adapter.backitup : backitup - v1.5.8 system.adapter.cloud : cloud - v3.0.4 system.adapter.daswetter : daswetter - v3.0.1 system.adapter.discovery : discovery - v2.3.7 system.adapter.flot : flot - v1.9.2 system.adapter.harmony : harmony - v1.2.2 system.adapter.info : info - v1.7.2 system.adapter.innogy-smarthome : innogy-smarthome - v0.3.6 system.adapter.javascript : javascript - v4.6.17 system.adapter.mercedesme : mercedesme - v0.0.21 system.adapter.mobile : mobile - v1.0.1 system.adapter.modbus : modbus - v3.1.6 system.adapter.node-red : node-red - v1.17.2 system.adapter.ping : ping - v1.4.8 system.adapter.scenes : scenes - v1.1.0 system.adapter.shelly : shelly - v4.0.2 system.adapter.simple-api : simple-api - v2.4.6 system.adapter.socketio : socketio - v3.0.13 system.adapter.sonoff : sonoff - v2.3.3 system.adapter.sql : sql - v1.15.2 system.adapter.tankerkoenig : tankerkoenig - v2.0.5 system.adapter.telegram : telegram - v1.5.9 system.adapter.terminal : terminal - v0.1.2 system.adapter.tr-064 : tr-064 - v4.0.9 system.adapter.upnp : upnp - v1.0.16 system.adapter.vis : vis - v1.2.11 system.adapter.vis-fancyswitch : vis-fancyswitch - v1.1.0 system.adapter.vis-map : vis-map - v1.0.4 system.adapter.vis-metro : vis-metro - v1.1.2 system.adapter.vis-plumb : vis-plumb - v1.0.2 system.adapter.vis-timeandweather : vis-timeandweather - v1.1.7 system.adapter.vis-weather : vis-weather - v2.5.2 system.adapter.web : web - v3.0.12root@iobroker2:/opt/iobroker/backups# iobroker list instances system.adapter.admin.0 : admin - enabled, por t: 8081, bind: 0.0.0.0, run as: admin system.adapter.backitup.0 : backitup - enabled system.adapter.cloud.0 : cloud - disabled system.adapter.daswetter.0 : daswetter - disabled system.adapter.discovery.0 : discovery - disabled system.adapter.flot.0 : flot - disabled system.adapter.harmony.0 : harmony - disabled system.adapter.info.0 : info - disabled system.adapter.innogy-smarthome.0 : innogy-smarthome - disabled system.adapter.javascript.0 : javascript - disabled system.adapter.mercedesme.0 : mercedesme - disabled system.adapter.mobile.0 : mobile - disabled system.adapter.modbus.0 : modbus - disabled system.adapter.node-red.0 : node-red - disabled, por t: 1880, bind: 0.0.0.0 system.adapter.ping.0 : ping - disabled system.adapter.scenes.0 : scenes - disabled system.adapter.shelly.0 : shelly - disabled, por t: 1882, bind: 0.0.0.0 system.adapter.simple-api.0 : simple-api - disabled, por t: 8087, bind: 0.0.0.0, run as: admin system.adapter.sonoff.0 : sonoff - disabled, por t: 1883, bind: 0.0.0.0 system.adapter.sql.0 : sql - disabled, por t: 3307 system.adapter.tankerkoenig.0 : tankerkoenig - disabled system.adapter.telegram.0 : telegram - disabled, por t: 8443, bind: 0.0.0.0 system.adapter.terminal.0 : terminal - disabled, por t: 8088, bind: 0.0.0.0, run as: admin system.adapter.tr-064.0 : tr-064 - disabled system.adapter.tr-064.1 : tr-064 - disabled system.adapter.upnp.0 : upnp - disabled system.adapter.vis-fancyswitch.0 : vis-fancyswitch - disabled system.adapter.vis-metro.0 : vis-metro - disabled system.adapter.vis-plumb.0 : vis-plumb - disabled system.adapter.vis-timeandweather.0 : vis-timeandweather - disabled system.adapter.vis-weather.0 : vis-weather - disabled system.adapter.vis.0 : vis - disabled system.adapter.web.0 : web - disabled, por t: 8082, bind: 0.0.0.0, run as: admin + instance is alive -
@iobroker_Rainer Schon mal nen Blick in die Logdateien geworfen? Ggf. hat sich der Hostname des Containers geändert?
-
@iobroker_Rainer ... und das waren die alten Admin-Einstellungen. Kann es an der Authentifizierung liegen???
-
@AlCalzone ... ja und ja.
Ja. Ich habe die Log-Dateien angeschaut - aus meiner Sicht unauffällig.
Ja. Der Hostname des Containers hat sich geändert - wo und wie könnte sich das denn auswirken? Wie geschrieben - vor dem Restore hat der Zugriff auf die Admin-Oberfläche ja noch geklappt - und ich sehe aktuell nicht, wo im Backupfile der Container-Name relevant wäre ... -
@iobroker_Rainer admin adapter neu installiert - keine Problemlösung ...
root@iobroker2:/opt/iobroker# iobroker stop admin The adapter "admin.0" was stopped. root@iobroker2:/opt/iobroker# npm install iobroker.admin sudo: Hostname iobroker2 kann nicht aufgelöst werden: Der Name oder der Dienst ist nicht bekannt npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.3 (node_modules/fse vents): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@ 2.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"} ) npm WARN optional SKIPPING OPTIONAL DEPENDENCY: osx-temperature-sensor@1.0.7 (no de_modules/osx-temperature-sensor): npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for osx-tempe rature-sensor@1.0.7: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux" ,"arch":"x64"}) + iobroker.admin@4.0.10 updated 1 package in 13.816s 24 packages are looking for funding run `npm fund` for details root@iobroker2:/opt/iobroker# iobroker upload admin upload [3] admin.admin /opt/iobroker/node_modules/iobroker.admin/admin/words.js words.js application/javascript upload [2] admin.admin /opt/iobroker/node_modules/iobroker.admin/admin/index_m.h tml index_m.html text/html upload [1] admin.admin /opt/iobroker/node_modules/iobroker.admin/admin/index.htm l index.html text/html upload [0] admin.admin /opt/iobroker/node_modules/iobroker.admin/admin/admin.png admin.png image/png root@iobroker2:/opt/iobroker# iobroker start admin The adapter "admin.0" was started. root@iobroker2:/opt/iobroker# iobroker status admin Instance "admin.0" is not running root@iobroker2: -
@iobroker_Rainer Neuen Admin eingerichtet mit neuem Port - alles wieder paletti!!!
-
@iobroker_Rainer sagte in Restore klappt nicht:
Ich habe die Log-Dateien angeschaut - aus meiner Sicht unauffällig.
Stand da was von "does not start any instances on this host"?
Der Hostname des Containers hat sich geändert - wo und wie könnte sich das denn auswirken?
Instanzen (auch admin) sind einem Host zugeordnet. Wenn der Hostname anders ist, glaubt ioBroker, dass es die Instanz nicht starten muss, weil diese vermutlich zu einem anderen Host gehört
-
@AlCalzone Ja, genau das ist der Fall.
host.iobroker_Neu does not start any instances on this hostich war auch ein bißchen zu schnell mit meinem "alles wieder paletti". Das Frontend kann ich wieder öffnen, die Instanzen sind auch alle da, aber "ROT". Ich kann sie von Hand auch nicht starten.
... Weisst Du, wo ich diesen Host-Namen einstellen/verändern kann? -
@iobroker_Rainer sagte in Restore klappt nicht:
Weisst Du, wo ich diesen Host-Namen einstellen/verändern kann?
- ioBroker stoppen
- Die Datei
/opt/iobroker/iobroker-data/objects.jsonmit einem Editor öffnen.
Dort solltest du einige Vorkommen hiervon sehen:
Diese musst du ersetzen durch"host":"iobroker_Neu"
(oder es könnte auch genau umgekehrt sein)."host":"iobroker2" - Datei speichern, ioBroker starten.
-
@iobroker_Rainer und es läuft kein weiterer Container mit ioBroker-Resten?
Nach Stillegung dieser wurde das gesamte System komplett neu gestartet? -
@Homoran ... den "alten" noch funktionierenden Container gibt es noch. Zu einem Zeitpunkt sind nie beide Container Gleichzeitig geöffnet. Manchmal schaue ich mir aber in dem alten noch was an um herauszufinden, wo die Unterschiede liegen. Einiges habe ich ja auch schon rausgefunden ...
-
@iobroker_Rainer sagte in Restore klappt nicht:
Zu einem Zeitpunkt sind nie beide Container Gleichzeitig geöffnet.
das reicht nicht.
Wie wir im anderen Fall gesehen haben sind die Ports trotzdem noch reserviert -
@Homoran da habe ich mich unklar ausgedrückt: im Docker läuft zu einem Zeitpunkt genau ein Container, der andere ist gestoppt. Solange ich nicht weiss, ob ich den neuen zum Fliegen kriege, kann ich den alten ja nicht löschen ...
-
@iobroker_Rainer sagte in Restore klappt nicht:
der andere ist gestoppt.
und danach wurde die Syno oder wo immer der Docker drauf läuft neu gestertet?
-
@Homoran Korrekt. Ich setze es aber gerne nochmals neu auf. Bin schon den 2. Tag an dem Thema dran und mache vermutlich auch Flüchtigkeitsfehler. Wo genau im Ablauf findet denn diese Host-Namen-Vergabe statt??? Ist das beim Erzeugen des Dockercontainers?
-
@iobroker_Rainer Kann ich dir nicht sagen, ich arbeite nicht mit Containern und verstehe auch nicht warum Einsteiger sich das immer wieder antun.
-
@Homoran ... okay. Wenn Du es nicht weisst, dann liegt es beim Erzeugen des Containers. Das hilft mir schon mal weiter, denn soviele Stellen gibt es da nicht ...
Auf die Frage des "Warum" folgende Antwort: ioBroker läuft auf meiner Syno. Meines Wissens gibt es dafür 4 Möglichkeiten:- Direkt im Betriebssystem der Syno. Wollte ich nicht machen, da ich Seiteneffekte befürchtete
- Virtual Machine Manager - eigenes Linux auf der Syno anlegen und dort ohne Einschränkungen iobroker installieren
- Docker/Portainer: War ein einfacher Einstieg für mich, gibt aber im Lauf der Zeit einiges an Problemen (siehe jetzt)
Früher hatte ich noch einen Raspi im Einsatz, wollte allerdings an meine IT etwas streamlinen ...
-
@iobroker_Rainer nach einem Restore und vor dem Start von ioBroker in einem "normalen" System hilft auch der Befehl
iobroker host this -
@Homoran ... wow - ist wie Weihnachten ...
-
Installation des Containers passt jetzt.
-
ioBroker wurde neu installiert und läuft
-
Zugriff auf Weboberfläche geht
-
Restore vom Terminal aus hat geklappt
-
die Instanzen werden zunehmend grün
Dank Euch allen, die Ihr mitgeholfen habt. Ich schreibe nochmals zusammen, was aus meiner Sicht zu berücksichtigen ist - vielleicht hilft es jemandem der mal über dieses Topic stolpert ...
-
