Npm ERR! code ELOCKVERIFY

General
1

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 .

2

Did you try running nam install as it suggests?

3

Yes, rada next para in note lol.

4

Sorry read not rada.

5

Whoops, missed that :flushed:

did you run the entire curl command?

6

That is not used any more I don't think, Use the script from here.

If instead you want to try to fix the problem then run

cd .node-red
rm -rf node_modules
rm -f package-lock.json
npm install
7

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.

8

That means there is a problem with your package-lock.json. I edited my post to provide the commands that should fix it, but you may have missed that.

9

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.

10

UPDATE: Have narrowed it down now to the MQTT tab I created causing the problem however I have no idea yet as to why.

11

Are you saying something in the flow is causing the ELOCKVERIFY error? That seems very odd to me. Are you sure it is not a different error?

12

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.

13

As a matter of principle it is very important after doing anything to recheck what the error actually is. Always use node-red-stop, node-red-start and check the error which will be shown there.

14

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:

  1. Scheduled Off (if on, will turn off next scheduled on time)
  2. Scheduled On (if off, will turn on next scheduled on time)
  3. Hard On (forever on)
  4. Hard Off (forever off)
  5. 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.

15

Are you saying that caused the ELOCKVERIFY error? I am pretty sure that could only happen on startup.

16

The code would sometimes run for a bit before the error showed itself. The ELOCKVERIFY indication was a result of running npm audit fix.

I am wondering about something else though. Because the code was a bit complicated in places I put a couple of if () functions like this example:

if (!context.flow.sw2_online)  
{  
    context.flow.lbl_msg2 =   offline; 
    flow.set('switch2', context.flow.lbl_msg2);
    return [context.flow.lbl_msg2] ; 
}

... on one line in the editor, just to get it out of my focus (I know, I could've used the little arrow but didn't).

if (!context.flow.sw2_online)  {context.flow.lbl_msg2 =   offline; flow.set('switch2', context.flow.lbl_msg2);     return [context.flow.lbl_msg2];  }

Would that be a problem? Also, one other error I caught was a missing semi-colon after the return statement you see above (which was repeated for every switch).

17

Best not to do that.

No there should be no issue with putting a function on one line. Javascript doesn't care, provided you put the ;s in.
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.

18

Understood. And thanks very much for your help. BTW, if you have any sway, I'd still like to see

node-red --safe runs the editor only

in the start-up banner. Just sayin'.

19

I don't have any sway.

20

It's there as part of node-red -? or node-red --help

(you all have enough sway to raise a pull request)