Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[liv-in-sky]

@thomas-braun sagte in Sporadische Neustarts/Crashes ioB:

@jackdaniel

Da geht dem System der Arbeitsspeicher aus.

und der swap :-)

[Thomas Braun]

@liv-in-sky

In der Folge natürlich auch der.
Wobei die Kiste ja eigentlich mit beidem üppig ausgestattet ist.

MEMORY:

               total        used        free      shared  buff/cache   available
Mem:             15G        5.0G        9.2G        0.0K        1.7G         10G
Swap:           976M        457M        519M
Total:           16G        5.4G        9.7G

Da ist also irgendwas sehr schief.

[JackDaniel]

@liv-in-sky sagte in Sporadische Neustarts/Crashes ioB:

@jackdaniel seit wann ist das so ? - irgendwelche neue scripte installiert, die immer wieder mal starten?

scripte gab es nur marginale änderungen, größte umstellung war influxdb 1.x auf 2.x
einige adapter sind auch dazu gekommen (device watcher, mihome-cloud)

[liv-in-sky]

@jackdaniel

eine kleine änderung in den scripten kann auch dazu führen - spreche aus erfahrung :-)

du kannst natürlich mal die neuen adapter ausmachen - aber ich glaube nicht, dass es daran liegt

wenn du im setting der javascript instanz das script backup aktiviert hast, kannst du darin (im filesystem) nach den neusten dateien (scripten) suchen und findest heraus, wann du was geändert hast

mir fällt im moment nix besseres ein, als das zu beobachten und dabei bestimmte sachen auszuschalten (neue adapter) oder auch die neuen scripte in eine weiter javascript instanz verschieben und deaktivieren - so könntest du den fehler "einkreisen"

oder jmd anders hat noch eine idee

[liv-in-sky]

@jackdaniel sagte in Sporadische Neustarts/Crashes ioB:

größte umstellung war influxdb 1.x auf 2.x

damit kenne ich mich nicht aus - was man da noch checken könnte - evtl. weiß @Thomas-Braun da ein paar tricks

[JackDaniel]

@liv-in-sky sagte in Sporadische Neustarts/Crashes ioB:

@jackdaniel

wenn du im setting der javascript instanz das script backup aktiviert hast, kannst du darin (im filesystem) nach den neusten dateien (scripten) suchen und findest heraus, wann du was geändert hast

danke guter tip, letzte änderung war am 26.01.23 und da hab ich nur einen enocean fenstergriff gegen einen von hm ip getauscht, sonst liegt alles im jahr 2022

[liv-in-sky]

@jackdaniel dann scheinen die scripte ausgeschlossen sein

[Ein ehemaliger Benutzer]

@jackdaniel sagte in Sporadische Neustarts/Crashes ioB:

so das müsste es sein:
Apr 3 030903 iobroker upsd[740] Da.txt

Moin,

also gleich am Anfang der Datei bekommst Du ein oom das bedeutet ein Prozess io.pushover.0 wurde aus dem Speicher geschmissen.

io.pushover.0 invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0

Wenn Du mal im Log nach 171246 suchst, dann findest Du das der node Prozess abgeschossen wurde, damit ist auch die Verbindung zu DB tot, und das ganze iobroker System ist runtergefahren.

Apr  3 03:36:40 iobroker kernel: [231817.391880] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/iobroker.service,task=node,pid=171246,uid=1001
Apr  3 03:36:40 iobroker kernel: [231817.391918] Out of memory: Killed process 171246 (node) total-vm:26720900kB, anon-rss:11704620kB, file-rss:0kB, shmem-rss:0kB, UID:1001 pgtables:37664kB oom_score_adj:0
Apr  3 03:36:40 iobroker systemd[1]: iobroker.service: A process of this unit has been killed by the OOM killer.

Apr  3 03:36:55 iobroker systemd[1]: iobroker.service: Failed with result 'oom-kill'.
Apr  3 03:36:55 iobroker systemd[1]: iobroker.service: Consumed 7h 13min 56.369s CPU time.
Apr  3 03:36:58 iobroker systemd[1]: iobroker.service: Scheduled restart job, restart counter is at 4.
Apr  3 03:36:58 iobroker systemd[1]: Stopped ioBroker Server.
Apr  3 03:36:58 iobroker systemd[1]: iobroker.service: Consumed 7h 13min 56.369s CPU time.
Apr  3 03:36:58 iobroker systemd[1]: Started ioBroker Server.

Hast Du pushover schon länger am Laufen oder kürzlich etwas daran geändert?

Ob es jetzt daran liegt, kann ich nicht sagen, vielleicht passiert da vorher ja noch etwas, dass das nur ein Folgefehler ist.

VG
Bernd

[Thomas Braun]

@dp20eic sagte in Sporadische Neustarts/Crashes ioB:

Ob es jetzt daran liegt, kann ich nicht sagen, vielleicht passiert da vorher ja noch etwas, dass das nur ein Folgefehler ist.

Das muss nicht die Ursache für den Speichermangel sein, nur der Tropfen der das Fass zum Überlaufen bringt und den oom-killer auf den Plan ruft.
Der senst dann für das Kernsystem entbehrliche Prozesse weg. Trifft dann halt den iobroker, weil der mit dem Systemkern ja nix zu tun hat.

[JackDaniel]

@dp20eic sagte in Sporadische Neustarts/Crashes ioB:

Hast Du pushover schon länger am Laufen oder kürzlich etwas daran geändert?

schon seit dem ersten tag, aber danke für den input

[Glasfaser]

@jackdaniel

Ab hier ECONNREFUSED :

2023-04-03 02:52:22.796  - warn: chromecast.0 (162295) Keller - Client error: Error: connect ECONNREFUSED 192.168.1.149:8009
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1494:16)

kommt auch immer already running:

2023-04-03 01:15:00.003  - warn: host.iobroker instance system.adapter.envertech-pv.0 already running with pid 162592

Hast du dein ioBroker schonmal neu rebootet !?

in den log´s stehen eh keine "persöhnlichen" dinge wie zb. pw usw.. oder?

entferne in den Logs die FIN von deinem Auto !

[Homoran]

@glasfaser sagte in Sporadische Neustarts/Crashes ioB:

entferne in den Logs die FIN von deinem Auto !

die steht aber auch für jeden sichtbar in der Windschutzscheibe

[Glasfaser]

@homoran

Großes Ja ... da gebe ich dir Recht ...
... aber war nur ein Hinweis !

[mcm1957]

@JackDaniel
Na ja,
den envertech-pv hast du in letzter Zeit zumindest auch aktualisiert :-)

https://github.com/iobroker-community-adapters/ioBroker.envertech-pv/issues/44#issuecomment-1493880654

Ich konnte bei mir keine Auffälligkeiten beim Memory feststellen. Aber schau dir den ggF gezielt an. Der Adapter ist nagelneu und im latest. Kann ja sein, dass ich da nen Fehler eingebaut hab. Mangels Aufnahme im latest seh ich zur Zeit nicht wieviele den einsetzen. Meldungen über Probleme gab es aber keine bisher.

McM

[Ein ehemaliger Benutzer]

@jackdaniel sagte in Sporadische Neustarts/Crashes ioB:

@dp20eic sagte in Sporadische Neustarts/Crashes ioB:

Hast Du pushover schon länger am Laufen oder kürzlich etwas daran geändert?

schon seit dem ersten tag, aber danke für den input

Moin,

ich habe auch geschrieben, dass das nur Nachfolgefehler seien könnten und Du Dir Deine Logs z.B. Syslog, Journ-Log anschauen musst, um evtl. noch andere Probleme zu finden, such doch mal nach den OOM vielleicht kommt da ja noch mehr zum Vorschein.

VG
Bernd

[JackDaniel]

danke mal an alle für die rasche hilfe
bin nun wieder auf die 1.x version von influxdb gegangen, da ich denke das es zeitlich am ehesten mit dem verhalten zusammenpasst.
werde das nun weiter beobachten, melde mich hier wieder sobald ich mehr erkentnisse habe

[apollon77]

An sich steht doch beim OOM im log auch immer die prozessliste mir RAM usage ... wer ist denn da s ich da mit "viel"?

[Ein ehemaliger Benutzer]

@jackdaniel sagte in Sporadische Neustarts/Crashes ioB (gelöst):

danke mal an alle für die rasche hilfe
bin nun wieder auf die 1.x version von influxdb gegangen, da ich denke das es zeitlich am ehesten mit dem verhalten zusammenpasst.
werde das nun weiter beobachten, melde mich hier wieder sobald ich mehr erkentnisse habe

Moin,

ich habe sowohl einen LXC Container mit influxDB V 1.8 als auch zwei influxDB V 2.6 LXC Container, und die sind auch nicht wirklich riesig, was Speicher oder RAM angeht, ich habe damit keinerlei Probleme.

Zudem kenne ich keinen Weg, von einer influxDb V 2.x zurück zur V 1.8. da ja die Daten bei der Migration von V 1.8 zu 2.6 angepasst werden, wie hast Du das hinbekommen?

VG
Bernd

[JackDaniel]

so abschließend noch zu diesem thema, übeltäter war die m.2 ssd die am sterben war bzw. jetzt total tot ist
mal schauen wie lange jetzt die wd red durchhält :)