Node-RED safe mode?

[Cory Guynn]

Is there a way to run Node-RED in a safe mode? 

I sometimes have issues with a flow that could cause chaos or max out the CPU. When its in this state, its difficult to load the editor to make any changes. I have to manually sift through the JSON flow and remove the offending parts there.

My Ask:

1) load editor without activating any flows

2) run editor and flows in different processes (which would be better for production systems as well.)

Cheers!

Cory

[Ben Hardill]

1) No

2) The editor already runs in a different process, it runs in the browser, where as the runtime is the nodejs process.

[Cory Guynn]

Thanks for the info.

Cheers

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/Ot9i83u5Dyw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+u...@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
For more options, visit https://groups.google.com/d/optout.

[Arnau Orriols]

1) No

I also think being able to boot in a "safe-mode" as Cory depicted would be a critically important feature to have. Is it being considered?

2) The editor already runs in a different process, it runs in the browser, where as the runtime is the nodejs process.

This is not entirely true. What runs in the browser is the UI of the editor. The backend of the editor runs in the NodeJS process, which is the same process where the flows are executed. When the runtime where the flows crashes, the editor crashes. 

 

[Dave C-J]

You can start Node-RED with a blank flow and then import your old flow without deploying it. OK so not immediately obvious but can be done.

If the backend crashes - what is in the browser does remain... so you can restart the backend - (or indeed re-start the backend with a blank flow) - and then deploy (save) to that just fine - so there is some separation... as long as you don't hit refresh :-)

[Ben Hardill]

No, the entire editor runs in the browser, when you hit deploy it just sends the flow as a single post to the back end to run. And as Dave said if you restart the back end the Editor will reconnect and let you send the current flow again.

 

 

[Arnau Orriols]

I completely understand your point. I think we are just talking from different points of view.  As example, let me share with you this example flow: http://pastebin.com/kZSuTfzU. If you ever deploy this flow, you'll need some sysadmin background to ever get your Node-RED editor to be able to deploy another (corrected) flow again. The editor, as you say, runs entirely in the browser. But the backend that stores the flows runs in the same process that executes the flows. If the flow's runtime enters an infinite loop, or quickly maxes out RAM memory, or whatever other cause of runtime blockage, the backend that stores the flows cannot receive any other flow correcting the bug.

How could this be improved? the backend of the editor could be decoupled into a dedicated Node.js process, communicating with the flows runtime though IPC. In this scenario the editor backend would still be able to deploy new flows and force the restart of the flows runtime, even if the later enters an infinite loop. This scenario would also make explicit my point that from a functional point of view, the editor, understanding it as the tool that gives the user the ability to CRUD the flows running in the server, has 2 parts, one running in the browser and the other in the server.

You can start Node-RED with a blank flow and then import your old flow without deploying it. OK so not immediately obvious but can be done.

This is actually not a bad idea. Dressed correctly with the proper UI should suffice. And it could even be said that it is actually a more explicit way to approach the situation than a "safe-mode"...