Node-Red Check Sessions Flow

Using Node-Red to monitor its sessions cache

UPDATE: It turned out that the initial solution presented here did not work properly and that the sessions cache was not always restored . I have found another solution, which is more robust and have updated this article with this solution.

Following up on my article series on Installing Node-Red as an intermediate layer between RFM interface and EmonCMS and Securing Node-Red as well as my use of this setup for a period of time, I feel that I should share some of the challenges that I have faced using this setup along with their resolutions. This is the first article about a specific such issue with an unknown number of articles yet to come.

Let’s start with some maintenance of Node-Red itself. If you have enabled username/password authentication in Node-Red and have moved the .sessions.json file to writable space – as described in my article on securing Node-Red – you might have experienced that the login feature can become unusable and that the user interface of Node-Red seems broken.

This situation only occurs for Node-Red installations with authentication enabled and where the sessions cache file has been replaced by a symbolic link pointing to another location on the file system.

This is actually caused by Node-Red (presumably) deleting its sessions cache file (.sessions.json), leaving the symbolic link, replacing the original file, pointing to nowhere. Then, when you try to open Node-Red it crashes because it cannot write to the dead symbolic link, which is a situation it is not designed to handle.

You can have Node-Red monitor the system for this situation and recover by itself before you accidentally break it by attempting to log in while the sessions cache file is missing. Because Node-Red does not provide advanced scripting functionality with means for accessing the file system this method requires an external script on the file system, which Node-Red can call using the exec node. The following block of code contains this script, which, upon execution, checks for the existence of the sessions cache file in writable space (/var/run/.sessions.json /var/run/nodered/.sessions.json) and re-creates it if it is missing.

#!/bin/bash

if [ ! -e "/var/run/nodered/.sessions.json" ]; then
  echo "/var/run/nodered/.sessions.json does not exist, restoring it .."
  if [ ! -d "/var/run/nodered" ]; then
    sudo mkdir /var/run/nodered
    sudo chown pi:pi /var/run/nodered
    chmod 777 /var/run/nodered
  fi
  touch /var/run/nodered/.sessions.json
  chmod 777 /var/run/nodered/.sessions.json
  chown pi:pi /var/run/nodered/.sessions.json
  if [ ! -e "/home/pi/.node-red/.sessions.json" ]; then
    ln -s /var/run/nodered/.sessions.json /home/pi/.node-red/.sessions.json
  fi
fi

Notice that there is no output from the script if everything is in order and that it prints a status text to stdout if the sessions cache, in writable space, is missing. This can be used to trigger the output of the exec node according to the state of the sessions cache.

For utility scripts that should be accessible from Node-Red I have created a folder in the .node-red sub folder of the pi user’s home folder named scripts (/home/pi/.node-red/scripts). The above script is saved as sessions.sh inside this folder and it is referred by an exec node, which you can find pre-configured and ready for import in Node-Red below.

[{"id":"97bb0e30.6844f", "type":"exec", "command":"~/.node-red/scripts/sessions.sh", "addpay":false, "append":"", "useSpawn":"", "name":"Check .sessions.json", "x":334, "y":204, "z":"22915660.dd6eaa", "wires":[["3a016410.c5fe9c"], [], []]}]

Having the script and the node configured is not enough for continuous monitoring, though, because the node will never be executed without something to trigger its input. For this I use an inject node, which is configured to fire a blank every 30 minutes and once at start. The chosen interval could be lower to minimise the risk of breaking Node-Red by attempting to log in while the sessions cache is missing – potentially, a period of up to 30 minutes allows for this scenario. A pre-configured inject node can be grabbed for import below.

[{"id":"7502fe64.8afd", "type":"inject", "name":"Trigger", "topic":"", "payload":"", "payloadType":"none", "repeat":"1800", "crontab":"", "once":true, "x":108, "y":204, "z":"22915660.dd6eaa", "wires":[["97bb0e30.6844f"]]}]

The last bit that remains to complete the monitoring of the Node-Red sessions cache is a way to handle the state where the sessions cache file is missing. In my flow the stdout output of the exec node goes to a function node that does nothing if its input is empty (the output of the exec node is empty) and, otherwise, forwards a message object with error information formatted for input to an e-mail node. This intermediate function node is necessary because I would otherwise receive an e-mail no matter what the output of the exec node would be. A pre-configured function node can be grabbed for import below.

[{"id":"3a016410.c5fe9c", "type":"function", "name":"Log status", "func":"if (msg.payload.trim().length>0) {\n    node.log(msg.payload);\n    return {\n        payload:msg.payload.trim(),\n        topic:\"Node-Red RPI system error\"\n    };\n} else\n    return null;","outputs":1, "noerr":0, "x":573, "y":106, "z":"22915660.dd6eaa", "wires":[["208cf2a.fdf730e", "4696dbc5.b96924"]]}]

Conclusion

This article describes another proof that running a low-write Linux distribution has its challenges. Although the real challenge here is not actually the low-write OS but the work around of replacing the Node-Red sessions cache with a symbolic link, which Node-Red does not expect.

The solution proposed here is not perfect, but can be quite easily improved by increasing the frequency with which the exec node is triggered. The important thing is to restore a missing sessions cache file before a user attempts to log in to Node-Red to prevent it from breaking. So, it would make sense to adjust the check interval according to the number of users of a given Node-Red installation – the more users, the more frequent to check, based on the assumption that the interval between logins is inversely proportional to the number of users. On the other hand, if there are enough users, Node-Red might never enter a state where it deletes its sessions cache file and thus this problem would not exist.

0 comments on “Using Node-Red to monitor its sessions cacheAdd yours →

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: