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?

  • FYI: in general, these kinds of questions will probably be answered much faster on serverfault. – Mikeage Aug 16 '10 at 9:22
  • @Mikeage: What, just because it's about bash? – Hello71 Aug 18 '10 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 '10 at 6:10

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|||||

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
    This doesn't really answer my question, since redirection (without nohup) seems to be doing the same thing, as I described. – Yang Aug 13 '10 at 2:26

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.