I have globally installed a single instance of node-red on a Deb 11 box.
My setup has grown organically, as follows:
I have one environment running via systemctl - port 1880
I have two further environments running via pm2 - ports 1881, 1882
All three environments have their own working folders in:
/home/<username>/<folder>
The two PM2 environment config files are pointing to the global install path of NR.
I have been experiencing a few glitches and am wondering if my setup is bad (not advisable).
To be clear, on the whole the 3x environments are running fine, but certain odd things are happening and I'm not sure if they are one-off glitches, something I've done or a consequence of a poorly designed setup.
What's been going wrong?
flows disappeared on the 2x PM2 ENVs when first setup, hasn't happened again
subflows on the 1880 ENV had code out of sync ie I made a code change, dropped a new subflow. The new subflow outputted the new code, the old subflow outputted the old code
Question(s):
What would a better setup be?
All 3x environments setup on PM2
Separate instances of node-red locally installed in the 2x PM2 folders
Separate instances of node-red locally installed in all 3x folders (1880, 1881,1882)
Something else
PS I don't want to move away from using PM2. It took some time to get right.
Thanks in advance, as always, for your help.
Oh, system was humming along fine all day today, so who knows if the issues will come up again.
And I'm happy to sit and test for some time days / week to see if anything pops up ie no rush to jump to something else right now, so treating this post as exploratory work for the time being.
PS: thank you to @marcus-j-davies for all your help in getting pm2 to work!
I know you say you don't want to move away from PM2 and I use it for my Windows based dev setup where I want node-red to auto restart on changes of various files. But really, other than that, it doesn't give much benefit and does come with some significant overheads. On Linux, for node-red instances that run permanently, I'd use multiple systemd scripts unless there was some other overriding factor.
As for running node-red globally vs locally, people will know my preference for running it locally due to ease of backup/restore, potentially increased security and greater control. Of course, that does come with increased disk usage but offsetting that is the ability to run different versions of node-red on each instance - great for testing new releases or needing to hang onto a previous release due to a clashing dependency.
However, even so, I've not experienced any of the issues you mention and wouldn't expect to do so even running multiple instances from a global install.
Unless another issue arises, I am sincerely hoping these were one off events that have some other explanation.
I can easily enough install node red locally, but why bother if the upside is running different versions as I want the exact opposite, keeping them in sync is more important to me.
I have places I can test new versions out.
Also, I backup flows and the whole disc, so don't need another backup process, although I will mull over what you wrote.
Most of my instances are already clones, so individual backups are off minimal value, so long as I have a master backup.
PM2 overhead - first I heard of that. I'll check resource usage more thoroughly, but when I was looking at resources the other day when installing mosquitto locally, it looked like almost nothing was being used by node red, as is always the case..... Though if that does become an issue, it will be a reason to move away. I'm more concerned right now with stability than performance.
If I get other weirdness, what should I do?
I plan to export the flows before trying to fix anything. I'll look for the log file and take a copy. Anything else?
The main real benefit to me is the control it gives, I can upgrade node-red without having sudo and if I want to dig into the node-red code or its dependencies, I don't have to go hunting for it. Also I don't have to find space to backup my whole server just to backup node-red. I keep 7 daily, 4 weekly and 12 monthly backups using a space efficient rsync process. I also get the added security of not installing node-red under root.
On Windows. Running under PM2 the committed memory us is 223,792kb. Running direct uses 140,616kb. Note though that I had several VSCode windows open so there are some instances of node.js that relate to those, obviously they are the same in each case.
Obviously, whether this concerns you depends on what server you are running on and what else is running as well as the complexity of your flows, how many nodes installed, how many people connecting, etc.
Even so though, if you are having some stability issues, removing complexity is a good starting point.
Start with a good backup!
Shut down Node-RED and make sure that what you think has happened, really has. For example, if you think that the flow file has disappeared, check on the filing system that it really has. And do a filing system search to see if something has moved the file somewhere else. Can't imagine how but hey, wouldn't be the first time I'd seen that.
Start to look through your flows and trim out things that aren't really being used. Then take out everything that isn't essential. Trying to get rid of some complexity so that you can see what is going on. Then walk through all of your flows to make sure that there isn't something rogue. For example, if you are loosing files, are you doing file-handling in your flows? That would be a good place to start looking.
Also check your settings.js file to make sure you aren't doing something odd in there.
Oh, and if you are doing folder/file-level backups - check the scripts to make sure they aren't doing something unexpected.
If all else fails, stand up a new instance of Node-RED and start transferring flows one by one, creating comms links back to the original instance. Giving time for things to settle between changes.
As a matter of interest why did you not use systemd for all three? That should just have been a matter of adding an additional service script for each node-red.
I have to be VERY careful whenever I set my mind to accuse my beloved NR of being unstable.
I've been digging deeper and I am going to put it ALL down to user error, although I can't be quite sure.
I think the flows disappearing were due to a naming convention issue, where the pi was not calling the flows.json file just that, flows.json.
As for the subflow issue, I looked through a back-up of my flows and saw that I had some ENV variables set on the "old" subflow that differ to the default. TBH, I can't even remember the code update right now, but I'm putting it down to user error for the time being, just to put my mind to rest.
All said and done, working off the assumption that the setup IS stable, unless something else goes awry and I can't pin back on me
Good news is I have a couple of options if there are any further issues and I can't pin-point them:
move over to systemsctl for all environments on the same machine
