Node-Red auf Venus 3.62 startet grundlos neu

Hallo,
seit ich auf 3.62 umgestiegen bin, startet mein Node-Red einfach mal neu, heute z.B. nach 15 Tagen uptime.
Vorher mit 3.60 ist es auch schon passiert, aber nach noch kürzerer Zeit.

Wollte mal fragen ob das bei euch auch passiert ?

Auszug aus dem Log:

@40000000686d862706aab7ec 8 Jul 22:57:01 - [info] [mqtt-broker:Webserver] Connected to broker: Venus@mqtt://192.168.168.250:1883
@40000000687485d41fa13c94 14 Jul 06:21:30 - [info] [mqtt-broker:Venus] Disconnected from broker: lokal@mqtt://localhost:1883
@40000000687485d50f59dcec 14 Jul 06:21:31 - [info] Stopping flows
@40000000687485d514c953c4 14 Jul 06:21:31 - [info] [udp in:SMA HM] udp listener stopped
@40000000687485d51a4810c4 14 Jul 06:21:31 - [info] [mqtt-broker:Webserver] Disconnected from broker: Venus@mqtt://192.168.168.250:1883
@40000000687485d715b4c91c 14 Jul 06:21:33 - [info] Stopped flows
@40000000687485d71b2c1bac *** starting node-red-venus ***
@40000000687485d71e9a05c4 *** Waiting for localsettings...
@40000000687485d71fdc5194 *** Starting in normal mode
@40000000687485da102f68e4 [info]: loading /data/home/nodered/.node-red/settings-venus.js failed
@40000000687485da1076e5ac [info]: loading /data/home/nodered/.node-red/settings-user.js failed
@40000000687485da2d967e7c 14 Jul 06:21:36 - [info] 
@40000000687485da2d969204 
@40000000687485da2d9699d4 Welcome to Node-RED
@40000000687485da2d96a1a4 ===================
@40000000687485da2d96a974 
@40000000687485da2dbe2ea4 14 Jul 06:21:36 - [info] Node-RED version: v3.1.15
@40000000687485da2dd50264 14 Jul 06:21:36 - [info] Node.js  version: v20.18.2
@40000000687485da2df40f9c 14 Jul 06:21:36 - [info] Linux 5.10.110 arm LE
@40000000687485dc0756b344 14 Jul 06:21:38 - [info] Loading palette nodes
@40000000687485df0d8da86c 14 Jul 06:21:41 - [info] Dashboard version 3.6.5 started at /ui
@40000000687485e1037f4d44 14 Jul 06:21:43 - [info] Settings file  : /usr/lib/node_modules/node-red/venus-settings.js
@40000000687485e103c25184 14 Jul 06:21:43 - [info] Context store  : 'default' [module=memory]
@40000000687485e103fd9d34 14 Jul 06:21:43 - [info] User directory : /data/home/nodered/.node-red
@40000000687485e1040b742c 14 Jul 06:21:43 - [warn] Projects disabled : editorTheme.projects.enabled=false
@40000000687485e104637384 14 Jul 06:21:43 - [info] Flows file     : /data/home/nodered/.node-red/flows.json
@40000000687485e108e02dbc 14 Jul 06:21:43 - [info] Server now running at http://127.0.0.1:1880/
@40000000687485e109d5ad64 14 Jul 06:21:43 - [warn] 
@40000000687485e109d5bd04 
@40000000687485e109d5c4d4 ---------------------------------------------------------------------
@40000000687485e109d5d474 Your flow credentials file is encrypted using a system-generated key.
@40000000687485e109d5e02c 
@40000000687485e109d5e7fc If the system-generated key is lost for any reason, your credentials
@40000000687485e109d5f3b4 file will not be recoverable, you will have to delete it and re-enter
@40000000687485e109d60354 your credentials.
@40000000687485e109d6fd54 
@40000000687485e109d70524 You should set your own key using the 'credentialSecret' option in
@40000000687485e109d710dc your settings file. Node-RED will then re-encrypt your credentials
@40000000687485e109d71c94 file using your chosen key the next time you deploy a change.
@40000000687485e109d7284c ---------------------------------------------------------------------
@40000000687485e109d737ec 
@40000000687485e1147407d4 14 Jul 06:21:43 - [info] Starting flows
@40000000687485e20bbf06d4 14 Jul 06:21:44 - [info] Started flows
@40000000687485e20d4c1f14 14 Jul 06:21:44 - [info] [udp in:SMA HM] udp multicast group 239.12.255.254
@40000000687485e20d75cb0c 14 Jul 06:21:44 - [info] [udp in:SMA HM] udp listener at 0.0.0.0:9522
@40000000687485e21edbc5cc Connected to D-Bus.
@40000000687485e21f209ae4 Polling is disabled. This is the recommended configuration.
@40000000687485e21f433a2c Polling is disabled. All roots have been requested once successfully.
@40000000687485e221a39c44 14 Jul 06:21:44 - [info] [mqtt-broker:Webserver] Connected to broker: Venus@mqtt://192.168.168.250:1883
@40000000687485e2222d3ea4 Service com.victronenergy.settings not found in cache. Publish may fail.
@40000000687485e22808b5ec 14 Jul 06:21:44 - [info] [mqtt-broker:Venus] Connected to broker: lokal@mqtt://localhost:1883

hallo,
dass node-red in unregelmaessigen abstaenden mal neu startet, kannst du nicht verhindern. der neustart wird durch einen bug ausgeloest, so dass das programm abstuerzt und automatisch neu gestartet wird.

das passiert bei mir auf allen systemen, egal ob gx oder odroid-m1. das ist auch kein problem, alle flows werden auch automatisch neu gestartet, man kann das auch beim start entsprechend in den flows beruecksichtigen.

das hat allerdings den nachteil, dass diagramm ebenfalls ohne daten neu gestartet werden und regelungen sich neu einregeln muessen. man kann deshalb auch in node-red selbst keine daten dauerhaft speichern, sie gehen beim neustart von node-red verloren. daten, die nach einem neustart wieder verfuegbar sein muessen, muessen deshalb in einer datenbank oder einer datei gespeichert werden. muessen die daten nur einen neustart von node-red ueberleben, aber keinen neustart des ganzen systems, kann man sie auch auf dem mqtt-server ablegen.

tschuess

Welcher Bug? In Node-RED, im VenusOS, wo sonst?

das ist ja interessant, ich verwende seit Jahren VenusOS, mit 2,x angefangen, bis 3,55 nie erlebt dass Node-Red neustartet.

hallo,
das ist entweder einbug im node.js, in node-red oder einem node, der den absturz verursacht. bisher hatte ich dieses problem nur einmal reproduzierbar und da war der fehler in einem shelly-node. um das problem zu beseitigen musste ich die datei mit den flows mit einem editor bearbeiten.
in dem fall war es eine nicht existierende variable, die den absturz verursacht hat.

tschuess

hallo,
dass node-red neu startet, passiert bei mir in groesseren abstaenden immer wieder. dabei spielt es keine rolle, auf welchem system.

tschuess

ich verwende Node-Red 4.09 auf zig anderen VM & RPi - da startet es niemals neu, teilweise >90 Tage Uptime.

Edit: irgendwas ist doch komisch bei mir, zwei andere Node-Red Instanzen (VM) haben heute um ähnliche Uhrzeiten neugestartet (6:40), dazu FlashMQ gleichzeitig.

Jetzt ist die Frage ob ein Restart von FlashMQ Node-Red getriggert hat oder umgekehrt.

Edit2: ich hatte mal einen Fehler in einer Modbus Abfrage, die zu einem anstieg des Ram geführt hat über Wochen, wenn der Ram dann zu voll war hat Node-Red neugestartet, das stand dann aber auch im Debug drin als Ursache.

hallo,
ich habe da nicht weiter nach den ursachen gesucht sondern mich damit abgefunden und erstelle meine flows so, dass es nach einem neustart keine probleme gibt. selbst wenn dann mal die heizung fuer 1-2 minuten ausfaellt, ist das nicht schlimm.

das problem ist, dass software normalerweise immer fehler hat, die frage ich nur, ob man von dem fehler betroffen ist. lediglich bei kleinen und sehr gut getesteten programmen kann man alle fehler sicher beseitigen. ich dachte auch einmal, dass eines meiner programme fehlerfrei ist. solange keine stoerung auftrat, war es das auch. aber ich hatte eine integerdivision im programm und bei genau einem 32bit-integer (alle bits auf 1) kam es zu einem ueberlauf, so dass ich diesen wert dann noch abfangen musste. dabei kommt dieser wert normalerweise nie vor!

und probleme mit speicherfressern sind immer ganz schlimm. bei mit hat es so auch schon mehrfach den tightvnc-server abgeschossen!

tschuess

Ursache gefunden:
grep "upgrade " /var/log/dpkg.log

2025-07-15 06:39:49 upgrade python3-problem-report:all 2.28.1-0ubuntu3.7 2.28.1-0ubuntu3.8
2025-07-15 06:39:49 upgrade python3-apport:all 2.28.1-0ubuntu3.7 2.28.1-0ubuntu3.8
2025-07-15 06:39:49 upgrade apport-core-dump-handler:all 2.28.1-0ubuntu3.7 2.28.1-0ubuntu3.8
2025-07-15 06:39:49 upgrade apport:all 2.28.1-0ubuntu3.7 2.28.1-0ubuntu3.8
2025-07-15 06:39:56 upgrade libc-devtools:amd64 2.39-0ubuntu8.4 2.39-0ubuntu8.5
2025-07-15 06:39:56 upgrade libc6-dev:amd64 2.39-0ubuntu8.4 2.39-0ubuntu8.5
2025-07-15 06:39:56 upgrade libc-dev-bin:amd64 2.39-0ubuntu8.4 2.39-0ubuntu8.5
2025-07-15 06:39:56 upgrade libc6:amd64 2.39-0ubuntu8.4 2.39-0ubuntu8.5
2025-07-15 06:39:57 upgrade libc-bin:amd64 2.39-0ubuntu8.4 2.39-0ubuntu8.5
2025-07-15 06:39:58 upgrade locales:all 2.39-0ubuntu8.4 2.39-0ubuntu8.5
2025-07-15 06:40:18 upgrade libgnutls30t64:amd64 3.8.3-1.1ubuntu3.3 3.8.3-1.1ubuntu3.4
2025-07-15 07:58:10 upgrade firmware-sof-signed:all 2023.12.1-1ubuntu1.5 2023.12.1-1ubuntu1.6

ein automisches Update hat div. Dienste neugestartet.

Habe ich bisher noch nie erlebt, aber man lernt dazu :laughing:

Zumindest bei meiner VM, ob das im VenusOS auch die Ursache war weiß ich nicht, also ob dort auch “unattended-upgrade” benutzt wird.