So I've read two different perspectives and I'm trying to figure out which one is right.

1) Some sources online say that signals sent from the controlling terminal are ONLY sent to the foreground process group. That means if want a process to continue running in the background when you logout it is sufficient to simply suspend the job (ctrl-Z) and resume it in the background (bg). Then you can log out and it will continue to run because SIGHUP is only sent to the foreground job.

See: http://blog.nelhage.com/2010/01/a-brief-introduction-to-termios-signaling-and-job-control/

...In addition, if any signal-generating character is read by a terminal, it generates the appropriate signal to the foreground process group....

2) Other sources claim you need to use the "nohup" command at the time the program is executed, or failing that, issue a "disown" command during execution to remove it from the jobs table that listens for SIGHUP. They say if you don't do this when you logout your process will also exit even if its running in a background process group.

For example: http://docstore.mik.ua/orelly/unix3/upt/ch23_11.htm

...If I log out anyway, the shell sends my background job a HUP signal...

In my own experiments with Ubuntu linux it seems like 1) is correct. I executed a command: "sleep 20 &" then logged out, logged back in and pressed did a "ps aux". Sure enough the sleep command was still running.

So then why is it that so many people seem to believe number 2? And if all you have to do is place a job in the background to keep it running why do so many people use "nohup" and "disown?"

  • 1
    I think maybe I found the answer, here: serverfault.com/questions/117152/… - it seems that BASH by default will receive the SIGHUP signal sent from the controlling terminal but then not re-send it along to its child processes unless the "huponexit" shell option has been set. – asolberg Nov 13 '12 at 0:12
  • 3
    I suspect that the answer is that different versions of *nix (and, perhaps, different shells, and maybe even different versions of them) may actually behave differently. “Standards are good, so we should have many of them!” :) – Scott Nov 13 '12 at 21:26

Your Answer

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

Browse other questions tagged or ask your own question.