Proper way to start a background process

screen and tmux certainly work but they are geared towards interactive sessions (often on remote computers) you want to disconnect and reconnect to. Since your application seems to be a server of some sort I would suggest to run it as a system service (often called "daemon") instead.

In the following I'm assuming you're using a system using systemd. All you need to do is create a unit file in /etc/systemd/system/foo.service:

[Unit] Description=My foo service After=network.target [Service] ExecStart=/usr/bin/node /absolute/path/to/your/server.js Restart=always User=nobody [Install] WantedBy=multi-user.target 

Modify the user as needed if your service needs to access files on your disk. Once the service file is in place run the following commands to ask systemd to reload its configuration files and run your service:

$ sudo systemctl daemon-reload $ sudo systemctl start foo.service 

You want to start it automatically during system start? Just enable it and you're all set:

$ sudo systemctl enable foo.service 

Running into problems? You can troubleshoot with the following commands:

$ systemctl status foo.service $ journalctl -u foo.service 

Regarding your requirement about preventing the service from being terminated/killed: I would say that's very difficult at the least. Even if your users don't have permission to kill your application your system might run out of RAM and the out-of-memory killer might decide to kill your service since it happens to be the one which is using RAM most aggressively. My suggestion would be to go with the Restart=always included in the above example instead which ensures systemd restarts the service when it crashes/exits.

You can use the screen command to save terminal sessions that can be accessed at a later time. This keeps you from having to kill processes that may be attached to a terminal session. So one example of how this is useful is if you were going to start a huge data transfer. You can start a screen session, start transferring the data, go home and ssh back into your work machine, and access the screen session without the transfer being interrupted

To install it:

sudo apt install screen for Ubuntu or Ubuntu variant

yum install screen Redhat or Redhat variant

you can then run

screen -S <screen name> to create new screen session

screen -ls list screen sessions

screen -r <screen name> attach to specific screen.

tmux is slowly replacing the screen command so I would recommend looking into that as well.

Just to add the simplest/obvious answer, for completeness & posterity (only difference here is closing stdin, otherwise it's the same as the example in the question, including redirect stdout/stdin syntax):

(1) If you don't care about stderr & stdout:

$ nohup {prog} </dev/null >/dev/null 2>&1 & 

(2) If you want to log stderr & stdout,

$ nohup {prog} </dev/null >/path/to/out.log 2>&1 & 

(3) If you want to log stderr & stdout to separate files,

$ nohup {prog} </dev/null >/path/to/out.log 2>/path/to/err.log & 

Rotate logs if you want to keep 'em; these examples will overwrite at every startup. Optionally name logs with a date, e.g., out-$(date '+%Y-%m-%d-%H:%M:%S').log Once you start going down that path,however, it's better to configure a service, as the other answers indicate, to let the system do the work for you. I do like screen / tmux, but only if I'm debugging a process that I want to actually reconnect the terminal eventually. Otherwise, I prefer background processes & logging.