<![CDATA[Iobroker startet einfach neu]]>Hallo zusammen,
in meiner Abwesenheit ist es in den letzten Tagen immer kurz vor 09:58 Uhr zu einem größeren Fehler auf meinem Raspberry Pi gekommen.
Laut den Meldungen, die ich erhalten habe, scheint mein Pi 5 neu gestartet zu haben oder zumindest haben sich die meisten Adapter neu gestartet.
Bis auf mehrere Updates wüsste ich nicht, was sich gegenüber vorher geändert hat.
Kann jemand von euch eventuell anhand der Logs den Auslöser erkennen?

EDIT:
Einges musste ich kürzen.

]]>https://forum.iobroker.net/topic/85631/iobroker-startet-einfach-neuRSS for NodeSun, 25 Oct 2026 11:09:27 GMTWed, 21 Oct 2026 11:16:51 GMT60<![CDATA[Reply to Iobroker startet einfach neu on Sun, 25 Oct 2026 10:19:35 GMT]]>@tourer4778

Kurz zu deiner Rückfrage in #25 – mein „abwarten“ in #24 war zu knapp.

Gemeint war: Erst wenn das Journal wirklich persistent auf der SSD landet, lohnt es sich, auf den nächsten ungeplanten Neustart zu warten und mit journalctl -b -1 zu schauen, was direkt davor passiert ist (Freeze/Watchdog/Strom vs. geplanter Reboot). Solange fast alles nur unter /run/log/journal (RAM) liegt, sind neuere Einträge nach einem Reboot wieder weg – passt zu „heute Morgen noch aktueller, jetzt fehlt wieder was“, besonders nach deinem manuellen Neustart.

In #25 steht der Knackpunkt im journald-Log:

Assignment outside of section. Ignoring.

Dann wird Storage=persistent nicht angewendet (Zeile außerhalb von [Journal], oft ganz oben in journald.conf). In #23 war /etc/systemd/journald.conf.d/ leer – das Drop-in fehlt dort noch.

Vorschlag:

sudo nano /etc/systemd/journald.conf

Oben kein Storage=…; unter [Journal] reichen die Defaults (#Storage=auto).

sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/persistent.conf

Inhalt:

[Journal]
Storage=persistent

sudo systemctl restart systemd-journald
logger "Journal-Test $(date)"
sudo journalctl -u systemd-journald -n 25 --no-pager
sudo ls -la /var/log/journal/*/
sudo journalctl --disk-usage

Erfolg: Meldungen wie „System Journal (/var/log/journal/...)“ / „flushing to /var/log/journal“, Dateien mit heutigem Datum, kein „Assignment outside of section“.

sudo touch /var/log/journal/.write-test && sudo rm /var/log/journal/.write-test

Wenn das steht – beim nächsten ungeplanten Neustart bitte:

sudo journalctl -b -1 -n 200 --no-pager

Speicher (#25): ~6,3 GB belegt, js-controller ~676 MB – zweite Baustelle; Journal zuerst, sonst beim nächsten Crash wieder keine Belege.

mit KI aus dem Thread zusammengefasst

]]>https://forum.iobroker.net/post/1360488https://forum.iobroker.net/post/1360488Sun, 25 Oct 2026 10:19:35 GMT<![CDATA[Reply to Iobroker startet einfach neu on Sun, 25 Oct 2026 10:05:39 GMT]]>

@crunchip sagte:

Dann mal abwarten, bis zum nächsten ungewollten Neustart

Verstehe das nicht, heute morgen standen da noch aktuellere logs drin.
grafik.jpeg

]]>https://forum.iobroker.net/post/1360481https://forum.iobroker.net/post/1360481Sun, 25 Oct 2026 10:05:39 GMT<![CDATA[Reply to Iobroker startet einfach neu on Sun, 25 Oct 2026 04:35:32 GMT]]>Dann mal abwarten, bis zum nächsten ungewollten Neustart

]]>https://forum.iobroker.net/post/1360436https://forum.iobroker.net/post/1360436Sun, 25 Oct 2026 04:35:32 GMT<![CDATA[Reply to Iobroker startet einfach neu on Sun, 25 Oct 2026 03:04:58 GMT]]>

@crunchip sagte:
Kurz: mkdir / restart / flush hast du gemacht, aber unter /var/log/journal/<machine-id>/ ist weiter nur Stand Mai

Ja 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.
grafik.jpeg

iob repo del latest ✓
del vis-material-webfont ✓
systeminfo-Polls nicht so aggressiv ✓

]]>https://forum.iobroker.net/post/1360435https://forum.iobroker.net/post/1360435Sun, 25 Oct 2026 03:04:58 GMT<![CDATA[Reply to Iobroker startet einfach neu on Sat, 24 Oct 2026 13:35:56 GMT]]>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.

]]>https://forum.iobroker.net/post/1360359https://forum.iobroker.net/post/1360359Sat, 24 Oct 2026 13:35:56 GMT<![CDATA[Reply to Iobroker startet einfach neu on Sat, 24 Oct 2026 11:42:20 GMT]]>@tourer4778

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-usage

Persistent erzwingen (nicht nur #Storage=auto):

sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/persistent.conf

Inhalt der Datei:

[Journal]
Storage=persistent

Dann:

sudo systemctl restart systemd-journald
sudo journalctl --flush
logger "Journal-Test $(date)"
ls -la /var/log/journal/*/
sudo journalctl --disk-usage

Erfolg = 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-pager

Danach 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).log

Vor dem nächsten „Hänger“ (wenn möglich):

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

Entlastung (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

]]>https://forum.iobroker.net/post/1360345https://forum.iobroker.net/post/1360345Sat, 24 Oct 2026 11:42:20 GMT<![CDATA[Reply to Iobroker startet einfach neu on Sat, 24 Oct 2026 10:37:18 GMT]]>

Leider keine Datei von heute
grafik.jpeg

]]>https://forum.iobroker.net/post/1360333https://forum.iobroker.net/post/1360333Sat, 24 Oct 2026 10:37:18 GMT<![CDATA[Reply to Iobroker startet einfach neu on Sat, 24 Oct 2026 09:34:01 GMT]]>@tourer4778

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 5

Danach 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

]]>https://forum.iobroker.net/post/1360318https://forum.iobroker.net/post/1360318Sat, 24 Oct 2026 09:34:01 GMT<![CDATA[Reply to Iobroker startet einfach neu on Sat, 24 Oct 2026 08:29:45 GMT]]>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.

]]>https://forum.iobroker.net/post/1360298https://forum.iobroker.net/post/1360298Sat, 24 Oct 2026 08:29:45 GMT<![CDATA[Reply to Iobroker startet einfach neu on Fri, 23 Oct 2026 06:50:30 GMT]]>

@tourer4778 sagte:

st jetzt schon fast voll nach fast 3h

nein

@tourer4778 sagte:

available
2092

]]>https://forum.iobroker.net/post/1360146https://forum.iobroker.net/post/1360146Fri, 23 Oct 2026 06:50:30 GMT<![CDATA[Reply to Iobroker startet einfach neu on Fri, 23 Oct 2026 06:44:49 GMT]]>

Der Speicher ist jetzt schon fast voll nach fast 3h

]]>https://forum.iobroker.net/post/1360143https://forum.iobroker.net/post/1360143Fri, 23 Oct 2026 06:44:49 GMT<![CDATA[Reply to Iobroker startet einfach neu on Fri, 23 Oct 2026 05:27:57 GMT]]>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.jsonl ist mit 61 MB recht groß. Prüf bitte, welche Repos eingetragen sind:

iob repo

Alles, was nicht unter "Active repo(s)" steht (meist beta), kannst du löschen, z. B.:

iob repo del beta

Der 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 fail

Wenn der Flush klappt, sehen wir beim nächsten Mal mit sudo journalctl -b -1 endlich, 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 -m und ps aux --sort=-rss | head -n 5. Dann sehen wir, wie stark der Speicher beim Refresh ansteigt.

]]>https://forum.iobroker.net/post/1360136https://forum.iobroker.net/post/1360136Fri, 23 Oct 2026 05:27:57 GMT<![CDATA[Reply to Iobroker startet einfach neu on Fri, 23 Oct 2026 04:51:33 GMT]]>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

]]>https://forum.iobroker.net/post/1360133https://forum.iobroker.net/post/1360133Fri, 23 Oct 2026 04:51:33 GMT<![CDATA[Reply to Iobroker startet einfach neu on Thu, 22 Oct 2026 19:25:11 GMT]]>@tourer4778 Die Befehle musst du einzeln eingeben, das Komma gehört nicht dazu. Also nacheinander:

sudo crontab -l
systemctl list-timers
sudo journalctl -k -b | grep -iE "oom|watchdog|panic|voltage"

#Storage=auto ist der Standard. Dann sollte das Journal eigentlich auf der SSD landen, weil /var/log/journal existiert. Trotzdem fehlen alle Boots seit Mai. Bitte schick noch:

cat /etc/machine-id
ls -la /var/log/journal /run/log/journal

Der Name des Verzeichnisses unter /var/log/journal muss genau der machine-id entsprechen. Wenn sich die ID im Mai geändert hat (z. B. durch ein Update oder ein zurückgespieltes Image), schreibt journald nur noch in den RAM.

Wichtiger ist jetzt, was "lief nicht richtig" heute genau heißt. War der Admin nicht erreichbar, haben einzelne Adapter nicht reagiert oder war der ganze Pi träge? Im zweiten diag war der Swap komplett voll (199 von 200 MB). Das spricht dafür, dass der Speicher über die Zeit vollläuft. Dann friert der Pi irgendwann ein oder startet neu. Beim nächsten Mal, bevor du neu startest:

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

Und schick bitte den Teil vom ioBroker-Log von heute, bevor du neu gestartet hast:

grep -iE "error|warn|memory|heap" /opt/iobroker/log/iobroker.2026-10-22.log | tail -n 100

Dann sehen wir, welcher Prozess bzw. Adapter den Speicher frisst.

]]>https://forum.iobroker.net/post/1360115https://forum.iobroker.net/post/1360115Thu, 22 Oct 2026 19:25:11 GMT<![CDATA[Reply to Iobroker startet einfach neu on Thu, 22 Oct 2026 14:05:05 GMT]]>

@Bluefox sagte:

Heute ist er nicht neu gestartet, aber das System lief auch nicht richtig. Ich habe es dann selbst mal neu gestartet und danach lief alles wieder.
#Storage=auto

crontab -l; sudo crontab -l, systemctl list-timers

pi@raspberrypi:~ $ grep
Usage: grep [OPTION]... PATTERNS [FILE]...
Try 'grep --help' for more information.
]]>https://forum.iobroker.net/post/1360060https://forum.iobroker.net/post/1360060Thu, 22 Oct 2026 14:05:05 GMT<![CDATA[Reply to Iobroker startet einfach neu on Thu, 22 Oct 2026 07:30:11 GMT]]>@tourer4778 Da fällt mir etwas auf: Laut --list-boots endet der letzte gespeicherte Boot am 24. Mai. Die Neustarts der letzten Tage stehen also gar nicht im Journal. Seit Mai wird das Journal offenbar nicht mehr auf der SSD gespeichert, sondern nur im RAM, und geht bei jedem Neustart verloren. Deshalb sehen wir nicht, was um 09:55 passiert ist. Bestätigt wird der Reboot aber trotzdem: timesyncd stellt die Uhr beim Booten auf den zuletzt gespeicherten Zeitpunkt 09:55:12.

Prüf das bitte:

ls /run/log/journal /var/log/journal
grep -ri storage /etc/systemd/journald.conf /etc/systemd/journald.conf.d/ 2>/dev/null

Steht dort Storage=volatile, nimm das raus oder setz es auf persistent. Danach:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Dann ist beim nächsten Neustart mit sudo journalctl -b -1 -n 150 --no-pager zu sehen, wie der letzte Boot geendet hat.

Bis dahin hilft das ioBroker-Log, denn das liegt auf der SSD:

grep -B 40 "js-controller starting" /opt/iobroker/log/iobroker.2026-10-21.log

Steht vor dem Start ein sauberes "terminating" der Instanzen, wurde der Pi ordentlich heruntergefahren. Hört das Log einfach mitten drin auf, ist ihm der Strom weggegangen oder er ist hart abgestürzt.

Die Ausgaben von crontab -l; sudo crontab -l, systemctl list-timers und dem grep auf oom/watchdog fehlen mir noch, oder sie sind im Spoiler abgeschnitten.

Zum Speicher: Der Swap ist mit 200 MB sehr klein und deshalb schnell voll. Verfügbar sind aber noch rund 2 GB, das ist unkritisch. Wenn du heute nach 09:57 noch einmal iob diag machst, sehen wir auch, ob es heute wieder passiert ist.

]]>https://forum.iobroker.net/post/1360014https://forum.iobroker.net/post/1360014Thu, 22 Oct 2026 07:30:11 GMT<![CDATA[Reply to Iobroker startet einfach neu on Thu, 22 Oct 2026 04:19:10 GMT]]>iob diag
Speicher ist schon voller geworden, bzw. sehr voll.

]]>https://forum.iobroker.net/post/1359994https://forum.iobroker.net/post/1359994Thu, 22 Oct 2026 04:19:10 GMT<![CDATA[Reply to Iobroker startet einfach neu on Thu, 22 Oct 2026 03:51:36 GMT]]>

@Bluefox sagte:

Netzteil hat sogar glaube 5A.

]]>https://forum.iobroker.net/post/1359993https://forum.iobroker.net/post/1359993Thu, 22 Oct 2026 03:51:36 GMT<![CDATA[Reply to Iobroker startet einfach neu on Wed, 21 Oct 2026 14:10:36 GMT]]>@tourer4778 Am RAM liegt es eher nicht. Laut diag hast du noch über 2 GB frei, und der Swap wird gar nicht benutzt. Wenn der Speicher doch mal voll läuft, beendet der Kernel (OOM-Killer) einzelne Prozesse, z. B. eine Adapter-Instanz. Den ganzen Pi startet er dabei nicht neu. Außerdem würde das nicht jeden Tag zur gleichen Minute passieren.

Auffällig ist aber, dass journalctl -b -1 Einträge vom 24. Mai zeigt. Entweder wurden die Boots seitdem nicht ins Journal geschrieben, oder sie sind wegen der falschen Uhrzeit direkt nach dem Booten durcheinander geraten. Bitte schick mal:

journalctl --list-boots | tail -n 10
sudo journalctl --since "2026-10-21 09:30" --until "2026-10-21 10:05" --no-pager
sudo journalctl -k | grep -iE "oom|watchdog|panic|voltage"
crontab -l; sudo crontab -l
systemctl list-timers

Wichtig ist der Zeitraum direkt vor 09:57. Steht dort ein sauberes Herunterfahren ("Stopping ...", "Reached target Reboot"), hat etwas den Neustart ausgelöst. Bricht das Log einfach ab, ist der Pi hart ausgegangen. Dann tippe ich auf eine geschaltete Steckdose, das Netzteil oder einen Watchdog.

Schau bitte auch in deinen Skripten nach schedule, exec( oder reboot und nach Schaltzeiten um 09:55 bis 10:00.

Ein Netzteil muss aber auch passend sein. Mindestens 3A

]]>https://forum.iobroker.net/post/1359887https://forum.iobroker.net/post/1359887Wed, 21 Oct 2026 14:10:36 GMT<![CDATA[Reply to Iobroker startet einfach neu on Wed, 21 Oct 2026 13:40:30 GMT]]>

@Bluefox sagte:

Kann es auchh mit dem Ram zu tun haben?

]]>https://forum.iobroker.net/post/1359881https://forum.iobroker.net/post/1359881Wed, 21 Oct 2026 13:40:30 GMT<![CDATA[Reply to Iobroker startet einfach neu on Wed, 21 Oct 2026 13:28:51 GMT]]>@tourer4778 Das diag bestätigt es: Um 15:18 läuft das System seit 5:21, also seit etwa 09:57. Laut dmesg wurde die SSD um 09:56:50 eingehängt. Das war ein echter Reboot vom Pi und nicht nur ein Neustart vom js-controller.

"No throttling issues detected" sagt hier leider wenig, weil die Flags beim Booten zurückgesetzt werden. Eine Unterspannung kurz vor dem Reboot würde man da nicht sehen.

Wichtig ist, was direkt vor dem Neustart passiert ist. Dein Journal wird dauerhaft gespeichert, also bitte:

last -x reboot shutdown | head
sudo journalctl -b -1 -n 150 --no-pager
crontab -l; sudo crontab -l
systemctl list-timers

Wenn am Ende von journalctl -b -1 sauber "Stopping ..." und "Reached target Reboot" steht, hat jemand bzw. etwas den Reboot ausgelöst (cron, Timer, Skript). Hört das Log einfach mitten drin auf, war es ein Stromausfall, Watchdog oder Absturz. Prüf auch, ob ein Skript um 09:57 eine Steckdose schaltet, an der der Pi oder sein Netzteil hängt.

]]>https://forum.iobroker.net/post/1359876https://forum.iobroker.net/post/1359876Wed, 21 Oct 2026 13:28:51 GMT<![CDATA[Reply to Iobroker startet einfach neu on Wed, 21 Oct 2026 13:31:40 GMT]]>

@Bluefox sagte:

Eine Störung der Stromversorgung glaube ich eher nicht, da diese dann vermutlich unregelmäßiger auftreten würde. Ich vermute eventuell einen Speicherüberlauf, wobei dieser dann vermutlich auch nicht fast immer um 10 Uhr auftreten würde.

Wie kann ich feststellen, ob ein Skript die Ursache dafür ist? Ich bin mir nicht bewusst, dort Änderungen vorgenommen zu haben.

]]>https://forum.iobroker.net/post/1359875https://forum.iobroker.net/post/1359875Wed, 21 Oct 2026 13:31:40 GMT<![CDATA[Reply to Iobroker startet einfach neu on Wed, 21 Oct 2026 13:22:22 GMT]]>

@Thomas-Braun sagte:
Gib mal die Ausgabe von
iob diag

]]>https://forum.iobroker.net/post/1359871https://forum.iobroker.net/post/1359871Wed, 21 Oct 2026 13:22:22 GMT<![CDATA[Reply to Iobroker startet einfach neu on Wed, 21 Oct 2026 11:35:08 GMT]]>@tourer4778 Im ioBroker-Log sieht man nur, dass der js-controller frisch startet. Warum das passiert, steht da nicht drin. Auffällig ist der Sprung von 09:00:39 auf 09:57:26, mitten im Start. Das sieht so aus, als hätte der Pi nach dem Booten zuerst eine alte Uhrzeit und bekommt die richtige erst später per NTP. Dann wäre das ein echter Reboot gegen 09:57. Die vielen ADAPTER_ALREADY_RUNNING sind wahrscheinlich nur eine Folge davon und nicht die Ursache.

Weil es jeden Tag zur gleichen Uhrzeit passiert, tippe ich eher auf etwas Zeitgesteuertes oder auf die Stromversorgung. Schick bitte die Ausgabe von:

last -x reboot | head
vcgencmd get_throttled
sudo journalctl -b -1 -n 100 --no-pager
crontab -l; sudo crontab -l
systemctl list-timers

journalctl -b -1 zeigt das Ende vom vorherigen Boot, also was direkt vor dem Neustart passiert ist. Schau auch nach, ob ein Skript im javascript-Adapter um diese Zeit etwas schaltet oder einen Reboot auslöst.

Nebenbei: vis-material-webfont gibt es nicht im Repository, deshalb scheitert die Installation bei jedem Start. Wenn du den Adapter nicht mehr brauchst, entferne ihn:

iob del vis-material-webfont
]]>https://forum.iobroker.net/post/1359857https://forum.iobroker.net/post/1359857Wed, 21 Oct 2026 11:35:08 GMT