Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[MartinP]

@hank-0

Node und NPM sind etwas alt ... bei mir ...

Plattform: linux
RAM: 4 GB
Node.js: v18.18.2
NPM: 9.8.1

Hast Du Dir in dem Link aus Deinem Logging mal die Dokumentation zu SETGID und SETUID angeschaut?
Es wird ja etwas zu Problemen mit Userrechten geloggt ...

Ist aber merkwürdig, wenn das vorher funktioniert hat, und nichts geändert wurde...

[Codierknecht]

@hank-0

@martinp sagte in ioBroker: Docker Bootschleife:

Node und NPM sind etwas alt

und passen nicht zusammen!

Du hast die Daten in einem Verzeichnis auf dem NAS liegen und dieses in den Container gemountet?

• Container stoppen und löschen
• Neuen Container mit identischen Einstellungen erzeugen und starten
  Dazu am besten das aktuelle Image von buanet verwenden.
• warten, warten, warten ... voilá

[Hank 0]

Die passen nicht zusammen? Ich kann mich nicht daran erinnern etwas aktualisiert zu haben. Wenn es über die ioBroker GUI geht dann vielleicht irgendwann mal aber nicht seit gestern....aber sei es drumm, wenn das so geht mit dem neuen Container, dann werde ich das probieren.

Nur bin ich mir überhaupt nicht sicher, ob ich das so mit dem Pfad gemacht habe :confounded: Ich glaube ich habe das damals nicht so gemacht und die Daten liegen mit im Container...

[Codierknecht]

@hank-0 sagte in ioBroker: Docker Bootschleife:

Die passen nicht zusammen?

Die NPM-Version ist in der Regel die Hälfte der Node-Version.
Also Node 16 mit NPM 8, Node 18 mit NPM 9.

die Daten liegen mit im Container

Niemals machen!
Container sind Wegwerfartikel. Dazu sind sie gedacht.
Wenn die Daten mit im Container liegen, sind sie beim Löschen desselben futsch.
Da hilft dann nur noch ein Backup.

Edit
Das gehört in etwa so:

[Hank 0]

Ich habe es definitiv nicht aktiv angefasst und diese Versionen installiert.

Dies ist auch der einzige Container der so blöd angelegt ist...war mal zum testen und dann wurde nochmal was probiert und irgendwann später nochmal und dann war es doch ganz schön viel über das man sich dann keine Gedanken mehr gemacht hat...

Backup kann ich nur den ganzen Ordner der Container Station von einer externen Backup Festplatte wiederherstellen.
Die anderen Container interessieren mich eigentlich nicht die ich laufen habe.

[Codierknecht]

@hank-0 sagte in ioBroker: Docker Bootschleife:

Backup kann ich nur den ganzen Ordner der Container Station von einer externen Backup Festplatte wiederherstellen.

Du hast kein ioBroker-Backup vom BackItUp-Adapter?

[Hank 0]

Wie gesagt, dass war nur ein Test zum spielen und damit wurde mit den Jahren immer mal was gemacht und dann habe ich daran nicht gedacht...

Edit: Ich kann mich zumindest auch nicht daran erinnern, dass ich eingestellt habe...

Edit:
Ich kann auch leider nicht viel machen in der Console, da er ja in einer Boot Schleife steckt. Ich habe den Container dupliziert und npm/node aktualsiert auf v10 und v21 aber das bringt auch nichts.

Das Backup von der externen Platte bringt anscheinend auch nichts, da ich wohl den falschen Ordner im Backup habe.
Ich würde das jetzt nur sehr ungerne aufgeben :(

[Codierknecht]

@hank-0
Aufgeben ist hier nur selten eine Option.

Kommst Du per Terminal (PuTTY, PowerShell) an den Container, während das Startscript läuft?
Dann könnte man das möglicherweise stoppen und so die Dauerschleife unterbrechen.
Geht vielleicht auch von der Weboberfläche des NAS. Aber bei QNAP kenne ich mich nicht aus.

Wie das Stoppen des Startscriptes geht, werden wir hier sicher herausbekommen.
Zunächst ist mal wichtig, dass Du während der Startphase mit dem Terminal an die Kiste rankommst.

[Ein ehemaliger Benutzer]

@codierknecht sagte in ioBroker: Docker Bootschleife:

Geht vielleicht auch von der Weboberfläche des NAS. Aber bei QNAP kenne ich mich nicht aus.

Moin,

mir ist da noch etwas im Kopf hängen geblieben, da muss eine Environmentvariable auf true gesetzt werden.
Ich glaube, dass das debug war, dann bleibt er wohl nach dem Fehler stehen.

Configure environment:

    DEBUG (optional) Set true to get extended logging messages on container startup

VG
Bernd

[Hank 0]

Danke schonmal für die Hilfe! Ich werde das morgen mit einem Kollegen versuchen und dann berichten.

[Hank 0]

Moin,

das mit dem DBUG hat schon mal geklappt!

Wir haben uns einmal die Adapter anzeigen lassen und den Admin Adapter einmal neu installiert aber das hat nichts gebracht.

iobroker controller daemon started. PID: 418
root@iobroker-debug:/opt/iobroker# iobroker list instances
Server Cannot start inMem-objects on port 9001: Failed to lock DB file "/opt/iobroker/iobroker-data/objects.jsonl"!
root@iobroker-debug:/opt/iobroker# iobroker list adapter
Unknown type: adapter
root@iobroker-debug:/opt/iobroker# iobroker list adapters
system.adapter.admin : admin - v6.10.1
system.adapter.backitup : backitup - v2.5.4
system.adapter.bosesoundtouch : bosesoundtouch - v0.10.3
system.adapter.discovery : discovery - v3.0.3
system.adapter.fritzdect : fritzdect - v2.2.6
system.adapter.history : history - v2.2.0
system.adapter.influxdb : influxdb - v3.2.0
system.adapter.iot : iot - v1.11.9
system.adapter.kostal-piko-ba : kostal-piko-ba - v3.0.6
system.adapter.modbus : modbus - v5.0.11
system.adapter.mqtt : mqtt - v4.0.7
system.adapter.node-red : node-red - v4.0.3
system.adapter.onkyo : onkyo - v2.1.2
system.adapter.openknx : openknx - v0.2.5
system.adapter.ping : ping - v1.5.3
system.adapter.shelly : shelly - v6.4.1
system.adapter.sourceanalytix : sourceanalytix - v0.4.14
system.adapter.tr-064 : tr-064 - v4.2.16
system.adapter.vaillant : vaillant - v0.2.1
system.adapter.vis : vis - v1.4.15
system.adapter.web : web - v6.1.2

[Thomas Braun]

@hank-0

Dann schau per

iob diag

danach.

[Ein ehemaliger Benutzer]

@hank-0 sagte in ioBroker: Docker Bootschleife:

das mit dem DBUG hat schon mal geklappt!

Moin,

tust Du uns den Gefallen, Deine Texte in Code Tags </> zu verpacken, dann liest es sich besser :)

@hank-0 sagte in ioBroker: Docker Bootschleife:

Server Cannot start inMem-objects on port 9001: Failed to lock DB file "/opt/iobroker/iobroker-data/objects.jsonl"!

Dann hast Du da ein Fehler, Du kannst nicht auf die objects.jsonl Datenbank zugreifen, weil sie vielleicht noch durch einen anderen Prozess geblockt ist. Hast Du den Container komplett neu gestartet?

@hank-0 sagte in ioBroker: Docker Bootschleife:

----- Version Information -----
----- image: v7.1.2 -----
----- build: 2022-11-12T20:56:04+00:00 -----

Ist das wirklich ein so altes Image, kann es sein, dass Du versucht hast, node.js von Hand upzudaten?
Aber mach erst einmal das, was @Thomas-Braun möchte, dann schauen wir weiter!

VG
Bernd

[Hank 0]

@thomas-braun said in ioBroker: Docker Bootschleife:

@hank-0
Dann schau per
iob diag

danach.

Was genau soll ich machen? Nochmal den Admin Adapter löschen?

@dp20eic said in ioBroker: Docker Bootschleife:

Dann hast Du da ein Fehler, Du kannst nicht auf die objects.jsonl Datenbank zugreifen, weil sie vielleicht noch durch einen anderen Prozess geblockt ist. Hast Du den Container komplett neu gestartet?

Ich habe den alten Container exportiert und dann abgeschaltet. Dann den exportierten neu importiert, um die Debug variable zu setzen. Somit sollte eigentlich niemand auf irgendwas zugreifen!?

Und ja, das ist ein altes Image von damals, als ich mit den ersten Versuchen angefangen habe. Wenn Updates gemacht wurden, dann nur über die ioBroker GUI.

[Ein ehemaliger Benutzer]

@hank-0 sagte in ioBroker: Docker Bootschleife:

Was genau soll ich machen? Nochmal den Admin Adapter löschen?

Moin,

dich auf den Rechner per ssh, putty, Konsole der QNAP, oder vergleichbarem einwählen/aufschalten/verbinden, dann auf der Kommandozeile, das Ausführen

# iob diag

Kann aber auch sein, dass das wegen, dem kommenden, siehe nächste Zeile(n)

@hank-0 sagte in ioBroker: Docker Bootschleife:

Und ja, das ist ein altes Image von damals, als ich mit den ersten Versuchen angefangen habe. Wenn Updates gemacht wurden, dann nur über die ioBroker GUI.

Ja, aber irgendwann passt dann der Unterbau, sprich Docker Image, nicht mit dem Oberbau, sprich ioBroker zusammen.

VG
Bernd

[Hank 0]

Hey, ich habe einfach mal iob diag und dann iobroker fix eingegeben und jetzt läuft wieder alles :)
Danke!

Edit: Ich habe jetzt Backitup eingerichtet, dass er in einem separaten Ordner auf der NAS ein Backup anlegt. Das ist jetzt 8mb groß? Dachte da kommt mehr bei raus!?

[Thomas Braun]

@hank-0 sagte in ioBroker: Docker Bootschleife:

Das ist jetzt 8mb groß? Dachte da kommt mehr bei raus!?

Kommt drauf an, was da alles mit gesichert wird. Aber 8MB ist keine ungewöhnliche Größe.

[Hank 0]

Eigentlich nutze ich mit ioBroker nur NodeRed, um mein KNX zu steuern und demnächst meine PV abzufragen und zu visualisieren.

[OliverIO]

@hank-0 sagte in ioBroker: Docker Bootschleife:

Dies ist auch der einzige Container der so blöd angelegt ist

buanet hat für die entsprechenden verzeichnisse entsprechende volumes definiert. wenn du diese volumes allerdings nicht auf einen pfad auf deiner festplatte mappst, dann liegen die daten nun ein einem separaten bereich von docker. daher, die sind erstmal nicht wirklich verloren, aber halt schwer zu erreichen.

die debug variable habt ihr ja gefunden
zusätzlich könnte man noch in das iobroker log schauen ob da etwas drin steht
so wie in der fehlermeldung drin steht, könnte man den neuen container einfach mal clean erzeugen, so das iobroker erst mal läuft und dann danach per backitup die sicherung wieder einspielen

[Ein ehemaliger Benutzer]

@hank-0 sagte in ioBroker: Docker Bootschleife:

Hey, ich habe einfach mal iob diag und dann iobroker fix eingegeben und jetzt läuft wieder alles
Danke!

Moin,

eine Vermutung, Du hast händisch versucht, im Docker, etwas auf einen neueren Stand zu bringen, dass man so nicht macht, wie sagt @OliverIO immer Docker Container sind Wegwerfprodukte und NodeJS, oder andere Betriebssystemkomponenten werden immer über das Docker Image ausgetauscht, einzig ioBroker geht wie gewohnt, oder über das Maintenence Verfahren von Buanet.

Das iob fix hat da eventuell nur die Rechte wieder gerade gezogen, die durch händische Aktionen verbogen wurden.

VG
Bernd