Iobroker startet einfach neu
-
Heute Morgen vor 6 Uhr war er nicht mehr zu erreichen. Um 05:58 ist er dann wieder zu erreichen gewesen. Diesmal habe ich auch den Lüfter vom PI gehört, wenn er neu startet.
Gestern kamen einige Werte von meinem Wechselrichter (OPENDTU) nicht an, daher hatte ich ihn neu gestartet.
Ich denke, es liegt am Speicher mit dem Neustart. Das mit dem einfrieren und neustarten könnte gut sein.Mit dem freien Speicher wird jetzt nicht brauchbar sein, wenn er gerade erst neu gestartet ist.
Hier noch das Log von heute vor dem Neustart. Seltsam ist, das er von 05:52 auf 05:00 springt und dann wieder auf 05:56
-
Man kann ewig hier suchen und am Ende rausfinden, dass doch RAM schuld ist.
Ich empfehle dir die Auslastung/Funktionsumfang zu reduzieren oder einfach auf die neue Hardware mit mehr RAM umzuziehen.Beim Repository-Refresh braucht der js-controller kurzzeitig deutlich mehr Speicher. Dazu gibt es ein offenes Issue: https://github.com/ioBroker/ioBroker.js-controller/issues/3427. Bei dir hat der js-controller direkt nach dem Start schon 670 MB, und deine
objects.jsonlist mit 61 MB recht groß. Prüf bitte, welche Repos eingetragen sind:iob repoAlles, was nicht unter "Active repo(s)" steht (meist
beta), kannst du löschen, z. B.:iob repo del betaDer Swap mit 200 MB ist außerdem sehr knapp. Wenn er voll ist, gibt es keinen Puffer mehr für solche Spitzen. Ich würde ihn vergrößern.
Zum Journal: Die machine-id stimmt, trotzdem landet alles nur in
/run/log/journal. Schick bitte noch:systemctl status systemd-journal-flush.service --no-pager sudo journalctl --flush sudo journalctl --verify 2>&1 | grep -i failWenn der Flush klappt, sehen wir beim nächsten Mal mit
sudo journalctl -b -1endlich, was direkt vor dem Neustart los war.Wenn du möchtest, mach außerdem morgen früh vor 05:50 und noch mal danach
free -mundps aux --sort=-rss | head -n 5. Dann sehen wir, wie stark der Speicher beim Refresh ansteigt. -
Der Speicher ist jetzt schon fast voll nach fast 3h
-
Der Speicher ist jetzt schon fast voll nach fast 3h
-
Update:
Ich hatte gestern den SWAP auf 2048MB erhöht.
Heute kurz nach 8 ist er wieder neu gestartet.sudo journalctl -b -1 hängt zum schluss recht lang. Und das Datum ist von gestern.
-
Ich hab mir die Spoiler nochmal in Ruhe angeschaut – kurz zum Journal-Thema, weil das leicht missverständlich ist:
Was du schon gemacht hast (#16):
- systemd-journal-flush.service = OK
- journalctl --flush und --verify ohne Fail
- beta-Repo ist weg
Das ist gut, ersetzt aber nicht die komplette Reparatur aus Bluefox’ Post #11.
Was die Spoiler trotzdem zeigen:
- journalctl --list-boots: Boot 0 ist Oktober, Boot -1 endet noch 24. Mai
- journalctl -b -1 liefert weiter Mai (#5/#7/#18), nicht „was gestern vor dem Neustart war“
- ls -la: unter /var/log/journal/... letzte Änderung Mai 24, unter /run/log/journal/... Oktober → aktuell landet viel nur im RAM-Journal, das beim Reboot weg ist
- #Storage=auto allein hilft nicht, wenn trotzdem nichts Neues auf der SSD ankommt
Damit ist „Ursache beim nächsten Absturz sehen“ noch nicht erledigt. Flush war ein Teilschritt. Der Test ist erst bestanden, wenn nach einem ungeplanten Neustart -b -1 den gestrigen Boot zeigt.
Bitte noch (fehlte in den Spoilern bisher):
grep -ri '^Storage' /etc/systemd/journald.conf /etc/systemd/journald.conf.d/ 2>/dev/null ls -la /var/log/journal /run/log/journal sudo mkdir -p /var/log/journal sudo systemd-tmpfiles --create --prefix /var/log/journal sudo systemctl restart systemd-journald sudo journalctl --flush journalctl --list-boots | tail -n 5Danach einmal rebooten und prüfen, ob unter /var/log/journal/<machine-id>/ heutige Dateien liegen (nicht nur Mai).
Nach dem nächsten ungeplanten Neustart (nicht nach manuellem Reboot):
sudo journalctl -b -1 -n 200 --no-pager grep -B 50 "js-controller starting" /opt/iobroker/log/iobroker.$(date +%Y-%m-%d).log- Ende mit Stopping / Reached target Reboot → geplanter Reboot (Skript/Timer/Befehl)
- bricht mitten ab → eher Freeze/Watchdog/Strom (passt zu eurem Bild)
Parallel weiter sinnvoll:
- iob repo del latest
- iob del vis-material-webfont
- RAM/Swap vor dem Hänger loggen (free -m, ps aux --sort=-rss | head), nicht nur direkt nach dem Boot
Wenn du die Ausgaben von grep Storage und list-boots nach dem journald-Neustart postest, sieht man, ob Schritt 1 jetzt wirklich steht.
Hinweis: Befehle einzeln ausführen – kein Komma zwischen mehreren Commands in einer Zeile (war bei euch schon mal passiert).
mit KI aus dem Thread zusammengefasst
-
Leider keine Datei von heute
-
Kurz: mkdir / restart / flush hast du gemacht, aber unter /var/log/journal/<machine-id>/ ist weiter nur Stand Mai 24 – „keine Datei von heute“ heißt: journald schreibt praktisch nur nach /run/log/journal (RAM), das beim Reboot weg ist. list-boots zeigt zwar Boot 0 (Oktober), die alten Boots -1 … -4 sind noch Mai – deshalb bringt journalctl -b -1 für „gestern vor dem Crash“ noch nichts.
Bitte als Nächstes (Ausgaben gern als Spoiler):
sudo systemd-analyze cat-config systemd/journald cat /etc/systemd/journald.conf ls -la /etc/systemd/journald.conf.d/ 2>/dev/null df -h /var sudo journalctl --disk-usagePersistent erzwingen (nicht nur #Storage=auto):
sudo mkdir -p /etc/systemd/journald.conf.d sudo nano /etc/systemd/journald.conf.d/persistent.confInhalt der Datei:
[Journal] Storage=persistentDann:
sudo systemctl restart systemd-journald sudo journalctl --flush logger "Journal-Test $(date)" ls -la /var/log/journal/*/ sudo journalctl --disk-usageErfolg = unter /var/log/journal/... Dateien mit heutigem Datum, disk-usage steigt.
Wenn trotzdem nichts Neues kommt:
mount | grep ' / ' touch /var/log/journal/.write-test && rm /var/log/journal/.write-test sudo journalctl -u systemd-journald -n 50 --no-pagerDanach einmal rebooten und nochmal:
journalctl --list-boots | tail -n 3 ls -la /var/log/journal/*/Erst wenn das klappt, lohnt sich nach dem nächsten ungeplanten Neustart:
sudo journalctl -b -1 -n 200 --no-pager
Parallel zur Ursache (geht auch ohne Journal):
In deinem Log vom 24.10. um ca. 08:12 fallen viele terminated due to SIGKILL auf (web, javascript, echarts, iot, alexa2). Das spricht oft für OOM-Killer oder harten Abbruch beim Neustart – nicht für ein sauberes shutdown/reboot.
Nach dem nächsten ungeplanten Neustart:
grep -B 80 "js-controller starting" /opt/iobroker/log/iobroker.$(date +%Y-%m-%d).log | tail -n 90 grep -i SIGKILL /opt/iobroker/log/iobroker.$(date +%Y-%m-%d).logVor dem nächsten „Hänger“ (wenn möglich):
free -m ps aux --sort=-rss | head -n 10Entlastung (weiter sinnvoll): iob repo del latest, iob del vis-material-webfont, systeminfo-Polls nicht so aggressiv (*:/1), vw-connect (>5000 Objekte), history aufräumen, zweite javascript-Instanz prüfen. Swap 2 GB ist gut, ersetzt aber keine zu viele laufende Adapter.
Hinweis: Befehle bitte einzeln in der Shell ausführen (jede Zeile getrennt), nicht alles in eine Zeile kopieren – dann passieren Tippfehler wie journalls seltener.
mit KI aus dem Thread zusammengefasst
-
ich habe auch aktuell irgendwie Neustart Probleme.
Ich habe das ganze mit Claude (in der free Version) durchgeackert.
Bei mir gab es auch keine Logs mehr seit Dez. 2025 auf dem Pi, von 2026 nur den aktuellen der gerade aufgezeichnet wurde.
Claude hat das erkannt und repariert.Ich kann nur sagen, dass ich das super finde, wie einem hier im Forum geholfen wird, mit den ganzen ssh Befehlen und wie ihr euch Zeit nehmt um die Ausgaben zu analysieren.
Wirklich Hut ab.
Hier würde ich aber empfehlen, das ganze auch mal mit Claude zu machen/probieren. Claude gibt die Befehle, die dann mit Strg c/v in die Konsole und die Konsolenausgabe dann wieder per Strg c/v zurück zu Claude. So kann man das flüssig alles machen ohne zu warten bis das Forum reagiert.Nach den ganzen Analysen von Claude könnte es bei mir an folgenden liegen:
-USB-Adapter mit UAS-Treiber,
-ioBroker selbst,
-der js-controller (belegt 1,2 GB)
-Netzteil (geringe Wahrscheinlichkeit, ist aber jetzt ausgetauscht)Claude wartet jetzt auf den nächsten Absturz und dann geht die Suche weiter.
Logs stehen ja jetzt wieder zur Verfügung. -
Kurz: mkdir / restart / flush hast du gemacht, aber unter /var/log/journal/<machine-id>/ ist weiter nur Stand Mai 24 – „keine Datei von heute“ heißt: journald schreibt praktisch nur nach /run/log/journal (RAM), das beim Reboot weg ist. list-boots zeigt zwar Boot 0 (Oktober), die alten Boots -1 … -4 sind noch Mai – deshalb bringt journalctl -b -1 für „gestern vor dem Crash“ noch nichts.
Bitte als Nächstes (Ausgaben gern als Spoiler):
sudo systemd-analyze cat-config systemd/journald cat /etc/systemd/journald.conf ls -la /etc/systemd/journald.conf.d/ 2>/dev/null df -h /var sudo journalctl --disk-usagePersistent erzwingen (nicht nur #Storage=auto):
sudo mkdir -p /etc/systemd/journald.conf.d sudo nano /etc/systemd/journald.conf.d/persistent.confInhalt der Datei:
[Journal] Storage=persistentDann:
sudo systemctl restart systemd-journald sudo journalctl --flush logger "Journal-Test $(date)" ls -la /var/log/journal/*/ sudo journalctl --disk-usageErfolg = unter /var/log/journal/... Dateien mit heutigem Datum, disk-usage steigt.
Wenn trotzdem nichts Neues kommt:
mount | grep ' / ' touch /var/log/journal/.write-test && rm /var/log/journal/.write-test sudo journalctl -u systemd-journald -n 50 --no-pagerDanach einmal rebooten und nochmal:
journalctl --list-boots | tail -n 3 ls -la /var/log/journal/*/Erst wenn das klappt, lohnt sich nach dem nächsten ungeplanten Neustart:
sudo journalctl -b -1 -n 200 --no-pager
Parallel zur Ursache (geht auch ohne Journal):
In deinem Log vom 24.10. um ca. 08:12 fallen viele terminated due to SIGKILL auf (web, javascript, echarts, iot, alexa2). Das spricht oft für OOM-Killer oder harten Abbruch beim Neustart – nicht für ein sauberes shutdown/reboot.
Nach dem nächsten ungeplanten Neustart:
grep -B 80 "js-controller starting" /opt/iobroker/log/iobroker.$(date +%Y-%m-%d).log | tail -n 90 grep -i SIGKILL /opt/iobroker/log/iobroker.$(date +%Y-%m-%d).logVor dem nächsten „Hänger“ (wenn möglich):
free -m ps aux --sort=-rss | head -n 10Entlastung (weiter sinnvoll): iob repo del latest, iob del vis-material-webfont, systeminfo-Polls nicht so aggressiv (*:/1), vw-connect (>5000 Objekte), history aufräumen, zweite javascript-Instanz prüfen. Swap 2 GB ist gut, ersetzt aber keine zu viele laufende Adapter.
Hinweis: Befehle bitte einzeln in der Shell ausführen (jede Zeile getrennt), nicht alles in eine Zeile kopieren – dann passieren Tippfehler wie journalls seltener.
mit KI aus dem Thread zusammengefasst
@crunchip sagte:
Kurz: mkdir / restart / flush hast du gemacht, aber unter /var/log/journal/<machine-id>/ ist weiter nur Stand MaiJa hatte ich.
Hier erstmal mein Speicher (Vor Neustart)
Storage=persistent habe ich gemacht
Im Log steht was unter heutigem Datum :-), auch wenn jetzt alles andere weg ist.
Ich hatte aber auch einen neustart gemacht.
iob repo del latest ✓
del vis-material-webfont ✓
systeminfo-Polls nicht so aggressiv ✓ -
Dann mal abwarten, bis zum nächsten ungewollten Neustart
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden265
Online33.1k
Benutzer84.1k
Themen1.4m
Beiträge