This is more of a process management/signal handling question than a Bash question. It just uses Bash to explain the issue.
I'm running a Bash script in which I run a background process.
This is the script:
#!/bin/bash
# ...
# The background process
{
while :; do
sleep 1 && echo foo >> /path/to/some/file.txt
done
} &
# ...
exit 0
I do NOT run the script itself in the background. Simply ./script
.
The "huponexit" shell option is enabled using shopt -s huponexit
, therefore when the terminal is being closed I expect it to send a HUP signal to Bash, which will propagate it until it reaches the background process. If the background process will not trap
and ignore the signal, it will be killed too – but this is not happening. The background process acts as if it was disown
'ed.
This is a scheme I draw to illustrate the issue. The scheme, along with the description above, can be wrong as I'm sure I do not understand the subject well enough. Please fix me on that if it is truly the case.
I want to know why the background process is not being killed after closing the terminal, as if it was invoked by an interactive shell like that:
rany@~/Desktop$ while :; do sleep 1 && echo foo >> /path/to/some/file.txt; done &
I'm not sure but I guess that the answer to my question lies in the fact that Bash fork()s a non-interactive shell to run the script which might have a different set of rules for job control and signal handling.
Best Answer
So what does the man page tell us about
huponexit
?EDIT: Emphasizing that it is a LOGIN shell.
EDIT 2: interactive deserves equal emphasis