Neuer Installer und neuer Fixer: übersichtliche Oberfläche und `iob docker`

[Feuersturm]

@infinity Hi, ein paar mehr Infos wären sehr hilfreich:

• iob diag ausführen und hier bereitstellen
• Tritt das Problem immer zur gleichen Zeit auf?
• Laufen automatische Backups zu dem Zeitpunkt im ioBroker? (Backitup Adapter)
• Wird ggf. ein Skript getriggert, welches einen Fehler hat. Du könntest z.B. einmal die javascript Instanz komplett abschalten und schauen ob das Problem weiter auftritt
• Welche weiteren Anwendungen laufen in deinem Container/VM neben ioBroker?

[MartinP]

512 MB Swap und 4 GB RAM.

Hast Du schon versucht, mehr Swap zuzuweisen?

[infinity]

@Feuersturm sagte:

@infinity Hi, ein paar mehr Infos wären sehr hilfreich:

• iob diag ausführen und hier bereitstellen
• Tritt das Problem immer zur gleichen Zeit auf?
• Laufen automatische Backups zu dem Zeitpunkt im ioBroker? (Backitup Adapter)
• Wird ggf. ein Skript getriggert, welches einen Fehler hat. Du könntest z.B. einmal die javascript Instanz komplett abschalten und schauen ob das Problem weiter auftritt
• Welche weiteren Anwendungen laufen in deinem Container/VM neben ioBroker?

Nein das Problem tritt zu unterschiedlichen Zeiten auf.
Ein Backup macht er da auch nicht.
Besondere Scripte laufen auch nicht, es laufen die die immer laufen.
Eigentlich lief das alles immer stabil, jetzt war das binnen 5 Tagen 2 mal passiert.

[infinity]

@MartinP sagte:

512 MB Swap und 4 GB RAM.

Hast Du schon versucht, mehr Swap zuzuweisen?

Hab mal den Swap verdoppelt, vielleicht hilft das ja.
Ist halt schwer zu sagen, weil ich das nicht nachvollziehen kann wann das passiert.

[Feuersturm]

@infinity wurden Updates in den letzten Tagen durchgeführt?

[mickym]

Ich hab keine Lösung - aber mein Stand bleibt auch bei nodejs 22 und iob 7.0.7 eingefroren. Alle Updates haben den Effekt, dass mein System spätestens nach 2-3 Tagen stehen bleibt. Ohne Fehlermeldung - einfach tot und nur ein Kaltstart hilft weiter. Ich plane das gesamte System umzubauen - aber seit diesen Updates ist der Wurm drin. Es gibt wie gesagt keine Fehlermeldung - das System bleibt einfach stehen.

[paul53]

@infinity [sagte: 2 Screenshots in Proxmox

Kannst du dem Container mehr RAM zuweisen oder hat das Board nur 4 GB?
Wie viele Instanzen sind aktiv?

[maloross]

Ich habe ähnliche Probleme (Proxmox auf Lenovo Think Center) und teste aktuell, ob die Energiesparfunktion der Netzwerkkarte der Verursacher ist. Die habe ich vor 4 Tagen deaktiviert und bis jetzt noch keine Ausfälle.
Vielleicht auch ein möglicher Ansatz bei dir.

[infinity]

Hmm, ein Lenovo Think Centre habe ich auch.
Beschreibe mal genau wie du was gemacht hast.
Aber komischerweise lief es ja ewig völlig problemlos.

Am Ram sollte es nicht liegen, glaube ich jedenfalls.
Hier mal 2 Screenshots vom normalen Betrieb:

[maloross]

Auch bei mir gab es wenig bis keine Auffälligkeiten, ausser dieser Zeile im Protokoll:
e1000e: Detected Hardware Unit Hang, lt. einem Forum Hinweis auf diese Energiesparfunktion.

Achtung: Der Linux-Gerätename der physischen Netzwerkkarte kann abweichen, bei mir lautet der Name nic0.

Auf der Shell folgendes:

1. Prüfung aktueller Status

ethtool --show-eee nic0

2. Temporäres Deaktivieren

ethtool --set-eee nic0 eee off

3. Für dauerhaftes Deaktivieren ist eine Dienstdatei erforderlich

nano /etc/systemd/system/disable-eee.service

Mit diesem Inhalt

[Unit]
Description=Disable Energy Efficient Ethernet
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool --set-eee nic0 eee off
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Dienst aktivieren und starten

systemctl enable --now disable-eee.service

[Shadowhunter23]

@maloross

Dafür gibt auch das hier:
https://community-scripts.org/scripts/nic-offloading-fix

[infinity]

Auf meinen Screenshots im ersten Post ist auch ein seltsamer Ausschlag bei Network Traffic und ab genau dann ging ja nix mehr.

[Bluefox]

@infinity Laut den Grafiken läuft bis ca. 19:20 alles normal mit etwa 2,6 GB. Dann geht der RAM innerhalb kurzer Zeit auf 4 GB, der Swap ist voll und Disk-Read bleibt dauerhaft hoch. Dann lagert der Container nur noch aus, deshalb die hohe CPU und deshalb geht nichts mehr. Irgendein Prozess (meist eine Adapter-Instanz oder ein Skript) frisst also plötzlich Speicher. Den müssen wir finden.

Bitte schick zuerst den Teil vom ioBroker-Log um diese Zeit:

grep -E "2026-10-29 19:(0|1|2)" /opt/iobroker/log/iobroker.2026-10-29.log | grep -iE "error|warn|memory|heap|terminated|restart" | tail -n 100

Auf dem Proxmox-Host (nicht im Container), ob der OOM-Killer zugeschlagen hat:

dmesg -T | grep -iE "oom|killed process"

Und beim nächsten Hänger, falls du noch auf die Konsole kommst (Proxmox > Console), vor dem Neustart:

free -m
ps aux --sort=-rss | head -n 15

Dann sehen wir direkt, welcher Prozess so viel Speicher braucht. Wenn es wieder läuft, poste bitte auch noch die Ausgabe von iob diag.

Eine bekannte Ursache für solche Sprünge ist das Update der Repositories. Das braucht unter Node 24 kurzzeitig mehrere hundert MB. Schau mit iob repo, ob außer dem aktiven Repo noch andere eingetragen sind (z. B. beta). Was du nicht brauchst, kannst du mit iob repo del beta löschen.

Unabhängig davon sind 512 MB Swap bei 4 GB RAM knapp. Wenn der Host genug Speicher hat, gib dem Container mehr RAM, z. B. 6 GB. Damit ist die Ursache aber nicht weg.