Load average am Anschlag -> Neustart
-
Nach gut 48h ist es wieder passiertIch hatte virher noch Daten gesammelt, und auch input und output counts vom History geloggt.
Auch da keine wirkliche Korrelation zu immer häufiger werdenden höheren load Werten gesehen.Dann stiegen die load maxima wieder über 10 bis 25. (Vorher eigentlich immer nur knapp über 4),
Top zeigte nichts verwertbares an
Lediglich der mögliche Hinweis auf historydann musste ich aus dem Haus.
Als ich wiederkam ist die uptime nur noch 0.1 Tag
15:41 ist iobroker wieder hochgefahren!Ich hab immer noch keinerlei blassen Schimmer was da los ist.
EDIT:
Hab seitenweise EPIPE, ECONNRESET 9000 und 9001 im log!Ist das etwa dasselbe hier?
https://forum.iobroker.net/topic/85231/unregelmäßig-unmotivierter-neustart-aller-instanzen/Steht was in
dmesg -Tzu den Zeiten drin?
Alternativ schau mal perjournalctlwas da so geloggt wird. Details hier:
Linux-Werkzeugkasten:
https://forum.iobroker.net/topic/42952/der-kleine-iobroker-linux-werkzeugkasten
NodeJS Fixer Skript:
https://forum.iobroker.net/topic/68035/iob-node-fix-skript
iob_diag: curl -sLf -o diag.sh https://iobroker.net/diag.sh && bash diag.sh -
Kann man die verdächtigen Module ggfs. einfach mal für einen Test disablen. Scheint ja erstmal nichts zu betreffen, was die Steuerung der Heimautomatisierung angeht...
-
Steht was in
dmesg -Tzu den Zeiten drin?
Alternativ schau mal perjournalctlwas da so geloggt wird. Details hier:
dmesg -T
Das was ich gesucht hatte ist drin:
[Thu Aug 27 15:40:15 2026] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=iobroker.js-con,pid=533421,uid=1001 [Thu Aug 27 15:40:15 2026] Out of memory: Killed process 533421 (iobroker.js-con) total-vm:12096752kB, anon-rss:150480kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:28000kB oom_score_adj:0 [Thu Aug 27 15:40:17 2026] oom_reaper: reaped process 533421 (iobroker.js-con), now anon-rss:768kB, file-rss:0kB, shmem-rss:0kB puh@BrokerRaspi:~ $journalctl
Alles?
lines 5575-5627/5656 100%
Oder nur das rote
Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:18 GOTO="alsa_restore_std" has no matching label, ignoring. Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:18 The line has no effect any more, dropping. Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:22 GOTO="alsa_restore_std" has no matching label, ignoring. Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:22 The line has no effect any more, dropping. . . . Aug 25 14:14:07 BrokerRaspi systemd[1]: Reached target remote-fs-pre.target - Preparation for Remote File Systems. Aug 25 14:14:07 BrokerRaspi systemd[1]: Reached target remote-fs.target - Remote File Systems. Aug 25 14:14:07 BrokerRaspi blkmapd[766]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory Aug 25 14:14:07 BrokerRaspi systemd[1]: Started nfs-blkmap.service - pNFS block layout mapping daemon. . . . Aug 27 15:27:33 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=iobroker.js-con,pid=1191,uid=1001 Aug 27 15:27:33 BrokerRaspi kernel: Out of memory: Killed process 1191 (iobroker.js-con) total-vm:12474624kB, anon-rss:335120kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:32976kB oom_score_adj:0 Aug 27 15:28:34 BrokerRaspi kernel: cron invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0 . . . Aug 27 15:28:36 BrokerRaspi kernel: [ 531576] 1001 531576 6381 6 0 6 0 98304 0 0 node Aug 27 15:28:36 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=io.javascript.1,pid=1474,uid=1001 Aug 27 15:28:36 BrokerRaspi kernel: Out of memory: Killed process 1474 (io.javascript.1) total-vm:12129424kB, anon-rss:205536kB, file-rss:256kB, shmem-rss:0kB, UID:1001 pgtables:22080kB oom_score_adj:0 Aug 27 15:28:36 BrokerRaspi systemd[1]: iobroker.service: Main process exited, code=killed, status=9/KILL . . . . Aug 27 15:40:16 BrokerRaspi kernel: [ 538774] 1001 538774 6712 12 0 12 0 98304 0 0 node Aug 27 15:40:16 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=iobroker.js-con,pid=533421,uid=1001 Aug 27 15:40:16 BrokerRaspi kernel: Out of memory: Killed process 533421 (iobroker.js-con) total-vm:12096752kB, anon-rss:150480kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:28000kB oom_score_adj:0 Aug 27 15:40:16 BrokerRaspi kernel: oom_reaper: reaped process 533421 (iobroker.js-con), now anon-rss:768kB, file-rss:0kB, shmem-rss:0kB . . .kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
dmesg -T
Das was ich gesucht hatte ist drin:
[Thu Aug 27 15:40:15 2026] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=iobroker.js-con,pid=533421,uid=1001 [Thu Aug 27 15:40:15 2026] Out of memory: Killed process 533421 (iobroker.js-con) total-vm:12096752kB, anon-rss:150480kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:28000kB oom_score_adj:0 [Thu Aug 27 15:40:17 2026] oom_reaper: reaped process 533421 (iobroker.js-con), now anon-rss:768kB, file-rss:0kB, shmem-rss:0kB puh@BrokerRaspi:~ $journalctl
Alles?
lines 5575-5627/5656 100%
Oder nur das rote
Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:18 GOTO="alsa_restore_std" has no matching label, ignoring. Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:18 The line has no effect any more, dropping. Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:22 GOTO="alsa_restore_std" has no matching label, ignoring. Aug 25 14:14:05 BrokerRaspi systemd-udevd[381]: /usr/lib/udev/rules.d/90-alsa-restore.rules:22 The line has no effect any more, dropping. . . . Aug 25 14:14:07 BrokerRaspi systemd[1]: Reached target remote-fs-pre.target - Preparation for Remote File Systems. Aug 25 14:14:07 BrokerRaspi systemd[1]: Reached target remote-fs.target - Remote File Systems. Aug 25 14:14:07 BrokerRaspi blkmapd[766]: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No such file or directory Aug 25 14:14:07 BrokerRaspi systemd[1]: Started nfs-blkmap.service - pNFS block layout mapping daemon. . . . Aug 27 15:27:33 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=iobroker.js-con,pid=1191,uid=1001 Aug 27 15:27:33 BrokerRaspi kernel: Out of memory: Killed process 1191 (iobroker.js-con) total-vm:12474624kB, anon-rss:335120kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:32976kB oom_score_adj:0 Aug 27 15:28:34 BrokerRaspi kernel: cron invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0 . . . Aug 27 15:28:36 BrokerRaspi kernel: [ 531576] 1001 531576 6381 6 0 6 0 98304 0 0 node Aug 27 15:28:36 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=io.javascript.1,pid=1474,uid=1001 Aug 27 15:28:36 BrokerRaspi kernel: Out of memory: Killed process 1474 (io.javascript.1) total-vm:12129424kB, anon-rss:205536kB, file-rss:256kB, shmem-rss:0kB, UID:1001 pgtables:22080kB oom_score_adj:0 Aug 27 15:28:36 BrokerRaspi systemd[1]: iobroker.service: Main process exited, code=killed, status=9/KILL . . . . Aug 27 15:40:16 BrokerRaspi kernel: [ 538774] 1001 538774 6712 12 0 12 0 98304 0 0 node Aug 27 15:40:16 BrokerRaspi kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-7,global_oom,task_memcg=/,task=iobroker.js-con,pid=533421,uid=1001 Aug 27 15:40:16 BrokerRaspi kernel: Out of memory: Killed process 533421 (iobroker.js-con) total-vm:12096752kB, anon-rss:150480kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:28000kB oom_score_adj:0 Aug 27 15:40:16 BrokerRaspi kernel: oom_reaper: reaped process 533421 (iobroker.js-con), now anon-rss:768kB, file-rss:0kB, shmem-rss:0kB . . .Alles?
Man kann das ganz wunderbar auf bestimmte Betrachtungszeiträume beschränken. Steht alles im Schnubbibuntu-Wiki drin, aus dem Kopf weiß ich die genaue Syntax auch nicht.
Linux-Werkzeugkasten:
https://forum.iobroker.net/topic/42952/der-kleine-iobroker-linux-werkzeugkasten
NodeJS Fixer Skript:
https://forum.iobroker.net/topic/68035/iob-node-fix-skript
iob_diag: curl -sLf -o diag.sh https://iobroker.net/diag.sh && bash diag.sh -
@Thomas-Braun Danke.
Such ich mir gerne nachher rausDie roten zeilen hab ich alle gezeigt
Dass es schlussendlich out of memory war, hab ich ja aus den charts vermutet, aber warum?
Hilft das letzte aus dem output
Aug 27 18:01:37 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Aug 27 18:02:41 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] Aug 27 18:03:51 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Aug 27 18:04:28 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] Aug 27 18:04:46 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Aug 27 18:05:11 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging]kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
Wer Speicher frisst, kann man sich auch anzeigen lassen...
Die Prozesse, sortiert von oben nach unten nach dem Speicherverbrauch.
Kann aber langweilig werden, wenn man davor sitzen muss ...
Wenn es Vorzeichen gibt, kann man sich ja über iobroker alarmieren lassen, wenn es spannend wird ...Linux Console
top -o %MEM- echtzeit-Anzeige
top -o %MEM -n 1- ein Durchlauf, kann man auch in Datei umleiten lassen (ggfs mit linux-control sogar von iobroker starten lassen)top - 18:36:03 up 1 day, 2:03, 0 users, load average: 3.43, 3.57, 3.73 Tasks: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie %Cpu(s): 27.5 us, 25.5 sy, 0.0 ni, 43.8 id, 0.5 wa, 0.0 hi, 2.7 si, 0.0 st MiB Mem : 6144.0 total, 2979.2 free, 2562.4 used, 602.5 buff/cache MiB Swap: 6144.0 total, 4956.9 free, 1187.1 used. 3581.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 410 iobroker 20 0 12.1g 247056 29684 S 9.4 3.9 205:08.33 iobroker.js-con 354 grafana 20 0 2147780 216260 81568 S 2.6 3.4 36:43.40 grafana 106 influxdb 20 0 4706888 192716 31064 S 4.9 3.1 198:46.98 influxd 498 iobroker 20 0 22.0g 189992 42472 S 0.0 3.0 2:23.22 io.admin.0 522 iobroker 20 0 12.0g 181988 39140 S 2.9 2.9 96:19.18 io.influxdb.0 554 iobroker 20 0 12.0g 181164 41612 S 2.3 2.9 62:00.97 io.javascript.0 570 iobroker 20 0 11.8g 145544 39192 S 2.3 2.3 44:19.36 io.javascript.1 601 iobroker 20 0 11.8g 124428 42428 S 0.3 2.0 9:39.54 io.mqtt.0 590 iobroker 20 0 11.7g 121228 40660 S 0.0 1.9 1:43.94 io.mqtt-client. 571 iobroker 20 0 11.9g 117876 41844 S 0.0 1.9 6:32.65 io.backitup.0 639 iobroker 20 0 11.7g 117788 41660 S 2.9 1.9 61:25.18 io.sonoff.0 816 iobroker 20 0 11.7g 116152 41380 S 0.3 1.8 2:15.27 io.simple-api.0 670 iobroker 20 0 11.9g 115492 42396 S 0.0 1.8 8:11.39 io.tr-064.0 51 root 20 0 233784 115160 114676 S 0.0 1.8 0:20.48 systemd-journal 646 iobroker 20 0 11.9g 113644 42556 S 0.0 1.8 4:27.48 io.meross.0 837 iobroker 20 0 21.7g 105520 41872 S 0.0 1.7 2:36.18 io.linux-contro 723 iobroker 20 0 11.9g 103152 42328 S 0.0 1.6 2:31.00 io.hm-rpc.0 801 iobroker 20 0 11.8g 103052 42320 S 0.0 1.6 1:44.38 io.web.0 773 iobroker 20 0 11.7g 99972 42172 S 0.0 1.6 2:40.04 io.hm-rega.0 534 iobroker 20 0 11.7g 97704 41924 S 0.0 1.6 1:39.59 io.email.0 659 iobroker 20 0 11.7g 97036 41252 S 0.0 1.5 1:52.47 io.snmp.0 795 iobroker 20 0 11.8g 96892 42248 S 0.0 1.5 1:32.61 io.vis-2.0 722 iobroker 20 0 11.7g 96848 41132 S 0.0 1.5 1:30.10 io.discovery.0Intel(R) Celeron(R) CPU N3000 @1.04GHz 8G RAM 480G SSD * Virtualization : unprivileged lxc container on Proxmox * 6 GByte RAM für den iobroker Container * Remote-Access über Wireguard meiner Fritzbox
-
Nachtrag Bei meiner "top" - Version gibt es noch einem Parameter, den aber nicht alle bieten
top -o %MEM -n 1 --scale-task-mem=mDamit wird der Speicherbedarf in Megabyte ausgegeben...
Tasks: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie %Cpu(s): 17.4 us, 21.7 sy, 0.0 ni, 60.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 6144.0 total, 2991.9 free, 2563.1 used, 589.1 buff/cache MiB Swap: 6144.0 total, 4956.9 free, 1187.1 used. 3580.9 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 410 iobroker 20 0 12.1g 275.0m 29.0m S 0.0 4.5 206:46.87 iobroker.js-con 354 grafana 20 0 2097.7m 211.4m 79.7m S 0.0 3.4 37:01.41 grafana 498 iobroker 20 0 22.0g 185.5m 41.5m S 0.0 3.0 2:23.85 io.admin.0 106 influxdb 20 0 4596.6m 178.2m 30.3m S 0.0 2.9 200:17.88 influxd 522 iobroker 20 0 12.0g 171.6m 38.2m S 0.0 2.8 97:05.90 io.influxdb.0 554 iobroker 20 0 12.0g 160.4m 40.6m S 0.0 2.6 62:31.28 io.javascript.0 570 iobroker 20 0 11.8g 142.1m 38.3m S 0.0 2.3 44:40.54 io.javascript.1 601 iobroker 20 0 11.8g 121.5m 41.4m S 0.0 2.0 9:44.16 io.mqtt.0 590 iobroker 20 0 11.7g 118.5m 39.7m S 0.0 1.9 1:44.71 io.mqtt-client. 571 iobroker 20 0 11.9g 115.1m 40.9m S 0.0 1.9 6:33.21 io.backitup.0 639 iobroker 20 0 11.7g 114.4m 40.7m S 0.0 1.9 61:56.16 io.sonoff.0 816 iobroker 20 0 11.7g 113.4m 40.4m S 0.0 1.8 2:16.30 io.simple-api.0 51 root 20 0 228.3m 112.9m 112.4m S 0.0 1.8 0:20.61 systemd-journal 670 iobroker 20 0 11.9g 112.8m 41.4m S 0.0 1.8 8:14.95 io.tr-064.0 646 iobroker 20 0 11.9g 110.9m 41.6m S 8.3 1.8 4:29.42 io.meross.0 837 iobroker 20 0 21.7g 103.4m 40.9m S 0.0 1.7 2:37.33 io.linux-contro 723 iobroker 20 0 11.9g 100.8m 41.3m S 0.0 1.6 2:32.01 io.hm-rpc.0 801 iobroker 20 0 11.8g 100.6m 41.3m S 0.0 1.6 1:45.00 io.web.0 773 iobroker 20 0 11.7g 98.4m 41.2m S 0.0 1.6 2:41.13 io.hm-rega.0 659 iobroker 20 0 11.7g 94.8m 40.3m S 0.0 1.5 1:53.36 io.snmp.0 795 iobroker 20 0 11.8g 94.6m 41.3m S 0.0 1.5 1:33.15 io.vis-2.0 722 iobroker 20 0 11.7g 94.6m 40.2m S 0.0 1.5 1:30.81 io.discovery.0 534 iobroker 20 0 11.7g 93.6m 40.9m S 0.0 1.5 1:40.26 io.email.0 772 iobroker 20 0 11.7g 92.7m 40.3m S 0.0 1.5 3:50.66 io.ping.0 808 iobroker 20 0 11.1g 80.9m 33.4m S 0.0 1.3 13:48.18 io.reolink.0 710 iobroker 20 0 11.1g 80.3m 32.7m S 0.0 1.3 11:14.24 io.ems-esp.0 830 iobroker 20 0 11.1g 78.8m 33.4m S 0.0 1.3 13:31.45 io.reolink.1 822 iobroker 20 0 11.2g 77.5m 33.2m S 0.0 1.3 18:38.57 io.fb-checkpres 737 iobroker 20 0 11.1g 76.8m 33.1m S 0.0 1.3 2:45.78 io.fritzdect.0 793 iobroker 20 0 11.1g 74.6m 32.7m S 0.0 1.2 2:06.69 io.tradfri.0 716 iobroker 20 0 11.1g 74.2m 32.9m S 0.0 1.2 8:15.38 io.zigbee2mqtt. 640 iobroker 20 0 11.1g 73.3m 32.5m S 0.0 1.2 5:48.54 io.operating-ho 438 grafana 20 0 1259.6m 21.1m 14.9m S 0.0 0.3 0:05.54 gpx_grafana_inf 458 grafana 20 0 1269.8m 13.9m 8.3m S 0.0 0.2 0:05.69 gpx_grafana-lok 391 grafana 20 0 1265.2m 13.1m 8.5m S 0.0 0.2 0:04.94 gpx_grafana_ela 1 root 20 0 23.0m 11.5m 9.2m S 0.0 0.2 1:17.94 systemd 403 grafana 20 0 1254.5m 11.2m 10.0m S 0.0 0.2 0:00.37 gpx_dash_linux_ 101 root 20 0 18.7m 7.6m 6.9m S 0.0 0.1 0:12.04 systemd-logind 35315 postfix 20 0 43.5m 7.3m 6.6m S 0.0 0.1 0:00.02 pickup 329 postfix 20 0 43.5m 6.2m 6.1m S 0.0 0.1 0:00.16 qmgr martin@iobroker-test-sicher:~$ top -o %MEM -n 1 --scale-task-mem=m -
@Thomas-Braun Danke.
Such ich mir gerne nachher rausDie roten zeilen hab ich alle gezeigt
Dass es schlussendlich out of memory war, hab ich ja aus den charts vermutet, aber warum?
Hilft das letzte aus dem output
Aug 27 18:01:37 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Aug 27 18:02:41 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] Aug 27 18:03:51 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Aug 27 18:04:28 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] Aug 27 18:04:46 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => true [system.adapter.admin.0.logging] Aug 27 18:05:11 BrokerRaspi bash[539235]: ================================== > LOG REDIRECT system.adapter.admin.0 => false [system.adapter.admin.0.logging] -
Wer Speicher frisst, kann man sich auch anzeigen lassen...
Die Prozesse, sortiert von oben nach unten nach dem Speicherverbrauch.
Kann aber langweilig werden, wenn man davor sitzen muss ...
Wenn es Vorzeichen gibt, kann man sich ja über iobroker alarmieren lassen, wenn es spannend wird ...Linux Console
top -o %MEM- echtzeit-Anzeige
top -o %MEM -n 1- ein Durchlauf, kann man auch in Datei umleiten lassen (ggfs mit linux-control sogar von iobroker starten lassen)top - 18:36:03 up 1 day, 2:03, 0 users, load average: 3.43, 3.57, 3.73 Tasks: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie %Cpu(s): 27.5 us, 25.5 sy, 0.0 ni, 43.8 id, 0.5 wa, 0.0 hi, 2.7 si, 0.0 st MiB Mem : 6144.0 total, 2979.2 free, 2562.4 used, 602.5 buff/cache MiB Swap: 6144.0 total, 4956.9 free, 1187.1 used. 3581.6 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 410 iobroker 20 0 12.1g 247056 29684 S 9.4 3.9 205:08.33 iobroker.js-con 354 grafana 20 0 2147780 216260 81568 S 2.6 3.4 36:43.40 grafana 106 influxdb 20 0 4706888 192716 31064 S 4.9 3.1 198:46.98 influxd 498 iobroker 20 0 22.0g 189992 42472 S 0.0 3.0 2:23.22 io.admin.0 522 iobroker 20 0 12.0g 181988 39140 S 2.9 2.9 96:19.18 io.influxdb.0 554 iobroker 20 0 12.0g 181164 41612 S 2.3 2.9 62:00.97 io.javascript.0 570 iobroker 20 0 11.8g 145544 39192 S 2.3 2.3 44:19.36 io.javascript.1 601 iobroker 20 0 11.8g 124428 42428 S 0.3 2.0 9:39.54 io.mqtt.0 590 iobroker 20 0 11.7g 121228 40660 S 0.0 1.9 1:43.94 io.mqtt-client. 571 iobroker 20 0 11.9g 117876 41844 S 0.0 1.9 6:32.65 io.backitup.0 639 iobroker 20 0 11.7g 117788 41660 S 2.9 1.9 61:25.18 io.sonoff.0 816 iobroker 20 0 11.7g 116152 41380 S 0.3 1.8 2:15.27 io.simple-api.0 670 iobroker 20 0 11.9g 115492 42396 S 0.0 1.8 8:11.39 io.tr-064.0 51 root 20 0 233784 115160 114676 S 0.0 1.8 0:20.48 systemd-journal 646 iobroker 20 0 11.9g 113644 42556 S 0.0 1.8 4:27.48 io.meross.0 837 iobroker 20 0 21.7g 105520 41872 S 0.0 1.7 2:36.18 io.linux-contro 723 iobroker 20 0 11.9g 103152 42328 S 0.0 1.6 2:31.00 io.hm-rpc.0 801 iobroker 20 0 11.8g 103052 42320 S 0.0 1.6 1:44.38 io.web.0 773 iobroker 20 0 11.7g 99972 42172 S 0.0 1.6 2:40.04 io.hm-rega.0 534 iobroker 20 0 11.7g 97704 41924 S 0.0 1.6 1:39.59 io.email.0 659 iobroker 20 0 11.7g 97036 41252 S 0.0 1.5 1:52.47 io.snmp.0 795 iobroker 20 0 11.8g 96892 42248 S 0.0 1.5 1:32.61 io.vis-2.0 722 iobroker 20 0 11.7g 96848 41132 S 0.0 1.5 1:30.10 io.discovery.0 -
Leider ist der Controller heute nacht kurz nach Mitternacht wieder abgeschossen worden. (Sourceanalytix??)
Daraufhin hab ich heute morgen einiges probiert.Was mir dabei aufgefallen ist:
-
Seit dem vorigen kill reagierte der scaling governor deutlich langsamer
Die CPU-Frequenz lieb deutlich länger auf 2400MHz, was ich erst als gutes Zeichen gesehen hatte. -
die Werte unter system.host.xyz.load passen nicht wirklich zu load average 1min aus
̀top- sie wechseln viel zu schnell und stark, als dass es 1min floating average sein könnten
- der Wert ist auch deutlich höher
-
das Ansteigen der Load konnte ich (meistens 😞) reproduzieren durch
- zoomen in einem Flot chart
- arbeiten im admin an Instanzeneinstellungen
-
Wenn es zu (geregelten (0-4)) load Anstiegen kam, dauerten diese meistens ca. 30 Minuten
-
zusätzlich stieg der Speicherverbrauch im Heap des admins (leicht) an.
-
Ansonsten war weder die CPU Last noch der Speicher der Prozesse in top irgendwie auffällig.
Daraufhin habe ich mir angesehen ob ich einige Instanzen pausieren, oder unnötige Adapter deinstallieren könnte um die Ursache einzugrenzen.
-
simple api hatte ich mWn nie installiert, im Gegenteil ich hatte es nach dem Umzug bewusst deinstalliert, was zu einer deutlich niedrigeren load führte. Jetzt war es wieder da.
-
native web sockets war updatefähig, was ich gemacht habe. Auch hier hatte ich es nie installiert.
- hier habe ich eine -bisher nicht existierende- Instanz angelegt, was zu einem Portkonflikt führte, da 8084 bereits vergeben war, geändert auf 8087
Anschließend ein
iob upload allund ein rebootJetzt reagiert auch der governor wieder wie vorher und die anderen Werte im chart verhielten sich wie früher
Ab kurz nach 08:00
Den go-e Adapter hab ich jetzt deaktiviert.
Er war bei den zuletzt upgedateten dabei und wurde wegen restart loops schon mal abgeschaltet (muss kein Zusammenhang bestehen)kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
-
Hast du den PI5 in einem speziellen Gehäuse? Ich hatte meinen PI4 mal in ein Alu-Gehäuse gepckt und dann zeigte der die selben Sympthome.
Ro75.
SERVER = Beelink U59 16GB DDR4 RAM 512GB SSD, FB 7490, FritzDect 200+301+440, ConBee II, Zigbee Aqara Sensoren + NOUS A1Z, NOUS A1T, Philips Hue ** ioBroker, REDIS, influxdb2, Grafana, PiHole, Plex-Mediaserver, paperless-ngx (Docker), MariaDB + phpmyadmin *** VIS-Runtime = Intel NUC 8GB RAM 128GB SSD + 24" Touchscreen
-
Hast du den PI5 in einem speziellen Gehäuse? Ich hatte meinen PI4 mal in ein Alu-Gehäuse gepckt und dann zeigte der die selben Sympthome.
Ro75.
Hast du den PI5 in einem speziellen Gehäuse?
Ja, in einem Argon mit NVMe Zusatz.
https://www.welectron.com/Raspberry-Pi-5-8-GB-Argon-Neo-KitIch hatte meinen PI4 mal in ein Alu-Gehäuse gepckt und dann zeigte der die selben Sympthome.
die Symptome traten ja bereits vorher auf, als es noch auf einem anderen Pi5 lief, plötzlich auf, nachdem es dort ca. 2 Jahre problemlos in einem anderen Alu Gehäuse lief.
https://www.welectron.com/Raspberry-Pi-5-8-GB-Flirc-Kit -
Das erste hatte ich für einen PI4. Der lief 2 Jahre ohne Probleme. In das Gehäuse und dann fingen die Probleme an. Vielleicht kannst du den PI5 mal ohne dem Gehäuse laufen lassen. Mein PI5 für OMV läuft in einem Plastegehäuse - bisher ohne Probleme. Manchmal ist es sehr komisch.
Ro75.
SERVER = Beelink U59 16GB DDR4 RAM 512GB SSD, FB 7490, FritzDect 200+301+440, ConBee II, Zigbee Aqara Sensoren + NOUS A1Z, NOUS A1T, Philips Hue ** ioBroker, REDIS, influxdb2, Grafana, PiHole, Plex-Mediaserver, paperless-ngx (Docker), MariaDB + phpmyadmin *** VIS-Runtime = Intel NUC 8GB RAM 128GB SSD + 24" Touchscreen
-
Das erste hatte ich für einen PI4. Der lief 2 Jahre ohne Probleme. In das Gehäuse und dann fingen die Probleme an. Vielleicht kannst du den PI5 mal ohne dem Gehäuse laufen lassen. Mein PI5 für OMV läuft in einem Plastegehäuse - bisher ohne Probleme. Manchmal ist es sehr komisch.
Ro75.
-
Leider ist der Controller heute nacht kurz nach Mitternacht wieder abgeschossen worden. (Sourceanalytix??)
Daraufhin hab ich heute morgen einiges probiert.Was mir dabei aufgefallen ist:
-
Seit dem vorigen kill reagierte der scaling governor deutlich langsamer
Die CPU-Frequenz lieb deutlich länger auf 2400MHz, was ich erst als gutes Zeichen gesehen hatte. -
die Werte unter system.host.xyz.load passen nicht wirklich zu load average 1min aus
̀top- sie wechseln viel zu schnell und stark, als dass es 1min floating average sein könnten
- der Wert ist auch deutlich höher
-
das Ansteigen der Load konnte ich (meistens 😞) reproduzieren durch
- zoomen in einem Flot chart
- arbeiten im admin an Instanzeneinstellungen
-
Wenn es zu (geregelten (0-4)) load Anstiegen kam, dauerten diese meistens ca. 30 Minuten
-
zusätzlich stieg der Speicherverbrauch im Heap des admins (leicht) an.
-
Ansonsten war weder die CPU Last noch der Speicher der Prozesse in top irgendwie auffällig.
Daraufhin habe ich mir angesehen ob ich einige Instanzen pausieren, oder unnötige Adapter deinstallieren könnte um die Ursache einzugrenzen.
-
simple api hatte ich mWn nie installiert, im Gegenteil ich hatte es nach dem Umzug bewusst deinstalliert, was zu einer deutlich niedrigeren load führte. Jetzt war es wieder da.
-
native web sockets war updatefähig, was ich gemacht habe. Auch hier hatte ich es nie installiert.
- hier habe ich eine -bisher nicht existierende- Instanz angelegt, was zu einem Portkonflikt führte, da 8084 bereits vergeben war, geändert auf 8087
Anschließend ein
iob upload allund ein rebootJetzt reagiert auch der governor wieder wie vorher und die anderen Werte im chart verhielten sich wie früher
Ab kurz nach 08:00
Den go-e Adapter hab ich jetzt deaktiviert.
Er war bei den zuletzt upgedateten dabei und wurde wegen restart loops schon mal abgeschaltet (muss kein Zusammenhang bestehen)Hier auch so eine Nachricht zum abfragen der repos und dann Absturz
-
-
Hier auch so eine Nachricht zum abfragen der repos und dann Absturz
Hier auch so eine Nachricht zum abfragen der repos und dann Absturz
Sag ich doch 😉
Homoran sagte:
@oliverio
Ich hab da noch was gefunden2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated
Das kommt mir aber bekannt vor.
Und
Homoran sagte:
EDIT:
Hab seitenweise EPIPE, ECONNRESET 9000 und 9001 im log!Ist das etwa dasselbe hier?
https://forum.iobroker.net/topic/85231/unregelmäßig-unmotivierter-neustart-aller-instanzen/Aber auch da gibt es keinerlei greifbare Ergebnisse.
Vielleicht kannst du den PI5 mal ohne dem Gehäuse laufen lassen
Ganz abgesehen davon, dass die Probleme bereits im Flirc Gehäuse begannen, bin ich ja danach auf Argon umgestiegen, da dort die NVMe und ein geregelter Lüfter drin sind.
Wäre aber jetzt nicht normal, wenn möglicherweise ausgerechnet der Lüfter due Störungen verursacht bzw. verschlimmert
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
Hier auch so eine Nachricht zum abfragen der repos und dann Absturz
Sag ich doch 😉
Homoran sagte:
@oliverio
Ich hab da noch was gefunden2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated
Das kommt mir aber bekannt vor.
Und
Homoran sagte:
EDIT:
Hab seitenweise EPIPE, ECONNRESET 9000 und 9001 im log!Ist das etwa dasselbe hier?
https://forum.iobroker.net/topic/85231/unregelmäßig-unmotivierter-neustart-aller-instanzen/Aber auch da gibt es keinerlei greifbare Ergebnisse.
Vielleicht kannst du den PI5 mal ohne dem Gehäuse laufen lassen
Ganz abgesehen davon, dass die Probleme bereits im Flirc Gehäuse begannen, bin ich ja danach auf Argon umgestiegen, da dort die NVMe und ein geregelter Lüfter drin sind.
Wäre aber jetzt nicht normal, wenn möglicherweise ausgerechnet der Lüfter due Störungen verursacht bzw. verschlimmert
-
Hier auch so eine Nachricht zum abfragen der repos und dann Absturz
Sag ich doch 😉
Homoran sagte:
@oliverio
Ich hab da noch was gefunden2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated
Das kommt mir aber bekannt vor.
Und
Homoran sagte:
EDIT:
Hab seitenweise EPIPE, ECONNRESET 9000 und 9001 im log!Ist das etwa dasselbe hier?
https://forum.iobroker.net/topic/85231/unregelmäßig-unmotivierter-neustart-aller-instanzen/Aber auch da gibt es keinerlei greifbare Ergebnisse.
Vielleicht kannst du den PI5 mal ohne dem Gehäuse laufen lassen
Ganz abgesehen davon, dass die Probleme bereits im Flirc Gehäuse begannen, bin ich ja danach auf Argon umgestiegen, da dort die NVMe und ein geregelter Lüfter drin sind.
Wäre aber jetzt nicht normal, wenn möglicherweise ausgerechnet der Lüfter due Störungen verursacht bzw. verschlimmert
Wäre aber jetzt nicht normal, wenn möglicherweise ausgerechnet der Lüfter due Störungen verursacht bzw. verschlimmert
Ich gebe dir da völlig recht. Ich hatte meinen PI4 dann wieder aus dem Gehäue genommen und der lief wieder - kein Problem mehr.
Möglicherweise eine andere Wärmeverteilung, vielleicht auch ungewollt ein Stromfluss der nicht sein darf - keine Ahnung.
Es war nur eine Idee, da ja wenn es was "globales" wäre hier viel mehr Berichte in gleicher Form auftauchen müssten. Deswegen denke ich, es ist etwas sehr spezielles und "unerfahren" bist du ja nun auch nicht. Deswegen, manchmal läuft es wirklich komisch.
Ro75.
SERVER = Beelink U59 16GB DDR4 RAM 512GB SSD, FB 7490, FritzDect 200+301+440, ConBee II, Zigbee Aqara Sensoren + NOUS A1Z, NOUS A1T, Philips Hue ** ioBroker, REDIS, influxdb2, Grafana, PiHole, Plex-Mediaserver, paperless-ngx (Docker), MariaDB + phpmyadmin *** VIS-Runtime = Intel NUC 8GB RAM 128GB SSD + 24" Touchscreen
-
Wäre aber jetzt nicht normal, wenn möglicherweise ausgerechnet der Lüfter due Störungen verursacht bzw. verschlimmert
Ich gebe dir da völlig recht. Ich hatte meinen PI4 dann wieder aus dem Gehäue genommen und der lief wieder - kein Problem mehr.
Möglicherweise eine andere Wärmeverteilung, vielleicht auch ungewollt ein Stromfluss der nicht sein darf - keine Ahnung.
Es war nur eine Idee, da ja wenn es was "globales" wäre hier viel mehr Berichte in gleicher Form auftauchen müssten. Deswegen denke ich, es ist etwas sehr spezielles und "unerfahren" bist du ja nun auch nicht. Deswegen, manchmal läuft es wirklich komisch.
Ro75.
@Ro75 ich logge jetzt auch noch die CPU Temp.
Hab leider auf die Schnelle keine Möglichkeit gefu den die Lüfteraktivität zu tracken.Nur ein Addon für HA
-
da könntest du mal auf input counts/output counts des javascript adapters tracken, ob das zu diesen ereignissen extrem ansteigt
Ooh, nicht korrekt gelesen
Hab nur die input counts 😞Was mich allerdings wundert ist, dass js.0 und js.1 etwa gleiche Werte (ca.1400) haben, obwohl in js.0 keine Skripte laufen
edit:
Jetzt aber
Input counts sind 10x so hoch wie die output counts@Homoran [sagte]: obwohl in js.0 keine Skripte laufen
Weshalb ist dann die Instanz aktiv? Das frisst nur eine Menge RAM.
In deinen Ausgaben von "top" vermisse ich "admin.0".
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN42 / N100 / 8 GB / 500 GB; Proxmox mit 2 VM (iob / openCCU)
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 Anmelden164
Online33.0k
Benutzende83.7k
Themen1.3m
Beiträge