NEWS
Automatidcher Reboot iobroker täglich
-
Neustarts sind unregelmässig:
21.12. - 22:19Uhr
20.12. - 22:17Uhr
19.12. - 22:15Uhr
Es staret jedes mal der iobroker neu als wenn ich eineniobroker restartdurchführe
@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.
- Alle 24h +2min
-
@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.
@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.
- Alle 24h +2min
-
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
@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.
-
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. -
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.@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.
-
Neustarts sind unregelmässig:
21.12. - 22:19Uhr
20.12. - 22:17Uhr
19.12. - 22:15Uhr
Es staret jedes mal der iobroker neu als wenn ich eineniobroker restartdurchführe
-
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
-
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" -
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 -
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-56Da 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 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.
-
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
-
@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