When I try to run Node Red it gets to a point and the log reports "Killed" and loading of Node Red stops. I was modifying code however I was not doing anything so major as to cause this problem (I was adjusting colors and icons on some Dashboard items).
I tried to run update-nodejs-and-nodered (which I have many times before) and now I'm getting 'command not found' no matter which directory I'm in when I call it (IE: .node-red)
'npm audit fix' returns the following:
npm ERR! code ELOCKVERIFY
npm ERR! Errors were found in your package-lock.json, run npm install to fix them.
npm ERR! Missing: growl@^1.10.5
npm ERR! Missing: hoek@^5.0.4
npm ERR! Missing: karma@^3.1.0
npm ERR! Missing: mdns@^2.4.0
'npm install' returns the following:
npm WARN .node-red No description
npm WARN .node-red No repository field.
npm WARN .node-red No README data
npm WARN .node-red No license field.
audited 11572 packages in 30.956s
13 packages are looking for funding
run npm fund for details
found 248 vulnerabilities (124 low, 36 moderate, 88 high)
run npm audit fix to fix them, or npm audit for details
Any suggestions? Oh, BTW, Nick, it'd be nice to see the command node-red --safe added to the initial start up info because it is not intuitive and when not used for a while it takes some time to remember "What was that command again?" I keep trying to use node-red-safe and node-red--safe .
No problem zenofmud, I do that as well, too often.
Colin, I agree. I think I'll hold off a bit before I do that. The frustrating thing is I have no indication in this case of what happened to cause this. The last lines in the log before KILLED was this:
15 Apr 09:06:52 - [warn] [function:Process Alarm On / Off] 1
nodered.service: Main process exited, code=killed, status=9/KILL
nodered.service: Unit entered failed state.
nodered.service: Failed with result 'signal'.
nodered.service: Service hold-off time over, scheduling restart.
Ok I ran the commands you suggested (thanks for that Colin), a lot of things seemed to happen (took some time) yet I seem to have the same problem (same log messages). I suspect whatever issues (if any) existed with Node Red itself may be straightened out now and I'll have to dive into the code to ferret out what is causing this.
It could be an inadvertent line or character somewhere not obvious left by a cut and paste, I've had that before (but usually I know what node I was last into). This is gonna take some time though, sigh. I'll have to delete tab by tab until I at least now where to start.
I'd have to confirm that is still the error as now I've done things to Node Red (your command suggestions) and I need to replace the error filled flows_?????.json into .node-red to have it crash again. I've been making sure the version I'm running (without that tab) is 100% solid before I did that. I'll advise.
SOLVED: This tab has many MQTT controlled switches that ea have 5 possible states to manage and be displayed on their respective ui_button (not switch) in Dashboard:
Scheduled Off (if on, will turn off next scheduled on time)
Scheduled On (if off, will turn on next scheduled on time)
Hard On (forever on)
Hard Off (forever off)
Offline (disconnected or hydro fail)
Each time a button is clicked in Dashboard the node(s) (and Dashboard labeling) cycle through the first 4 states so a user can set the switch however they need. Each switch process needs to control the switch and set the scheduler (auto / manual). The challenge is the state of these switches can be altered by many different sources:
Dashboard button click
A user manually changes the switch at site
Scheduler changes switch state
Power outage / restore
and the Dashboard must always properly represent the actual switch state regardless of the source of change.
All that to explain there is much parsing of MQTT traffic and a ton of context variables. I think the problem was that I misassigned / applied some variables in such a way that certain return statements could get confused. That's a guess on my part because I went over the code very meticulously and found the errors, set them straight and now am back to stable operation. This explains why it happened when I was doing simple stuff, it wasn't until certain processes got called that the problem was created.
However that is not the recommended way of using node context, and this snippet of code demonstrates why I virtually never use global or flow context for such purposes. Much better to pass data about in messages where it belongs.