Load average am Anschlag -> Neustart
-
Ich bin mit meinem Latein am Ende 😞
Seit etwa 2 Wochen startet mein iobroker immer mal wieder neu.
Ich habe nicht erkennen können woran es liegt, dass die load average kurz vorher an die Decke geht und tlw gut zweistellig liegt.Doku dazu hab ich leider der Einfachheit halber als Screenshits gemacht. Die waren schnell durchzuführen und leicht zu archivieren.
SYSTEM
Pi5 mit SD, zusätzlich .m2 SSD an USB2 für Backups
Stable Repo.Was ich gemacht habe:
Ich habe diesen Screen lange live betrachtet.
Während die load explodierte änderte sich in der unteren Tabelle die CPU Last nur marginal.Nach 2 Tagen Ärger bin ich auf ein neues System umgezogen, ähnliche Konstellation, anerer Pi5 im Argon Gehäuse mit .m2, diesmal endlich Trixie statt bookworm.
Außerdem ein Original pi5 netzteil, auch wenn in iob diag keine Auffälligkeiten warenNach leichten Startschwierigkeiten lief es 1.7 Tage absolut störungsfrei, dann das selbe Bild.
Ich meine damit Probleme im Unterbau (OS / NPM) ausgeschlossen zu haben, da auch die iob Adapter ja neu gebaut wurden.Kurz vor Auftreten habe ich noch 2 / 3 Updates gefahren, kann mich leider nicht genau erinnern welche.
Ich meine go-e und ical wären dabei gewesen.Nach dem Fehlerbild tippe ich allerdings auf web und Konsorten.
Im log war nichts zu sehen!Da fiel mir ein, dass ich einige Adapter auf logstufe warn hatte. Admin und web wieder auf info zurückgestellt und....
Das kann doch nicht gesund sein ;-)
Mittlerweile habe ich auch noch 2 Jahre History gelöscht, falls History bei der Erstellung der Charts von flot zuviel I/O braucht, was die load treibt.
Letzte Auffälligkeiten von heute
Schnell wechselnde CPU Last beim Controller
Für jede Hilfe oder Idee bin ich dankbar!
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 - -
Ich bin mit meinem Latein am Ende 😞
Seit etwa 2 Wochen startet mein iobroker immer mal wieder neu.
Ich habe nicht erkennen können woran es liegt, dass die load average kurz vorher an die Decke geht und tlw gut zweistellig liegt.Doku dazu hab ich leider der Einfachheit halber als Screenshits gemacht. Die waren schnell durchzuführen und leicht zu archivieren.
SYSTEM
Pi5 mit SD, zusätzlich .m2 SSD an USB2 für Backups
Stable Repo.Was ich gemacht habe:
Ich habe diesen Screen lange live betrachtet.
Während die load explodierte änderte sich in der unteren Tabelle die CPU Last nur marginal.Nach 2 Tagen Ärger bin ich auf ein neues System umgezogen, ähnliche Konstellation, anerer Pi5 im Argon Gehäuse mit .m2, diesmal endlich Trixie statt bookworm.
Außerdem ein Original pi5 netzteil, auch wenn in iob diag keine Auffälligkeiten warenNach leichten Startschwierigkeiten lief es 1.7 Tage absolut störungsfrei, dann das selbe Bild.
Ich meine damit Probleme im Unterbau (OS / NPM) ausgeschlossen zu haben, da auch die iob Adapter ja neu gebaut wurden.Kurz vor Auftreten habe ich noch 2 / 3 Updates gefahren, kann mich leider nicht genau erinnern welche.
Ich meine go-e und ical wären dabei gewesen.Nach dem Fehlerbild tippe ich allerdings auf web und Konsorten.
Im log war nichts zu sehen!Da fiel mir ein, dass ich einige Adapter auf logstufe warn hatte. Admin und web wieder auf info zurückgestellt und....
Das kann doch nicht gesund sein ;-)
Mittlerweile habe ich auch noch 2 Jahre History gelöscht, falls History bei der Erstellung der Charts von flot zuviel I/O braucht, was die load treibt.
Letzte Auffälligkeiten von heute
Schnell wechselnde CPU Last beim Controller
Für jede Hilfe oder Idee bin ich dankbar!
also du hast 2 extreme load ereignisse ca 7:50 und ca 8:56
und 1 leichtes load ereignis bei ca 8:30/8:351. chart
input count
bei 7:50 lässt sich nicht abschätzen
bei 8:35 er leicht an
bei 9:00 stärker (leider abgeschnitten)freies RAM
7:50 nicht gut lesbar
8:35 leichtes abfallen
9:00 starkes abfallen2.chart
load
hier sieht man deutlich die starken und leichen load anstiege
bei den uhrzeitenRAM oder CPU?
Im text schreibst du der 2. chart zeigt die cpu last ich gehe davon aus, das es nur die grüne load linie betrifft, der rest zeigt den ram verbrauch der adapter
bei 8:00 siehst du einen leichten anstieg und dann ein starkes abfallen.
das müsste entweder ein neustart des javascript adapters sein oder (was ungewöhnlich wäre) der adapter gibt plötzlich eine große menge an speicher frei. ich tippe auf ersteres
admin adapter steigt der ram verbrauch stärker an und fällt dann wieder ab.
9:00 ähnliches, aber nicht so stark ausgeprägtich tippe erst einmal auf ein skript im javascript adapter.
entweder erzeugt es viele lese und schreibvorgänge in sehr kurzer zeit
oder events schaukeln sich auf.
entweder blockt das der admin, ich glaube da gibt es eine grenze wieviel vorgänge ein adapter innerhalb einer sekunde senden darf und startet den javascript adapter neudu sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
die connected/disconnected meldungen sind eigentlich harmlos. alles in iobroker kommuniziert per socket. der client (also jeder adapter oder auch visualisierungen) melden sich an und schließen die verbindung wenn bspw bei vis das tablet in den schlafmodus geht (glaube ich). ich habe ähnliche meldungen, allerdings nicht ganz so oft.
ich hatte vor einigen jahre ein ähnliches problem. da hat ein skript wegen falsch programmieren setTimeouts immer mehr zugriffe auf datenpunkte erzeugt. irgendwann ist der js-controller dann abgestürzt.
aber nur eine vermutung und evtl hinweise fürs weitersuchen.
wenn du an den skripten nichts verändert hast, kann es evtl auch durch eine höhere schreibdichte auf datenpunkte, bei denen du im javascript einen trigger darauf hast kommen. evtl durch einen neuen oder aktualisierten adapter. da könntest du mal auf input counts/output counts des javascript adapters tracken, ob das zu diesen ereignissen extrem ansteigt (und hoffen das das noch geschrieben wird bevor der iobroker abstürzt)Meine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
also du hast 2 extreme load ereignisse ca 7:50 und ca 8:56
und 1 leichtes load ereignis bei ca 8:30/8:351. chart
input count
bei 7:50 lässt sich nicht abschätzen
bei 8:35 er leicht an
bei 9:00 stärker (leider abgeschnitten)freies RAM
7:50 nicht gut lesbar
8:35 leichtes abfallen
9:00 starkes abfallen2.chart
load
hier sieht man deutlich die starken und leichen load anstiege
bei den uhrzeitenRAM oder CPU?
Im text schreibst du der 2. chart zeigt die cpu last ich gehe davon aus, das es nur die grüne load linie betrifft, der rest zeigt den ram verbrauch der adapter
bei 8:00 siehst du einen leichten anstieg und dann ein starkes abfallen.
das müsste entweder ein neustart des javascript adapters sein oder (was ungewöhnlich wäre) der adapter gibt plötzlich eine große menge an speicher frei. ich tippe auf ersteres
admin adapter steigt der ram verbrauch stärker an und fällt dann wieder ab.
9:00 ähnliches, aber nicht so stark ausgeprägtich tippe erst einmal auf ein skript im javascript adapter.
entweder erzeugt es viele lese und schreibvorgänge in sehr kurzer zeit
oder events schaukeln sich auf.
entweder blockt das der admin, ich glaube da gibt es eine grenze wieviel vorgänge ein adapter innerhalb einer sekunde senden darf und startet den javascript adapter neudu sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
die connected/disconnected meldungen sind eigentlich harmlos. alles in iobroker kommuniziert per socket. der client (also jeder adapter oder auch visualisierungen) melden sich an und schließen die verbindung wenn bspw bei vis das tablet in den schlafmodus geht (glaube ich). ich habe ähnliche meldungen, allerdings nicht ganz so oft.
ich hatte vor einigen jahre ein ähnliches problem. da hat ein skript wegen falsch programmieren setTimeouts immer mehr zugriffe auf datenpunkte erzeugt. irgendwann ist der js-controller dann abgestürzt.
aber nur eine vermutung und evtl hinweise fürs weitersuchen.
wenn du an den skripten nichts verändert hast, kann es evtl auch durch eine höhere schreibdichte auf datenpunkte, bei denen du im javascript einen trigger darauf hast kommen. evtl durch einen neuen oder aktualisierten adapter. da könntest du mal auf input counts/output counts des javascript adapters tracken, ob das zu diesen ereignissen extrem ansteigt (und hoffen das das noch geschrieben wird bevor der iobroker abstürzt)Im text schreibst du der 2. chart zeigt die cpu last ich gehe davon aus
Tat ich das?
sorry.
Cpu last ist ganz unten die Tabelle!du sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
09:04, siehe Tabelle
Der chart zeigt leider durch die Aggregation nicht immer alle kurzen aber massiven Ausschläge an 😞
nur eine vermutung und evtl hinweise fürs weitersuchen.
Danke, das ist genau was ich brauche!
Aber Skripte sehe ich nicht, der js-Adapter läuft ruhig.
bei 9:00 stärker (leider abgeschnitten)
Müsste ich mal versuchen den "echten" Wert herauszufinden
DANKE
Edit:
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 - -
also du hast 2 extreme load ereignisse ca 7:50 und ca 8:56
und 1 leichtes load ereignis bei ca 8:30/8:351. chart
input count
bei 7:50 lässt sich nicht abschätzen
bei 8:35 er leicht an
bei 9:00 stärker (leider abgeschnitten)freies RAM
7:50 nicht gut lesbar
8:35 leichtes abfallen
9:00 starkes abfallen2.chart
load
hier sieht man deutlich die starken und leichen load anstiege
bei den uhrzeitenRAM oder CPU?
Im text schreibst du der 2. chart zeigt die cpu last ich gehe davon aus, das es nur die grüne load linie betrifft, der rest zeigt den ram verbrauch der adapter
bei 8:00 siehst du einen leichten anstieg und dann ein starkes abfallen.
das müsste entweder ein neustart des javascript adapters sein oder (was ungewöhnlich wäre) der adapter gibt plötzlich eine große menge an speicher frei. ich tippe auf ersteres
admin adapter steigt der ram verbrauch stärker an und fällt dann wieder ab.
9:00 ähnliches, aber nicht so stark ausgeprägtich tippe erst einmal auf ein skript im javascript adapter.
entweder erzeugt es viele lese und schreibvorgänge in sehr kurzer zeit
oder events schaukeln sich auf.
entweder blockt das der admin, ich glaube da gibt es eine grenze wieviel vorgänge ein adapter innerhalb einer sekunde senden darf und startet den javascript adapter neudu sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
die connected/disconnected meldungen sind eigentlich harmlos. alles in iobroker kommuniziert per socket. der client (also jeder adapter oder auch visualisierungen) melden sich an und schließen die verbindung wenn bspw bei vis das tablet in den schlafmodus geht (glaube ich). ich habe ähnliche meldungen, allerdings nicht ganz so oft.
ich hatte vor einigen jahre ein ähnliches problem. da hat ein skript wegen falsch programmieren setTimeouts immer mehr zugriffe auf datenpunkte erzeugt. irgendwann ist der js-controller dann abgestürzt.
aber nur eine vermutung und evtl hinweise fürs weitersuchen.
wenn du an den skripten nichts verändert hast, kann es evtl auch durch eine höhere schreibdichte auf datenpunkte, bei denen du im javascript einen trigger darauf hast kommen. evtl durch einen neuen oder aktualisierten adapter. da könntest du mal auf input counts/output counts des javascript adapters tracken, ob das zu diesen ereignissen extrem ansteigt (und hoffen das das noch geschrieben wird bevor der iobroker abstürzt)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 countskein 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 - -
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:
js.0 und js.1 etwa gleiche Werte (ca.1400) haben, obwohl in js.0 keine Skripte laufenFür beide Instanzen wird der (getrennte) Puffer synchronisiert.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN42 / N100 / 8 GB / 500 GB; Proxmox mit 2 VM (iob / openCCU) -
@Homoran sagte:
js.0 und js.1 etwa gleiche Werte (ca.1400) haben, obwohl in js.0 keine Skripte laufenFür beide Instanzen wird der (getrennte) Puffer synchronisiert.
@paul53 Danke!
Hab mir so etwas gedacht und jetzt statt js.0 input in und output für js.1 im chart integriertkein 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 - -
@paul53 Danke!
Hab mir so etwas gedacht und jetzt statt js.0 input in und output für js.1 im chart integriert@Homoran sagte:
für js.1 im chart integriertBei Input von 4000 muss ein Adapter schnell viele DP aktualisieren.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN42 / N100 / 8 GB / 500 GB; Proxmox mit 2 VM (iob / openCCU) -
@Homoran sagte:
für js.1 im chart integriertBei Input von 4000 muss ein Adapter schnell viele DP aktualisieren.
-
Im text schreibst du der 2. chart zeigt die cpu last ich gehe davon aus
Tat ich das?
sorry.
Cpu last ist ganz unten die Tabelle!du sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
09:04, siehe Tabelle
Der chart zeigt leider durch die Aggregation nicht immer alle kurzen aber massiven Ausschläge an 😞
nur eine vermutung und evtl hinweise fürs weitersuchen.
Danke, das ist genau was ich brauche!
Aber Skripte sehe ich nicht, der js-Adapter läuft ruhig.
bei 9:00 stärker (leider abgeschnitten)
Müsste ich mal versuchen den "echten" Wert herauszufinden
DANKE
Edit:
Homoran sagte:
@OliverIO sagte:
du sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
09:04, siehe Tabelle
@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.
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 - -
Ich hab da noch was gefunden
2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated
Das kommt mir aber bekannt vor.
der admin hat die ratings, also die bewertungssterne der adapter gelesen
https://github.com/ioBroker/ioBroker.socket-classes/blob/aea61897afee4642784737c162760db9bcdcf4fe/src/lib/socketCommandsAdmin.ts#L267 -
Ich hab da noch was gefunden
2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated
Das kommt mir aber bekannt vor.
der admin hat die ratings, also die bewertungssterne der adapter gelesen
https://github.com/ioBroker/ioBroker.socket-classes/blob/aea61897afee4642784737c162760db9bcdcf4fe/src/lib/socketCommandsAdmin.ts#L267@OliverIO danke, ja das weiss ich.
Aber ich habe einige Absturzberichte im Hinterkopf, bei denen auch das lesen der ratings das letzte Lebenszeichen war. Die finde ich gerade nicht mehr.Ist aber wahrscheinlich nur Zufall, gestern 14:10 war da nichts entsprechendes im log.
Hier
Habe ich mal sie counts auf max aggregiert.
Input kommt auf gut 3000, output auf 600Das korreliert nicht (??) mit den peaks bei load.
Auch wenn es bei 15:30 so sein könnte, habe ich dort mit dem Zoom in einem flot chart gespielt, bis die load auf 4 war. Danach aufgehört und die load fing sich wieder.
Das käme meiner Theorie vom Zugriff auf die SD und hoher I/O entgegen.
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 - -
@OliverIO danke, ja das weiss ich.
Aber ich habe einige Absturzberichte im Hinterkopf, bei denen auch das lesen der ratings das letzte Lebenszeichen war. Die finde ich gerade nicht mehr.Ist aber wahrscheinlich nur Zufall, gestern 14:10 war da nichts entsprechendes im log.
Hier
Habe ich mal sie counts auf max aggregiert.
Input kommt auf gut 3000, output auf 600Das korreliert nicht (??) mit den peaks bei load.
Auch wenn es bei 15:30 so sein könnte, habe ich dort mit dem Zoom in einem flot chart gespielt, bis die load auf 4 war. Danach aufgehört und die load fing sich wieder.
Das käme meiner Theorie vom Zugriff auf die SD und hoher I/O entgegen.
wenn ich mich recht erinnere setzt du das standard jsonl als datenbank format ein. wenn du viele datenpunkte hast und auch viel history machst, kommst du evtl an die grenzen?
evtl mal redis probieren? -
wenn ich mich recht erinnere setzt du das standard jsonl als datenbank format ein. wenn du viele datenpunkte hast und auch viel history machst, kommst du evtl an die grenzen?
evtl mal redis probieren?@OliverIO Danke!
Wäre vielleicht mal zu testen, ist für mich aber eher eine Symptombekämpfung.Wenn es nicht eine kritische Masse gibt, nach deren Überschreitung alles zusammenbricht ergibt das für mich keinen Sinn.
Ich logge diese Daten seit 12 Jahren auf allen bisherigen Systemen.
Seit Umzug auf den Pi5 lag die load durchgehend unter 1 (backup und install ausgenommen)Seit 2-3 Wochen jetzt diese immensen Ausreißer.
Ich weiss dass ich mit history übertrieben habe, aber ich habe gestern 30GB! Daten aus 2021 und 2022 gelöscht.
Wenn getHistory überlastet war, hätte das IMHO schleichend beginnen und nach der Radikalkur wieder beendet sein müssen.Skripte habe ich nocht in den letzten Wochen neu angelegt oder geändert.
Es kann aus meiner Logik eher ein Adapter- oder nodejs Update verursacht haben.
-
Update:
Gestern abend stieg noch einmal die Load an den Anschlag, warum auch immer.
Anscheinend regelte das System dagegen an, indem die CPU Frequenz auf 2400 ging bis die load etwa unter 2 fiel, danach stieg die Load wieder usw.Hier aggregiert auf minmax
Um die Spitzen besser zu sehen, load, js.0 in und out jetzt aggregiert auf max
Ich sehe da keine Korrelation von load zu js.
Der memfree fiel schon 1h vorher leicht ab und ging nach dem Backup um 03:30 erst wieder zurück zum alten Wert
-
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/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 - -
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...
Intel(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
-
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
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 Anmelden182
Online33.0k
Benutzende83.7k
Themen1.3m
Beiträge