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

@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

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

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

entferne in den Logs die FIN von deinem Auto !

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

Ab hier ECONNREFUSED :

2023-04-03 02:52:22.796  - [33mwarn[39m: 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  - [33mwarn[39m: 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 !

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

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.

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

@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

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

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

@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)

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

Da geht dem System der Arbeitsspeicher aus.

und der swap :-)

Da geht dem System der Arbeitsspeicher aus.

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

und

Apr  3 03:36:40 iobroker kernel: [231817.391605] 9688 pages in swap cache
Apr  3 03:36:40 iobroker kernel: [231817.391607] Swap cache stats: add 2232089, delete 2222436, find 629163/901540
Apr  3 03:36:40 iobroker kernel: [231817.391608] Free swap  = 0kB
Apr  3 03:36:40 iobroker kernel: [231817.391609] Total swap = 1000444kB
Apr  3 03:36:40 iobroker kernel: [231817.391610] 4165748 pages RAM

@jackdaniel müssen aber einen zeitpunkt finden, an dem es passiert ist - um irgendwie anzufangen - in deinem syslog ist kein 4.3.

irgendwie brauchen wir einen definierten crashzustand und die beiden log s von diesem zeitpunkt

es gibt auch out of mem errors - die hören sich nicht gut anv - was läuft auf dem nuc noch außer iob

influxdb,motioneye und plex

@jackdaniel
Grenz das log mal zeitlich auf eine Stunde vor und nach dem Crash ein.
Da ist ja jetzt der Kram von mehreren Tagen drin.

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