Bash – On the desktop with Bash, should I use ‘&’, nohup, disown, or some combination of the three to start a process and have it run completely on its own

bashnohup

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.

Best Answer

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.

Related Question