Setting Node_Env for Node.Js + Expressjs Application as a Daemon Under Ubuntu

setting NODE_ENV for node.js + expressjs application as a daemon under ubuntu

Try

exec NODE_ENV=production /usr/local/bin/node /where/yourprogram.js >> /var/log/node.log 2>&1

In my setup I'm sudoing as a lesser user, so it's

exec sudo -u some-user NODE_ENV=production /usr/local/bin/node /where/yourprogram.js >> /var/log/node.log 2>&1

and since it's spawning off another user it probably has another environment. I'm a newbie here, but it works for me.

Upstart env stanza not setting environment variables (like NODE_ENV) for Node.js application

From the sudo man page (Ubuntu version of sudo)

There are two distinct ways to deal with environment variables. By default, the env_reset sudoers
option is enabled. This causes commands to be executed with a minimal environment containing TERM,
PATH, HOME, SHELL, LOGNAME, USER and USERNAME in addition to variables from the invoking process
permitted by the env_check and env_keep sudoers options. There is effectively a whitelist for
environment variables.

Sudo is resetting the environment. This is a frustrating aspect of using su and sudo in upstart or init scripts. Recent versions of upstart support specifying uid/gid without the use of sudo via the setuid/setgid directives as in the example below. Also note the use of chdir.

start on filesystem and started networking
respawn
chdir /var/www/yourapp
setuid yourapp
setgid yourapp
env NODE_ENV=production
env PATH=/usr/local/bin:/usr/bin:/bin
env CUSTOM=somevalue
exec /usr/local/bin/node app.js | /usr/bin/multilog s1024000 /var/log/yourapp 2>&1

For older versions of upstart, here's what I used to do to work around it.

description "start and stop the example.com node.js server"

start on filesystem and started networking
respawn

chdir /path/to/your/code
exec su -c 'PATH=$PWD/node/bin NODE_ENV=$(cat node_env.txt) ./node/bin/node app/server.js' www-data  >> tmp/stdout.log 2>&1

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 do NODE_ENV=production right there if you prefer.

How to make a node.js application run permanently?

Although the other answers solve the OP's problem, they are all overkill and do not explain why he or she is experiencing this issue.

The key is this line, "I close putty, then I cannot reach the address"

When you are logged into your remote host on Putty you have started an SSH linux process and all commands typed from that SSH session will be executed as children of said process.

Your problem is that when you close Putty you are exiting the SSH session which kills that process and any active child processes. When you close putty you inadvertently kill your server because you ran it in the foreground. To avoid this behavior run the server in the background by appending & to your command:

node /srv/www/MyUserAccount/server/server.js &

The problem here is a lack of linux knowledge and not a question about node. For some more info check out: http://linuxconfig.org/understanding-foreground-and-background-linux-processes

UPDATE:

As others have mentioned, the node server may still die when exiting the terminal. A common gotcha I have come across is that even though the node process is running in bg, it's stdout and stderr is still pointed at the terminal. This means that if the node server writes to console.log or console.error it will receive a broken pipe error and crash. This can be avoided by piping the output of your process:

node /srv/www/MyUserAccount/server/server.js > stdout.txt 2> stderr.txt &

If the problem persists then you should look into things like tmux or nohup, which are still more robust than node specific solutions, because they can be used to run all types of processes (databases, logging services, other languages).

A common mistake that could cause the server to exit is that after running the nohup node your_path/server.js & you simply close the Putty terminal by a simple click. You should use exit command instead, then your node server will be up and running.

Setting up process.env variables using EXPORT while running node with sudo

To set process.env variable use the following code:

sudo PORT=80 node server.js

Of course, you can set multiple process.env variables:

sudo PORT=80 HOST=localhost node server.js

Normally, EXPORT should work too. But sudo creates its own environments and then starts your program as root. So, you shall either add PORT to sudo's environment or force it to preserve your own environment.

To change sudo's environment you shall modify /root/.profile.

To force it to preserve your own environment use -E key:

sudo -E node app.js

How does one start a node.js server as a daemon process?

Forever is answer to your question.

Install

$ curl https://npmjs.org/install.sh | sh
$ npm install forever
# Or to install as a terminal command everywhere:
$ npm install -g forever

Usage

Using Forever from the command line

$ forever start server.js

Using an instance of Forever from Node.js

var forever = require('forever');

  var child = new forever.Forever('your-filename.js', {
    max: 3,
    silent: true,
    args: []
  });

  child.on('exit', this.callback);
  child.start();

How do I run a Node.js application as its own process?

2016 answer: nearly every Linux distribution comes with systemd, which means forever, monit, PM2, etc. are no longer necessary - your OS already handles these tasks.

Make a myapp.service file (replacing 'myapp' with your app's name, obviously):

[Unit]
Description=My app

[Service]
ExecStart=/var/www/myapp/app.js
Restart=always
User=nobody
# Note Debian/Ubuntu uses 'nogroup', RHEL/Fedora uses 'nobody'
Group=nogroup
Environment=PATH=/usr/bin:/usr/local/bin
Environment=NODE_ENV=production
WorkingDirectory=/var/www/myapp

[Install]
WantedBy=multi-user.target

Note if you're new to Unix: /var/www/myapp/app.js should have #!/usr/bin/env node on the very first line and have the executable mode turned on chmod +x myapp.js.

Copy your service file into the /etc/systemd/system folder.

Tell systemd about the new service with systemctl daemon-reload.

Start it with systemctl start myapp.

Enable it to run on boot with systemctl enable myapp.

See logs with journalctl -u myapp

This is taken from How we deploy node apps on Linux, 2018 edition, which also includes commands to generate an AWS/DigitalOcean/Azure CloudConfig to build Linux/node servers (including the .service file).

How do I run a node.js app as a background service?

Copying my own answer from How do I run a Node.js application as its own process?

2015 answer: nearly every Linux distro comes with systemd, which means forever, monit, PM2, etc are no longer necessary - your OS already handles these tasks.

Make a myapp.service file (replacing 'myapp' with your app's name, obviously):

[Unit]
Description=My app

[Service]
ExecStart=/var/www/myapp/app.js
Restart=always
User=nobody
# Note Debian/Ubuntu uses 'nogroup', RHEL/Fedora uses 'nobody'
Group=nogroup
Environment=PATH=/usr/bin:/usr/local/bin
Environment=NODE_ENV=production
WorkingDirectory=/var/www/myapp

[Install]
WantedBy=multi-user.target

Note if you're new to Unix: /var/www/myapp/app.js should have #!/usr/bin/env node on the very first line and have the executable mode turned on chmod +x myapp.js.

Copy your service file into the /etc/systemd/system.

Start it with systemctl start myapp.

Enable it to run on boot with systemctl enable myapp.

See logs with journalctl -u myapp

This is taken from How we deploy node apps on Linux, 2018 edition, which also includes commands to generate an AWS/DigitalOcean/Azure CloudConfig to build Linux/node servers (including the .service file).

How to run Node.js as a background process and never die?

Simple solution (if you are not interested in coming back to the process, just want it to keep running):

nohup node server.js &

There's also the jobs command to see an indexed list of those backgrounded processes. And you can kill a backgrounded process by running kill %1 or kill %2 with the number being the index of the process.

Powerful solution (allows you to reconnect to the process if it is interactive):

screen

You can then detach by pressing Ctrl+a+d and then attach back by running screen -r

Also consider the newer alternative to screen, tmux.

---

Related Topics