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

Question

I connect to the linux server via putty SSH. I tried to run it as a background process like this:

$ node server.js &

However, after 2.5 hrs the terminal becomes inactive and the process dies. Is there anyway I can keep the process alive even with the terminal disconnected?

---

Edit 1

Actually, I tried nohup, but as soon as I close the Putty SSH terminal or unplug my internet, the server process stops right away.

Is there anything I have to do in Putty?

---

Edit 2 (on Feb, 2012)

There is a node.js module, forever. It will run node.js server as daemon service.

Sidle

In my case nohup works when I exit Terminal by typing exit. When I just close Putty window it fails. – Pellet

Answer 1

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.

Salvidor

So, if I run "screen", I create the screen and run inside it, right? – Sidle

yes and then you can detach by pressnig Ctrl+a, d and then attach back by running screen -r – Salvidor

nohup doesn't work in EC2. I think because I need to run as root. but in EC2, we can't have root access. Using screen is much better choice. :) – Sidle

@Sidle EC2 is an environment and has nothing to do with root privilege. It's probably about the your AMI. For example with Amazon AMI you certainly can sudo bash. – Bertilla

@Salvidor Quick question on syntax: What does the ampersand at the end of the command do? – Damn

man bash:If a command is terminated by the control operator &, the shell executes the command in the background in a subshell. The shell does not wait for the com- mand to finish, and the return status is 0. – Salvidor

And the obvious follow-up, how do you run this automatically when the system first boots up? – Writer

@PsychoDad the answer to that is OS-dependent. The simplest way that often works is to add it to /etc/rc.local file – Salvidor

Please, to anyone reading this: running a node.js server inside a screen or tmux session is an AMATEUR solution! Don't do that, unless for quick tests. To keep a process running you need to daemonize it! Use proper tools for it, like forever, pm2 or the plain old init.d scripts. – Fuel

supervisor , it can restart itself. – Peres

I ran a process with nohup node server.js & and I can't stop server.js now. Everytime I kill it with "$ fuser -k 3002/tcp" it will restart again. Does anyone know how to kill the parent process? – Maternal

@VictorSchröder how is using a screen an amateur solution? I mean, does it work less efficiently or somehow slow things down or use up more memory or...? – Doretheadoretta

@TannerStrunk, why keep an interactive shell session and a full terminal multiplexer if the intent is just to keep the process running? It's an amateur solution because it's the wrong approach. And it's fragile, it doesn't work in the long run. In real life, I already had colleagues doing exactly this and it ALWAYS ended badly. "Why is my app offline?", "Where is my screen session?" and so on. Screen and Tmux are awesome, I use them literally everyday, but this is not what they were meant to. – Fuel

@VictorSchröder I was missing the fact that my situation is different from the above. In my problem, I needed to come back to processes and potentially interact later, and none of my processes should run forever. They just process some data, report the results, and await further instructions. Exiting my ssh on my laptop was just stopping my code. My screen sessions were easy to find, because I would name them distinctly with just numbers for each sample I was processing. Is screen still the wrong way to go in that scenario? (Maybe I should have just made a separate question...) – Doretheadoretta

@TannerStrunk, no this is totally different. If you need to interact with the process, you want to keep an interactive session around, but without the risk of network disruptions or simply with the possibility to disconnect your laptop. In this case, screen and tmux are the right tools for the job. – Fuel

Thanks for the options of solutions. Screen was actually the easiest for me although I'd like to get forever running. – Toneless

Answer 2

nohup node server.js > /dev/null 2>&1 &

1. nohup means: Do not terminate this process even when the stty is cut off.
2. > /dev/null means: stdout goes to /dev/null (which is a dummy device that does not record any output).
3. 2>&1 means: stderr also goes to the stdout (which is already redirected to /dev/null). You may replace &1 with a file path to keep a log of errors, e.g.: 2>/tmp/myLog
4. & at the end means: run this command as a background task.

Toussaint

This should be the accepted answer, because it is of much higher quality than the currently accepted one. – Bellina

@Bellina debatable, OP has demonstrated a level of understanding that litte further explanation is required for the accepted answer. – Benson

SO isn't about the OP as much as it's about the thousands of people coming to OP's question for help. – Bellina

Is it necessary to redirect stdout and stderr? Would it work just as well if I did not redirect them at all? Or if I redirected them to files instead? – Stokes

2>&1 precisely means: stderr shall go to where stdout currently goes (which in this case is /dev/null).This explains why the stderr redirect has to stand after the stdout redirect. – Spall

Send stdout AND stderr to /dev/null? Nice logging... Good luck trying to debug this... – Fuel

Even shorter it could be nohup node server.js &> /dev/null &. &> file is equivalent to > file 2>&1 – Centum

L0j1k, that is a terrible argument for why OP should change the accepted answer of their own question. If the alternative option of screen is relevant to the OP, then it should be part of the accepted answer. Explaining what every single tiny thing means on a command line seems more relevant to the unix stackexchange than to stackoverflow. – Spiteful

@VictorSchröder If the user understands the command, it doesn't matter. My plasmashell process keeps throwing up and I don't care to find the cause right now... So it's easy for me to nohup kstart plasmashell > /dev/null 2>&1 & because I don't care about logging. – Pigeonhearted

According with the original question, when in Putty I start node server.js is running okay but as soon I close the Putty session it stops. When I tried nohup, once close the Putty session it stops too. Seems that pm2 or forever goes like a charm! – Deragon

I use this command and the process still gets terminated when ssh connection to server is lost. anyone observed this as well? – Bellona

Answer 3

This is an old question, but is high ranked on Google. I almost can't believe on the highest voted answers, because running a node.js process inside a screen session, with the & or even with the nohup flag -- all of them -- are just workarounds.

Specially the screen/tmux solution, which should really be considered an amateur solution. Screen and Tmux are not meant to keep processes running, but for multiplexing terminal sessions. It's fine, when you are running a script on your server and want to disconnect. But for a node.js server your don't want your process to be attached to a terminal session. This is too fragile. To keep things running you need to daemonize the process!

There are plenty of good tools to do that.

PM2: http://pm2.keymetrics.io/

# basic usage
$ npm install pm2 -g
$ pm2 start server.js

# you can even define how many processes you want in cluster mode:
$ pm2 start server.js -i 4

# you can start various processes, with complex startup settings
# using an ecosystem.json file (with env variables, custom args, etc):
$ pm2 start ecosystem.json

One big advantage I see in favor of PM2 is that it can generate the system startup script to make the process persist between restarts:

$ pm2 startup [platform]

Where platform can be ubuntu|centos|redhat|gentoo|systemd|darwin|amazon.

forever.js: https://github.com/foreverjs/forever

# basic usage
$ npm install forever -g
$ forever start app.js

# you can run from a json configuration as well, for
# more complex environments or multi-apps
$ forever start development.json

Init scripts:

I'm not go into detail about how to write a init script, because I'm not an expert in this subject and it'd be too long for this answer, but basically they are simple shell scripts, triggered by OS events. You can read more about this here

Docker:

Just run your server in a Docker container with -d option and, voilá, you have a daemonized node.js server!

Here is a sample Dockerfile (from node.js official guide):

FROM node:argon

# Create app directory
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

# Install app dependencies
COPY package.json /usr/src/app/
RUN npm install

# Bundle app source
COPY . /usr/src/app

EXPOSE 8080
CMD [ "npm", "start" ]

Then build your image and run your container:

$ docker build -t <your username>/node-web-app .
$ docker run -p 49160:8080 -d <your username>/node-web-app

Always use the proper tool for the job. It'll save you a lot of headaches and over hours!

Snivel

This is what I was looking for. With the pm2 solution, is there a way to attach a terminal to it later? – Function

@Quantumplation, no. That is not possible because the process isn't running in an interactive session. But you can have the same "feeling" by tail -fing the log file that pm2 generates. – Fuel

You specify the screen solution which many people are finding does the job is a workaround. There are lots of ways of achieving a specific task. I believe it happens that (consider the specific question) it happens to be achieving the specific task of run as background and never die excelent for many. It also has the added bonus of allowing the user to go back into it to re-interact and make changes if he wants. The key is components is background and never die. All the solutions have certain bonuses. – Missis

@Rakshith Ravi - I disagree. These all require additional downloads/software/tools (except the init solution, to which no solution was given). The nohup is the solution. It's baked in to Linux, and is what it's there for. It's one line, it's clean, and it works as intended, everytime, regardless of updates. People should really try to avoid using third party tools for basic use cases such as this. The docker example (for example) is a lot more verbose and resource intensive than the one simple command in the top voted answer. Love Docker, but not for this. – Airspeed

@Jack_Hu, I have no doubts about the overhead, but the nohup solution doesn't satisfy the "never die" requirement. Unless you write a very tricky trap or a hacky infinite loop, I don't see how to keep the process daemonized without using tools specially written for this purpose (or an init script written by yourself, of course). – Fuel

I agree, I came here looking for linux start process background but the question really is about a Node process, thus I proposed an edit to the original title. – Wednesday

The accepted answer didn't work for me, pm2 worked perfectly thank you – Cnossus

Answer 4

You really should try to use screen. It is a bit more complicated than just doing nohup long_running &, but understanding screen once you never come back again.

Start your screen session at first:

user@host:~$ screen

Run anything you want:

wget http://mirror.yandex.ru/centos/4.6/isos/i386/CentOS-4.6-i386-binDVD.iso

Press ctrl+A and then d. Done. Your session keeps going on in background.

You can list all sessions by screen -ls, and attach to some by screen -r 20673.pts-0.srv command, where 0673.pts-0.srv is an entry list.

Hypertension

screen is designed to be used for interactivity; for non-interactive scripts, many would argue that nohup is the canonical solution. – Swimming

Answer 5

another solution disown the job

$ nohup node server.js &
[1] 1711
$ disown -h %1

Opus

disown is exactly what i was looking for, but what does -h flag do? I cant find it in manual – Keelykeen

from man page: If the -h option is given, each jobspec is not removed from the table, but is marked so that SIGHUP is not sent to the job if the shell receives a SIGHUP. If no jobspec is supplied, the -a option means to remove or mark all jobs; – Opus

Answer 6

nohup will allow the program to continue even after the terminal dies. I have actually had situations where nohup prevents the SSH session from terminating correctly, so you should redirect input as well:

$ nohup node server.js </dev/null &

Depending on how nohup is configured, you may also need to redirect standard output and standard error to files.

Chace

Answer 7

Nohup and screen offer great light solutions to running Node.js in the background. Node.js process manager (PM2) is a handy tool for deployment. Install it with npm globally on your system:

npm install pm2 -g

to run a Node.js app as a daemon:

pm2 start app.js

You can optionally link it to Keymetrics.io a monitoring SAAS made by Unitech.

Rendon

Answer 8

I have this function in my shell rc file, based on @Yoichi's answer:

nohup-template () {
    [[ "$1" = "" ]] && echo "Example usage:\nnohup-template urxvtd" && return 0
    nohup "$1" > /dev/null 2>&1 &
}

You can use it this way:

nohup-template "command you would execute here"

Leonleona

Answer 9

$ disown node server.js &

It will remove command from active task list and send the command to background

Botelho

Answer 10

Have you read about the nohup command?

Dozer

Answer 11

To run command as a system service on debian with sysv init:

Copy skeleton script and adapt it for your needs, probably all you have to do is to set some variables. Your script will inherit fine defaults from /lib/init/init-d-script, if something does not fits your needs - override it in your script. If something goes wrong you can see details in source /lib/init/init-d-script. Mandatory vars are DAEMON and NAME. Script will use start-stop-daemon to run your command, in START_ARGS you can define additional parameters of start-stop-daemon to use.

cp /etc/init.d/skeleton /etc/init.d/myservice
chmod +x /etc/init.d/myservice
nano /etc/init.d/myservice

/etc/init.d/myservice start
/etc/init.d/myservice stop

That is how I run some python stuff for my wikimedia wiki:

...
DESC="mediawiki articles converter"
DAEMON='/home/mss/pp/bin/nslave'
DAEMON_ARGS='--cachedir /home/mss/cache/'
NAME='nslave'
PIDFILE='/var/run/nslave.pid'
START_ARGS='--background --make-pidfile --remove-pidfile --chuid mss --chdir /home/mss/pp/bin'

export PATH="/home/mss/pp/bin:$PATH"

do_stop_cmd() {
    start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 \
        $STOP_ARGS \
        ${PIDFILE:+--pidfile ${PIDFILE}} --name $NAME
    RETVAL="$?"
    [ "$RETVAL" = 2 ] && return 2
    rm -f $PIDFILE
    return $RETVAL
}

Besides setting vars I had to override do_stop_cmd because of python substitutes the executable, so service did not stop properly.

Lorikeet

Answer 12

Apart from cool solutions above I'd mention also about supervisord and monit tools which allow to start process, monitor its presence and start it if it died. With 'monit' you can also run some active checks like check if process responds for http request

Coronary

Answer 13

For Ubuntu i use this:

(exec PROG_SH &> /dev/null &)

regards

Templar

Minor point: 'exec' is not needed if PROG_SH is an executable. The point of the solution proposed by David is to disassociate the child from the current running shell. The child's parent becomes 'pid 1' and will not be affected when the shell terminates. – Bithia

Answer 14

Try this for a simple solution

cmd & exit

Upstanding