Persistent data not being saved

#1

Using v0.19.5 script installed, on a Pi running Debian Stretch.

Persistence to disk generally works well for me, but noticed that node-red-stop does not initiate a flush to disk, and this has caught me out a few times now.

I know this has been raised before in NR Slack, but never resolved.

Is node-red-stop the preferred way to stop node-RED, or is there a better way, which would initiate a flush?

1 Like
#2

I have the same issue when I stop NR on a Macintosh by killing its process, so it may not be a matter of how it is started or stopped.

#3

Have a look to the doc:

The default configuration for a file context store is to use the directory ~/.node-red/context, with caching enabled and writes to storage happening every 30 seconds.

The flushInterval is provided to minimise wear on the underlying storage, such as on a Raspberry Pi’s SD card. Note that if Node-RED is unexpectedly killed, any data that has not yet been flushed will be lost.

#4

I'm not talking about Node-RED being unexpectedly killed, I'm referring to it being gracefully shutdown by node-red-stop.

When persistence was first introduced, it was said that stopping Node-RED would trigger a flush, which it does not appear to do.

As I recall - although maybe wrong! it was something to do with the Node-RED shutdown process, which should trigger the buffer to be flushed to disk, before completing the shutdown.

#5

I know, my link to the doc was for @drmibell talking about killing the process.

1 Like
#6

@cflurin, sorry for the sloppy language. MacOS uses control-c or command-. to send a SIGINT to the foreground process. NR should be able to handle this.

1 Like
#7

@drmibell,
Ok, I think node-red handles SIGINT.

Search in red.js for process.on:

process.on('SIGINT', function () {
    RED.stop().then(function() {
        process.exit();
    });
});

You can add a RED.log to test it on your mac:

process.on('SIGINT', function () {
    RED.log.info('SIGINT');
    RED.stop().then(function() {
        process.exit();
    });
});
1 Like
#8

@cflurin Exactly right. Both SIGINT on a mac and node-red-stop on a pi should produce an orderly shutdown of NR. According to a previous discussion,

This does not seem to happen. @Paul-Reed observed that context that is supposed to persist does not, and I was just offering another example.

#9

@drmibell,
Let's see what the node-red team think about that.
Because of this in the node.js doc:

SIGINT from the terminal is supported on all platforms, and can usually be generated with <Ctrl>+C (though this may be configurable). It is not generated when terminal raw mode is enabled.

I suggested to add RED.log.

#10

Also the Pi systemd service is set

# Use SIGINT to stop
KillSignal=SIGINT

So node-red-stop should def be calling a SIGINT... which should be calling an orderly stop.

1 Like
#11

Sorry for the diversion through Macintosh-land. I don't think there is any question that I'm getting a clean shutdown of NR. The console shows:

12 Dec 04:45:38 - [info] Stopping flows
12 Dec 04:45:38 - [info] Stopped flows

Examining the files in $HOME/.node-red/context shows that they have not been updated.

2 Likes
#12

The same here:

Starting as a systemd service.
Started Node-RED graphical event wiring tool.
12 Dec 11:10:34 - [info]
Welcome to Node-RED
===================
12 Dec 11:10:34 - [info] Node-RED version: v0.19.5
12 Dec 11:10:34 - [info] Node.js  version: v8.14.0
12 Dec 11:10:34 - [info] Linux 4.14.79-v7+ arm LE
12 Dec 11:10:35 - [info] Loading palette nodes
12 Dec 11:10:44 - [info] Dashboard version 2.12.2 started at /ui
12 Dec 11:10:45 - [info] Settings file  : /home/pi/.node-red/settings.js
12 Dec 11:10:45 - [info] Context store  : 'default' [module=localfilesystem]
12 Dec 11:10:45 - [info] Context store  : 'memoryOnly' [module=memory]
12 Dec 11:10:45 - [info] User directory : /home/pi/.node-red
12 Dec 11:10:45 - [warn] Projects disabled : set editorTheme.projects.enabled=true to enable
12 Dec 11:10:45 - [info] Flows file     : /home/pi/.node-red/flows_rpi4.json
12 Dec 11:10:46 - [info] Server now running at http://127.0.0.1:1880/
12 Dec 11:10:46 - [info] Starting flows
12 Dec 11:10:49 - [info] Started flows
1 Like
#13

I just verified this (in OSX)

  1. in terminal, start NR
  2. create a simple flow (attached below) - an inject to two change nodes - each change node to a seperate debug node
  3. set one change node to use a flow variable the other uses a global variable.
  4. deploy and press the inject and use the 'context data' to examine the contents.
  5. as soon as you see the timestamp in the context data, press the inject again and then swap to the terminal and press CTRL-C

If you go edit .node-red/context/global/flobal.json you will see the contents which you can compare against the debug. Here is what I see:

26%20AM

HERE SI THE FLOW:

[{"id":"78088df5.2fd3b4","type":"inject","z":"488e1c5.d552c64","name":"","topic":"","payload":"","payloadType":"date","repeat":"","crontab":"","once":false,"onceDelay":0.1,"x":140,"y":200,"wires":[["54316793.93ec58","ecf6671d.852d8"]]},{"id":"54316793.93ec58","type":"change","z":"488e1c5.d552c64","name":"","rules":[{"t":"set","p":"timestamp","pt":"global","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":400,"y":180,"wires":[["38182ee9.bf1872"]]},{"id":"ecf6671d.852d8","type":"change","z":"488e1c5.d552c64","name":"","rules":[{"t":"set","p":"timestamp","pt":"flow","to":"payload","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":390,"y":240,"wires":[["35e6ac92.ee3d14"]]},{"id":"38182ee9.bf1872","type":"debug","z":"488e1c5.d552c64","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":680,"y":140,"wires":[]},{"id":"35e6ac92.ee3d14","type":"debug","z":"488e1c5.d552c64","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":670,"y":260,"wires":[]}]
Error on stop/restart
#14

Probably time to move this to an issue please.
(with all that detail)
It would also be useful to run with logging level set to debug as it should log when it flushes at debug level.

#15

Will do - by issue you mean on GitHub?

#16

yes on github

#17

done! here is the link https://github.com/node-red/node-red/issues/2001

2 Likes