I have an Upstart script for my server that looks like this:
description "myapp node.js server"
start on runlevel [2345]
stop on shutdown
env NODE_ENV=production
env CUSTOM=somevalue
exec sudo -u nodejs /usr/local/bin/node /opt/myapp/app.js >> /var/log/nodejs/myapp.log 2>&1
post-start script
NODE_PID=`status myapp | egrep -oi '([0-9]+)$' | head -n1`
echo $NODE_PID > /var/run/nodejs/myapp.pid
end script
However, the app doesn't see NODE_ENV set to production. In fact, if I console.log(process.env) within the app, I don't see NODE_ENV or CUSTOM. Any ideas what's happening?
By the way, NODE_ENV=production node app.js works just fine.
visudo
has a line to define environment variables to be kept.and add your env to:
and reboot.
This has been working for me to set node env variables in upstart.
Just for the record. The Upstart Cookbook recommends the usage of
start-stop-daemon
instead ofsu
orsudo
when your Upstart version does not implementsetuid
.But, unless you are still using
10.04 LTS
(Lucid Lynx) which only has Upstart version 0.6.5, you should be using thesetuid/setgid
directives.From the sudo man page (Ubuntu version of sudo)
Sudo is resetting the environment. This is a frustrating aspect of using
su
andsudo
in upstart or init scripts. Recent versions of upstart support specifying uid/gid without the use of sudo via thesetuid/setgid
directives as in the example below. Also note the use ofchdir
.For older versions of upstart, here's what I used to do to work around it.
Note that I just put a
node_env.txt
file in my app root that sets production mode, because I hate environment variables. You can just doNODE_ENV=production
right there if you prefer.