4

In zsh, setopt nohup seems to be required to make nohup work, as follows:

# nohup does not work without setopt nohup ➜ /tmp zsh ➜ /tmp nohup watch ls & [1] 31556 nohup: ignoring input and appending output to ‘nohup.out’ ➜ /tmp exit zsh: you have running jobs. ➜ /tmp exit zsh: warning: 1 jobs SIGHUPed ➜ /tmp ps -fp 31556 UID PID PPID C STIME TTY TIME CMD # It works well with setopt nohup ➜ /tmp zsh ➜ /tmp setopt nohup ➜ /tmp nohup watch ls & [1] 31216 nohup: ignoring input and appending output to ‘nohup.out’ ➜ /tmp exit zsh: you have running jobs. ➜ /tmp exit ➜ /tmp ps -fp 31216 UID PID PPID C STIME TTY TIME CMD nori 31216 1 0 19:00 pts/6 00:00:00 watch ls

Why does zsh need setopt nohup since bash does not?

Improve this question
6
  • 1
    According to 3.18 in the FAQ you don't need it: "Note that you can always run programs with nohup in front of the pipeline whether or not the option is set, which will prevent that job from being killed on logout. (nohup is actually an external command.)" Commented Feb 15, 2015 at 5:17
  • 1
    I was actually able to keep a background task executing from zsh without the nohup option (only using the nohup executable). Output Commented Feb 15, 2015 at 5:21
  • @Bratchley That's the correct answer: without the nohup option the shell sends SIGHUP but the nohup command did its job so the signal is ignored. You should post that as an answer. Commented Feb 15, 2015 at 5:28
  • 1
    Well I think we may need more info from the OP so I know what I'm really answering. For instance, he doesn't really explain why he thinks it isn't working. That might be good to know since it seems to be an issue with expectations. Commented Feb 15, 2015 at 6:07
  • @Bratchley I thought nohup does not work because watch process seems to be killed. I'll update my question. Commented Feb 15, 2015 at 9:57

1 Answer 1

Reset to default
4

nohup is ineffective against watch because watch installs a signal handler for SIGHUP which overrides the one installed by nohup.

nohup works by setting the signal handler for SIGHUP to SIG_IGN which causes the signal to be ignored, and then it runs the program it was asked to run. This works well with target programs that leave the signals configured the way they were when they got started, which mainly means programs that pay no attention at all to signals. But watch installs a signal handler for SIGHUP and other signals (for the purpose of restoring the changes it makes to the terminal settings before it exits).

Improve this answer
1
  • Wow, I never thought it does not work because of watch. Thanks! Commented Feb 15, 2015 at 12:21

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.