10

When I run these four commands on Xubuntu 16.04, either locally or over ssh, they all seem to do the exact same thing:

export DISPLAY=:0.0 #not necessary unless you have logged in over ssh instead of starting a terminal locally

  1. gedit &

  2. gedit & disown

  3. nohup gedit

  4. nohup gedit & disown

I don't get the the difference between gedit & and gedit & disown because if I kill the parent terminal or log out out of an ssh session, it would seem that gedit is "disowned" in either scenario.

As for two and three, the only difference I see is that the command output is logged to a separate file and will continue to be logged to that separate log even if the original shell session that spawned the bg process is killed.

As for three and four, I keep reading that there is a technical difference, but cannot understand at all why would you would prefer one over the other.

Which one should I use? I have seen all four commands used in tutorials and Q&As, and despite some really great answers describing the technical differences between nohup and disown, I can't seem to get a clear recommendation (except perhaps for logging purposes or shell compatibility) for which one I should use.

Improve this question
1
  • You need & in all cases where you want to continue in the shell (and the program does not fork itself). You might not need nohup for programs which close the file descriptors and disassociate themselves (that. Gibt be true for most GUI Applications). You can use disown after the fact (if you forget nohup) and as written before GUI apps don’t need it.
    – eckes
    Mar 11, 2018 at 21:42

3 Answers 3

Reset to default
11

When I need to run a script that will run for a long time, and I'm on an ssh session, I want either:

  1. The task should continue even when the network breaks or when I pack my laptop and go away.

    a. The task can finish without interactive input from me.

     nohup do_my_stuff &

    b. The task might need something from me on stdin.

     man tmux
 history -w
 tmux
 do_my_stuff

  2. The background process is somehow enhancing my current session and should die together with the session. A rarity.

     enhance_my_session  >>/tmp/enhance.$$.log 2>&1 &

  3. I want the thing to spit some logs randomly at my ssh session. Wait, what? No, I would never want that. Thank you disown.

  4. Another thing that I never want: convert the process to a fully detached daemon, but avoid starting it automatically at the next boot. I would never want that because I cannot predict when the system will reboot and who will be rebooting it.

Improve this answer
1

Typically, I just do the following:

  1. myprog & if I just want to run something in the background from my current login shell. This is adequate for me 99% of the time...

  2. nohup myprog > /my/path/output.txt & if I start something from the shell, but want to log out afterwards (perhaps while the background task is still running).

Improve this answer
0

You must tell apart exiting the shell from aborting the terminal.

  1. The shell kills all known jobs (but not their children) when it gets an abort signal.
  2. The terminal kills everything for which it was the controlling terminal.

In general the best solution (on user level) IMHO is screen.

If your task is rather system-related than user-related you might make it a systemd service instead which you start manually.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .