What's the difference between nohup and ">& nohup.out &"?

Question

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?

Solution 1

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

Solution 2

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.

Comments

[Peter Olsson]

FYI: in general, these kinds of questions will probably be answered much faster on serverfault.

[JJ_Australia]

@Mikeage: What, just because it's about bash?

[Yang]

This doesn't really answer my question, since redirection (without nohup) seems to be doing the same thing, as I described.