Unable to login to node-red after PM2 install

[Paul Reed]

I removed the existing init.d node-red script, and followed the PM2 installation guide, which I presume is the recommended process for v0.10.4 

However, following a reboot I am unable to log into the ui.

The node-red-error-0.log shows;

Potentially unhandled rejection [1] Error: EACCES, open '/usr/local/lib/node_modules/node-red/.sessions.json'

I did not specify the '--userDir' option (because I wasn't sure what it meant!) - could this be the problem? My user data is stored in the default home/.node-red folder

Paul

[Dave C-J]

Paul,

yes that should fix it - the .sessions.json file gets written to the userDir.

Though I'm intrigued why it's trying to access it there if it is loading the flows OK from ~/.node-red (or is it not loading them ?)

[Nicholas O'Leary]

Hi Paul,

--userDir tells node-red where to store your data.

If you don't specify it, it tries to use various default values. In some very particular circumstances, those defaults result in node-red trying to write somewhere it doesn't have permission to.

So, first you need to delete the existing pm2 entry for node-red:

    pm2 delete node-red

then, redo the pm2 start command you ran previously, but with "--userDir /path/to/your/.node-red/directory" added on the end.

Nick

--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Reed]

When I run;

pm2 start /usr/local/bin/node-red --node-args="--max-old-space-size=128" --userDir /home/pi/.node-red -- -v

I get

error: unknown option `--userDir'

[Dave C-J]

the userDir one needs to be at the end :-)

--

http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

regards

Dave Conway-Jones

[Dave C-J]

Paul - the way PM2 works is it wants its parameters first (of which the node-args are then passed down to the underlying node process) - then it passes anything after a double hyphen -- to the app (Node-RED) - so in this case -v and --userDir /home/pi/.node-red

(but I still think we may have a bug in that the original log you sent said userDir was home/pi/.nodered anyway... so ... we obviously aren't honouring that correctly for that .sessions file...

[Julian Knight]

I never could work out those parameter passing weirdness with either Forever or PM2.

Thankfully, you've engineered NR so well, we can just put those settings in the settings file instead!! :)

[Nicholas O'Leary]

assuming node-red finds your settings file.... ;)

--

[Dave C-J]

Julian, 

thanks - but I don't think we're quite out of the woods yet :-)

[Paul Reed]

$ pm2 start /usr/local/bin/node-red --node-args="--max-old-space-size=128" -- -v --userDir /home/pi/.node-red

was accepted without error, but after a reboot I still cannot login to the UI.

[Nicholas O'Leary]

anything in the log?

if you saw the thread yesterday regarding "bcrypt vs bcryptjs", it can take ~20 seconds to verify a password on the Pi currently.... something we'll improve in the next release.

N

[Paul Reed]

I've left the login thinking since the last post, so I don't think that I'm leaving it long enough.

In the log, I get;

...lots of previous normal entries - followed by...

node-red-0 (out): 8 Mar 22:22:08 - [info] [inject:17331dbf.e8cce2] crontab = 00 00 * * *

node-red-0 (out): 8 Mar 22:22:08 - [info] [inject:29e3e39b.d61c1c] crontab = 00 08 * * *

node-red-0 (out): 8 Mar 22:22:08 - [info] [inject:NOAA Weather] repeat = 300000

node-red-0 (out): 8 Mar 22:22:08 - [info] [inject:Emoncms temp] repeat = 300000

node-red-0 (out): 8 Mar 22:22:08 - [info] Started flows

node-red-0 (err): Potentially unhandled rejection [1] Error: EACCES, open '/home/pi/.node-red/.sessions.json'

[Nicholas O'Leary]

You need to check the permissions/ownership of the .sessions.json file - my guess it has been created by root at some point, but now you're running as the pi user, so you don't have permission to modify the file. This may affect other files in that directory, so the quick fix is to change the ownership of everything in there to the pi user:

Quick fix should be:

   chown -R pi /home/pi/.node-red

N

[Paul Reed]

Thanks Nick, that got me access to my ui again!

However, I've noticed that one on my flows which has worked well for the past 6 months is now creating an error since I started PM2 and forces node-red to restart every time the flow runs.

node-red-0 (out): 8 Mar 23:25:32 - [red] Uncaught Exception:

node-red-0 (out): 8 Mar 23:25:32 - Error: EACCES, open '/var/www/pictures/current_con.gif'

PM2: 2015-03-08 23:25:33: App closed with code: 1

PM2: 2015-03-08 23:25:33: App name:node-red id:0 exited with code 1

PM2: 2015-03-08 23:25:33: Starting execution sequence in -fork mode- for app name:node-red id:0

PM2: 2015-03-08 23:25:33: App name:node-red id:0 online

The flow gets weather data from wunderground.com and also downloads a weather icon image file from the same source.

[{"id":"d820bfe6.27df4","type":"function","name":"Weather calcs","func":"var weatherSTR = msg.payload.response.current_observation[0];\nvar rainin = weatherSTR.precip_1hr_in[0];\nvar rainmm = Math.round(rainin * 254); //convert to mm x 10\nvar raindayin = weatherSTR.precip_today_in[0];\nvar raindaymm = Math.round(raindayin * 254); //convert to mm x 10\nvar iconURL = weatherSTR.icon_url[0];\n\n\nmsg.payload = ((rainmm) + (\",\") + (raindaymm));\n//and msg2 is the weather icon URL\nmsg2 = { payload: iconURL };\nreturn [msg,msg2];","outputs":"2","x":628,"y":270.5,"z":"3f1992f2.c0e66e","wires":[["58b6c9e1.a74938"],["bd46f6d1.42b908"]]},{"id":"3ebc476d.c143b8","type":"inject","name":"Get Conditions","topic":"","payload":"6803e94c3cc08f6a/conditions/q/pws:IENGLAND539.xml","payloadType":"string","repeat":"","crontab":"","once":false,"x":109.00000762939453,"y":270.5000066757202,"z":"3f1992f2.c0e66e","wires":[["7eb287c6.814d78"]]},{"id":"d72d8ac.f28d278","type":"function","name":"Download weather icon","func":"var fileURL = msg.payload;\n//var dest = (\"../../../var/www/pictures/current_con.gif\");\nvar dest = (\"/var/www/pictures/current_con.gif\");\nvar fs = context.global.fs;\nvar http = context.global.http;\n\nvar file = fs.createWriteStream(dest);\nvar request = http.get(fileURL, function(response) {\n  response.pipe(file);\n});\n//pass msg out for debug, etc.\nreturn [msg];","outputs":1,"x":411.75,"y":312.5,"z":"3f1992f2.c0e66e","wires":[["20f9bf5f.df064"]]},{"id":"58b6c9e1.a74938","type":"debug","name":"","active":false,"complete":false,"x":817,"y":309.75,"z":"3f1992f2.c0e66e","wires":[]},{"id":"20f9bf5f.df064","type":"debug","name":"","active":false,"complete":false,"x":602.25,"y":312.25,"z":"3f1992f2.c0e66e","wires":[]},{"id":"bd46f6d1.42b908","type":"delay","name":"Rate Limit","pauseType":"rate","timeout":"5","timeoutUnits":"seconds","rate":"1","rateUnits":"hour","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":true,"x":206,"y":313,"z":"3f1992f2.c0e66e","wires":[["d72d8ac.f28d278"]]},{"id":"fc9c3a28.0363c8","type":"xml","name":"Convert XML","x":471,"y":270,"z":"3f1992f2.c0e66e","wires":[["d820bfe6.27df4"]]},{"id":"7eb287c6.814d78","type":"http request","name":"wunderground.com","method":"GET","url":"http://api.wunderground.com/api/{{{payload}}}","x":290,"y":270,"z":"3f1992f2.c0e66e","wires":[["fc9c3a28.0363c8"]]}]

[Nicholas O'Leary]

The file in that location would previously have been written by root... so again, same as before, you need to allow the pi user write access to that file.

chown pi:pi /var/www/pictures/current_con.gif

(no need for the -R option this time as you're modifying a single file).

As an aside, if you change your Weather Calcs function to set msg2 like this:

    msg2 = { url: iconURL };

Then you can replace that "Download weather icon" function node with this:

[{"id":"1f1659fd.e0e9a6","type":"http request","name":"","method":"GET","ret":"bin","url":"","x":473,"y":379,"z":"396c2376.c693dc","wires":[["f60586e5.09fa78"]]},{"id":"f60586e5.09fa78","type":"file","name":"","filename":"/tmp/weather.gif","appendNewline":false,"overwriteFile":"true","x":640,"y":380,"z":"396c2376.c693dc","wires":[]}]

This is an http request node that will retrieve the icon (based on the url property of the received message, ie msg2, hence why the change from payload to url). The http node was updated a while ago so you can request a binary payload from it - suitable for downloading images for example. This can then be passed to the file output node. (you'll need to change the file output node to point to the location you want...)

This then removes the need to having fs/http in global context (assuming you aren't using them else where...)

N

--

[Paul Reed]

That got the flow running again!

I'll make the other changes to the flow tomorrow - after I've regrouped!

Thanks for the support Nick/Dave

Paul

[Dave C-J]

Now also raised as Issue #586  https://github.com/node-red/node-red/issues/586

(for the original problem)

[Paul Reed]

Apart from the permissions issue, the wording of the docs page derailed me;  

"Note: if you want to run as the root user, you must use the `--userDir` option to specify where Node-RED should store your data."

Most node-red user I assume would understand what that means, but I didn't!!

Paul

[Nicholas O'Leary]

Paul - thanks for the feedback.

The --userDir option is explained further up the page - http://nodered.org/docs/getting-started/running.html#storing-user-data - could you have a read of that and let me know if that helps at all?

Nick

--

[Paul Reed]

Not really, but probably my lack of knowledge regarding terminology. For example;

'By default, Node-RED stores your data in the directory $HOME/.node-red'    and

'To override what directory to use, the --userDir command-line option can be used.'

...suggested to me that if I used the default data directory (which I did), then I did not need to use the --userDir command to override it. But this is just my interpretation - nobody else seems to have had problems!

Paul

[Nicholas O'Leary]

Your interpretation is correct - you should not have needed to specify the --userDir option.

But as Dave mentioned, there is a particular issue with the sessions file and it getting created in the right location - for which he has raised issue #586. This will only affect instances using the new adminAuth feature under certain circumstances. I think you just got unlucky.

I suspect that once we fix that issue, you would no longer need to use the --userDir option... although now you're running, it does no harm to have it there.

Nick

--