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.

  • 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

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
  • 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

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.

  • 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

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/


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

nohup java -jar project.jar 2>&1 &
  • 1
    You're only redirecting stderr to stdout, which doesn't change anything about how nohup operates (it redirects both to nohup.out). – Gilles Apr 16 '14 at 22:39
  • 1
    -1, I think you meant nohup java -jar project.jar 2>/dev/null & but you obviously don't know what you are doing. Even better, also feed stdin /dev/null. – PlasmaPower Apr 17 '14 at 1:21
  • @PlasmaPower here you have your +1. Have a nice day :) – boris quiroz Apr 17 '14 at 2:42

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.