5

nohup renders a process immune to the shell's SIGHUP, but even if I run this from my shell:

bash -c 'while true; do sleep 1; date; done' >& nohup.out &

then log out and log back in, bash is still running and producing output to nohup.out. Is there any difference? Is relying solely on redirection less reliable in any way?

Improve this question
3
  • FYI: in general, these kinds of questions will probably be answered much faster on serverfault.
    – Mikeage
    Aug 16, 2010 at 9:22
  • @Mikeage: What, just because it's about bash?
    – Hello71
    Aug 18, 2010 at 19:08
  • It's fairly Linux specific (and SF tends to have a hgiher percentage of linux users than SU), and this is the kind of things admins do daily.
    – Mikeage
    Aug 20, 2010 at 6:10

2 Answers 2

Reset to default
5

In bash backgrounded jobs do not need to be protected by nohup

Depending on your version of bash, the behaviour can be changed. In the SIGNALS section of the manual page

If the huponexit shell option has been set with shopt, bash sends a SIGHUP to all jobs when an interactive login shell exits.

The huponexit option defaults to off

Improve this answer
1

nohup allows you to disconnect the execution from the shell,

Nohuping backgrounded jobs is typically used to avoid terminating them when logging off from a remote SSH session. A different issue that often arises in this situation is that ssh is refusing to log off ("hangs"), since it refuses to lose any data from/to the background job(s).

This problem can also be overcome by redirecting all three I/O streams:
nohup ./myprogram > foo.out 2> foo.err < /dev/null &

Another reference to the SSH 'hangup' case.

Improve this answer
1
  • 1
    This doesn't really answer my question, since redirection (without nohup) seems to be doing the same thing, as I described.
    – xyzzyrz
    Aug 13, 2010 at 2:26

You must log in to answer this question.

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