0

I am just trying to start up a basic node.js server on a remote machine in a ssh session. This seems to work:

nohup node server/server.js &  disown

Maybe I don't need nohup? what's the "official" way to startup a background process that's not going to get killed by SIGTERM etc? I just want to start a background process then exit the session and have the process continue to run.

6
  • 1
    Neither nohup nor disown will do anything related to the TERM signal, only the HUP signal (nohup makes it ignore it and disown stops the shell form sending it, so using both is not needed). Could you expand on the "etc." at the end? – Kusalananda Aug 19 '19 at 20:09
  • sure, I just want to start a background process then exit the session and have the process continue to run – Alexander Mills Aug 19 '19 at 20:34
  • 1
    Have you considered using either tmux or GNU screen? – Kusalananda Aug 19 '19 at 20:40
  • 6
    ... or creating a proper system service? – Jeff Schaller Aug 19 '19 at 20:52
  • isn't a proper system service just using these types of facilities under the hood? can you add an answer showing one or the other? – Alexander Mills Aug 20 '19 at 18:41
3

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.

2
  • yes I hear tmux can also be used for this, is that the best option? – Alexander Mills Aug 20 '19 at 2:31
  • 2
    Yeah, I would just go with learning tmux. @AlexanderMills – Gordster Aug 20 '19 at 18:31
3
+25

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.

1

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.

3
  • yeah this is more of what I am looking for – user393961 Jun 11 '20 at 8:56
  • so I guess closing stdin was the main thing I was missing in the OP? – Alexander Mills Jun 11 '20 at 17:36
  • It's "correct" in the canonical sense, but often unnecessary. I notice that gnu nohup does this automatically anyway, but if on a non-Linux system, depending on how the process is written, results could vary (example: running ‘ssh host command‘ across many targets could be an example where you don't know/care about the OS) gnu.org/software/coreutils/manual/html_node/…. – michael Jun 11 '20 at 23:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.