Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Thomas Braun]

@Karacho

Setz die LogLevel runter. Oder debuggst du den gerade? Vermutlich nicht.

[OliverIO]

sagte in Automatidcher Reboot iobroker täglich:

den admin adapter kann ich mir nicht erklären

ich habe mal geschaut, was der admin adapter aktiv im hintergrund den so macht.
er horcht auf alle objectchanges und auf ein paar wenige stateChange Ereignisse. stateChange betrtifft aber nur Sentry.
Daher ist der Speicheranstieg des Admin-Adapters nur dadurch erklärbar, das zu diesem Zeitpunkt viele Datenpunktobjekte geändert werden (also nicht States, sondern das eigentliche Objekt)

Leider gab es noch keine Antwort, ob der Browser mit dem Admin-Adapter offen war. wenn bspw das im Browser geöffnet war und sehr viel passiert, könnte es auch auf den Backend-Anteil des Adapters betreffen. Ist aber eher unwahrscheinlich, da der Frontend-Anteil der Adapter sich direkt vom jscontroller-Prozess informieren lassen.

Evtl hilft das bei der Fehlersuche

[Homoran]

@Karacho sagte in Automatidcher Reboot iobroker täglich:

Neustarts sind unregelmässig:

so unregelmäßig sind die gar nicht.
entweder

• Alle 24h +2min
  oder ggf.
• x h:m nach Sonnenuntergang

@OliverIO sagte in Automatidcher Reboot iobroker täglich:

top bringt bei so etwas nur bedingt, da es eine augenblicksdarstellung ist

klar, aber nach ständigem Volllaufen des RAM über 3 Tage sähe der SWAP anders aus.

[OliverIO]

@Homoran sagte in Automatidcher Reboot iobroker täglich:

klar, aber nach ständigem Volllaufen des RAM über 3 Tage sähe der SWAP anders aus.

Wenn der RAM nur temporär vollläuft und die Prozesse dann beendet werden, wird auch der Swap mit der Zeit wieder aufgeräumt bzw freigegeben.

[mcm1957]

@OliverIO sagte in Automatidcher Reboot iobroker täglich:

sagte in Automatidcher Reboot iobroker täglich:

den admin adapter kann ich mir nicht erklären

ich habe mal geschaut, was der admin adapter aktiv im hintergrund den so macht.
er horcht auf alle objectchanges und auf ein paar wenige stateChange Ereignisse. stateChange betrtifft aber nur Sentry.
Daher ist der Speicheranstieg des Admin-Adapters nur dadurch erklärbar, das zu diesem Zeitpunkt viele Datenpunktobjekte geändert werden (also nicht States, sondern das eigentliche Objekt)

Admin holt sich auch alle 24h die aktuellen NEWS und legt diese ggF als Notifications ab.
Weiters aktualisisert admin im Intervall "config.autoUpdate" Stunden (default 24h) die Repositorydaten.

Der Aktivitätspeak kann auch dadurch ausgelöst werden.

Admin sollte diese Aktionen mit loglevel DEBUG loggen.

[mcm1957]

Und - habs hier vielleicht überlesen - findet überhaupt ein RAM Überlauf statt? Wenn Linux da Prozesse killt, dann sollte das doch in System-Logs zu finden sein.

Und steht denn auch gar nichts im ioBroker-Log wenn der js-controller restartet?

EDIT:
@thomas-braun
Wäre es bei Speicherknappheit nicht wahrscheinlich dass Linux irgendwelche Prozesse killt - und nicht jedesmal den js-controller aussucht? Wenn Linux da den Adapter xyz zuerst killt würde ja der js-controller mal überleben und das auch im ioBroker log loggen dass der Adapter gecrashed ist.

[Thomas Braun]

@mcm1957 sagte in Automatidcher Reboot iobroker täglich:

Wäre es bei Speicherknappheit nicht wahrscheinlich dass Linux irgendwelche Prozesse killt - und nicht jedesmal den js-controller aussucht?

Wie genau das 'out-of-memory'-Management funktioniert weiß ich gar nicht. Der sollte aber Einträge im journal hinterlassen. Muss man mal reinschauen.

[Karacho]

Von Info auf warn gestellt

[Karacho]

@OliverIO
Admin Adapter war nicht im Browser offen

[mcm1957]

@karacho
hast du hier schon mal das ioBroker Log rund um den js-controlelr neustart gepostet?
Also die letzten Minuten VOR und die NACH dem Restart des js-controllers?
Wenn nicht könntest du das mal tun.

[Thomas Braun]

@Karacho

Schau dir das jounal an. Am besten nur den entsprechenden Zeitraum +- 15 Minuten.
Geht so:

journalctl --since "2015-06-26 23:15:00" --until "2015-06-26 23:20:00"

[Karacho]

journalct:

pi@iobroker20:~ $ journalctl --since "2025-12-21 22:04:00" --until "2025-12-21 22:34:00"
Dec 21 22:16:18 iobroker20 bash[128091]: Send diag info: {"uuid":"34fe198a-1e58-0ca4-805f-5ba8bf90f8c2","language":"de","country":"Germany","hosts":[{"version":"7.0.7","platform":"Javascript/Node.js","type":"linux"}]>
Dec 21 22:16:19 iobroker20 sudo[224819]: iobroker : PWD=/ ; USER=root ; COMMAND=/usr/bin/apt -v
Dec 21 22:16:19 iobroker20 sudo[224819]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1001)
Dec 21 22:16:19 iobroker20 sudo[224819]: pam_unix(sudo:session): session closed for user root
Dec 21 22:16:20 iobroker20 sudo[224824]: iobroker : PWD=/ ; USER=root ; COMMAND=/usr/bin/apt list --upgradeable
Dec 21 22:16:20 iobroker20 sudo[224824]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1001)
Dec 21 22:16:21 iobroker20 sudo[224824]: pam_unix(sudo:session): session closed for user root
Dec 21 22:16:57 iobroker20 bash[128091]: Send diag info: {"uuid":"34fe198a-1e58-0ca4-805f-5ba8bf90f8c2","language":"de","country":"Germany","hosts":[{"version":"7.0.7","platform":"Javascript/Node.js","type":"linux"}]>
Dec 21 22:17:01 iobroker20 CRON[224858]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Dec 21 22:17:01 iobroker20 CRON[224859]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Dec 21 22:17:01 iobroker20 CRON[224858]: pam_unix(cron:session): session closed for user root
Dec 21 22:17:05 iobroker20 sudo[224871]: iobroker : PWD=/ ; USER=root ; COMMAND=/usr/bin/apt -v
Dec 21 22:17:05 iobroker20 sudo[224871]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1001)
Dec 21 22:17:05 iobroker20 sudo[224871]: pam_unix(sudo:session): session closed for user root
Dec 21 22:17:05 iobroker20 sudo[224876]: iobroker : PWD=/ ; USER=root ; COMMAND=/usr/bin/apt list --upgradeable
Dec 21 22:17:05 iobroker20 sudo[224876]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1001)
Dec 21 22:17:07 iobroker20 sudo[224876]: pam_unix(sudo:session): session closed for user root
Dec 21 22:17:13 iobroker20 kernel: io.hmip.0 invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
Dec 21 22:17:13 iobroker20 kernel: CPU: 1 UID: 1001 PID: 128556 Comm: io.hmip.0 Tainted: G         C         6.12.47+rpt-rpi-v8 #1  Debian 1:6.12.47-1+rpt1~bookworm
Dec 21 22:17:13 iobroker20 kernel: Tainted: [C]=CRAP
Dec 21 22:17:13 iobroker20 kernel: Hardware name: Raspberry Pi 4 Model B Rev 1.2 (DT)
Dec 21 22:17:13 iobroker20 kernel: Call trace:
Dec 21 22:17:13 iobroker20 kernel:  dump_backtrace+0xa0/0x100
Dec 21 22:17:13 iobroker20 kernel:  show_stack+0x20/0x38
Dec 21 22:17:13 iobroker20 kernel:  dump_stack_lvl+0x78/0x90
Dec 21 22:17:13 iobroker20 kernel:  dump_stack+0x18/0x28
Dec 21 22:17:13 iobroker20 kernel:  dump_header+0x44/0x1a8
Dec 21 22:17:13 iobroker20 kernel:  oom_kill_process+0x140/0x368
Dec 21 22:17:13 iobroker20 kernel:  out_of_memory+0xec/0x588
Dec 21 22:17:13 iobroker20 kernel:  __alloc_pages_noprof+0xaa0/0xdc8
Dec 21 22:17:13 iobroker20 kernel:  alloc_pages_mpol_noprof+0x60/0x158
Dec 21 22:17:13 iobroker20 kernel:  alloc_pages_noprof+0x58/0x98
Dec 21 22:17:13 iobroker20 kernel:  folio_alloc_noprof+0x1c/0x38
Dec 21 22:17:13 iobroker20 kernel:  filemap_alloc_folio_noprof+0x13c/0x158
Dec 21 22:17:13 iobroker20 kernel:  __filemap_get_folio+0x140/0x310
Dec 21 22:17:13 iobroker20 kernel:  filemap_fault+0x534/0x970
Dec 21 22:17:13 iobroker20 kernel:  __do_fault+0x44/0x148
Dec 21 22:17:13 iobroker20 kernel:  __handle_mm_fault+0x628/0xc58
Dec 21 22:17:13 iobroker20 kernel:  handle_mm_fault+0x188/0x2a0
Dec 21 22:17:13 iobroker20 kernel:  do_page_fault+0x104/0x548
Dec 21 22:17:13 iobroker20 kernel:  do_translation_fault+0xa4/0xc8
Dec 21 22:17:13 iobroker20 kernel:  do_mem_abort+0x4c/0xa8
Dec 21 22:17:13 iobroker20 kernel:  el0_ia+0x50/0xe8
Dec 21 22:17:13 iobroker20 kernel:  el0t_64_sync_handler+0xd0/0x130
Dec 21 22:17:13 iobroker20 kernel:  el0t_64_sync+0x190/0x198
Dec 21 22:17:13 iobroker20 kernel: Mem-Info:
Dec 21 22:17:13 iobroker20 kernel: active_anon:234589 inactive_anon:679128 isolated_anon:0
                                    active_file:51 inactive_file:142 isolated_file:0
                                    unevictable:0 dirty:114 writeback:0
                                    slab_reclaimable:22441 slab_unreclaimable:9482
                                    mapped:793 shmem:26 pagetables:5124
                                    sec_pagetables:0 bounce:0
                                    kernel_misc_reclaimable:0
                                    free:4724 free_pcp:1189 free_cma:512
Dec 21 22:17:13 iobroker20 kernel: Node 0 active_anon:390732kB inactive_anon:1378928kB active_file:0kB inactive_file:460kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:1568kB dirty:216kB writeback:0kB>
Dec 21 22:17:13 iobroker20 kernel: Node 1 active_anon:452660kB inactive_anon:1432548kB active_file:0kB inactive_file:308kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:1604kB dirty:240kB writeback:0kB>
lines 1-56

[Thomas Braun]

@Karacho

Da läuft die Ermittlung der Updates und die Übermittlung der Telemetrie an ioBroker.
Das ganze löst dann den oom-killer aus:

Dec 21 22:17:13 iobroker20 kernel: io.hmip.0 invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0

[Karacho]

Also definitiv RAM Problem?
Falls ja, wie kann ich weiter "runterschrauben"?

[Thomas Braun]

@Karacho sagte in Automatidcher Reboot iobroker täglich:

Falls ja, wie kann ich weiter "runterschrauben"?

Eher schwierig. Du hast da jetzt 30 Instanzen laufen, über den Daumen gepeilt benötigt jede Instanz um die 100MB RAM. Kommt noch das Basissystem hinzu und dann bist du im normalen Betrieb 'unter der Decke'. Kommen dann solche Dinge wie gerade gesehen hinzu muss ein aus Sicht des OS entbehrlicher Prozess über die Klinge springen.

Edit: Du kannst natürlich die Übermittlung der ioBroker-Statistik mal untersagen. Wo man die OS-Updates abstellt weiß ich aber gerade nicht.

[mcm1957]

Du könntest überlegen den compact mode zu aktivieren. Spart memory kann aber dazu führen dass ein Fehler in einem Adapter nicht nur dirsen crashen lässt. Obvdrr Adapter xx im compact mode stabil läuft musst du testen.

Technisch läuft normalerweise jede Adapterinstanz inbeinem eigenen Prozess. Im compact Mode laufen alle oder einige Instanzenbgemeindamnin einem Prozess.

Generell würd ich dir aber zu einem grösseren System raten

[crunchip]

@Karacho sagte in Automatidcher Reboot iobroker täglich:

Von Info auf warn gestellt

@Karacho sagte in Automatidcher Reboot iobroker täglich:

debug: daswetter

debug ausschalten war gemeint

@Karacho sagte in Automatidcher Reboot iobroker täglich:

• system.adapter.info.0

der ist doch eh "abgekündigt", wofür genau benötigst du den noch bzw was fehlt dir, was iobroker nicht schon von Haus aus bietet?

@mcm1957 sagte in Automatidcher Reboot iobroker täglich:

aber zu einem grösseren System raten

oder ggf wenn zufällig noch was brauchbares rumliegt, einen slave aufsetzen