11

I need to run a java program on my university servers. I'm remotely logging in through their servers via ssh

So I used nohup like so:

nohup java -jar project.jar &

However when I logout and close the terminal then log back into the server my process is missing/got killed off.

Braiam
  • 35,991
bigubosu
  • 213
  • Try redirecting stdout and stderr to some files - your process may be killed by signal other than SIGHUP, when trying to write to a closed terminal stdout/stderr. E.g. add >/dev/null 2>&1 to your command before & job sign. – Boris Burkov Apr 16 '14 at 14:12
  • 1
    @Bob shouldn't be necessary with nohup - most implementations will do this by default although it may be necessary to redirect stdin eg </dev/null. – Graeme Apr 16 '14 at 14:27

4 Answers4

15

nohup only make program immune to SIGHUP and SIGQUIT signal. Modern shell maybe send other signals when you logout from your session, so there is no guarantee that your program is not killed, even running under nohup.

The better solution is using tmux or screen, or if you use bash, you can try:

$ java -jar project.jar &
$ disown
cuonglm
  • 153,898
  • If you use disown, you need to redirect manually, eg add </dev/null &>/dev/null – Graeme Apr 16 '14 at 14:23
  • @Graeme: I think if we don't work with the shell anymore (just run command and exit), there is no need to redirecting. – cuonglm Apr 16 '14 at 14:26
  • Try ssh localhost 'sleep 10m & disown'. bash won't exit. – Graeme Apr 16 '14 at 14:30
  • Ok it seems to be ssh that doesn't exit if there are programs connected to the terminal. However, the above is fine if you run interactively. – Graeme Apr 16 '14 at 14:39
  • The Linux (GNU coreutils and busybox) and BSD implementations of nohup do not make the command immune to SIGQUIT, but only to SIGHUP. That would be explicitly against the standard and AFAIK may only happen on (some versions of?) Solaris. –  Dec 03 '19 at 07:32
13

Yet another option in place of the (chronically dysfunctional) nohup:

setsid java -jar project.jar </dev/zero &>/dev/null &

This effectively "daemonizes" the process. It is now owned by init, so will never get HUP'd, its I/O streams are safe, and it has been forked into the background.

See man setsid for more information. Unlike screen or tmux, this is not a program which claims ownership and continues to run. It simply starts a program in its own process group.

goldilocks
  • 87,661
  • 30
  • 204
  • 262
  • Why is nohup dysfunctional? – cpugeniusmv Apr 16 '14 at 16:10
  • @cpugeniusmv I'm sure it's good for something, however, I did not find it reliable for a purpose it is often recommended for, logging in somewhere, starting a process, and logging out (much like the OP). I guess it could have been misuse, and perhaps setsid is a little more idiot proof this way. It skips a step implied by nohup (having the process re-parented by init as an orphan). nohup would be more flexible if you potentially want to foreground the job later. – goldilocks Apr 16 '14 at 16:15
  • @TAFKA'goldilocks' I think the problem is in handling stdin, stdout and stderr, which is not really (but partly(!)) handled by nohup. Nohup does it's main job pretty well, shielding the process from SIGHUP. But there are lots of things that can go wrong with the streams - or, much worse, go wrong sometimes, depending on buffer sizes. I'd say, not nohup is wrong, but the expectation what nohup does. – Volker Siegel Apr 16 '14 at 20:29
  • Why is the </dev/zero &>/dev/null part necessary? – snorbi Dec 05 '23 at 07:06
  • It completes the detachment of the process from the parent context, which is, eg., ssh or a (pseudo) tty (or a pseudo tty in ssh). Those things are connected by the process's input and output streams; if you let this run in the foreground, its output would go to the console, and it would also have an input stream coming from the console -- connections that may now be abruptly broken (this is why nohup prevents the SIGHUP, "hang up signal", that happens when the parent process exits). I'm not completely sure my manual redirects are really necessary with setsid (which is.... – goldilocks Dec 06 '23 at 14:12
  • ....derived from the POSIX C function of the same name). Probably it is a bit paranoid but I have not found anything explicit stated one way or the other about it. – goldilocks Dec 06 '23 at 14:12
3

Another idea would be to use the screen command. It is possible to start a program withhin screen, detach and logout. Afterwards you can login and attach to the running screen session.

Tutorial: http://www.rackaid.com/blog/linux-screen-tutorial-and-how-to/

Tobias
  • 577
-2

Try running your nohup with STDOUT and STDERR redirect to null:

nohup java -jar project.jar 2>&1 &
boris quiroz
  • 395