This is a followup to this question.
I've run some more tests; looks like it really doesn't matter if this is done at the physical console or via SSH, neither does this happen only with SCP; I also tested it with cat /dev/zero > /dev/null
. The behaviour is exactly the same:
- Start a process in the background using
&
(or put it in background after it's started usingCTRL-Z
andbg
); this is done without usingnohup
. - Log off.
- Log on again.
- The process is still there, running happily, and is now a direct child of
init
.
I can confirm both SCP and CAT quits immediately if sent a SIGHUP
; I tested this using kill -HUP
.
So, it really looks like SIGHUP is not sent upon logoff, at least to background processes (can't test with a foreground one for obvious reasons).
This happened to me initially with the service console of VMware ESX 3.5 (which is based on RedHat), but I was able to replicate it exactly on CentOS 5.4.
The question is, again: shouldn't a SIGHUP be sent to processes, even if they're running in background, upon logging off? Why is this not happening?
Edit
I checked with strace
, as per Kyle's answer.
As I was expecting, the process doesn't get any signal when logging off from the shell where it was launched. This happens both when using the server's console and via SSH.
Best Answer
Answer found.
For BASH, this depends on the
huponexit
shell option, which can be viewed and/or set using the built-inshopt
command.Looks like this options is off by default, at least on RedHat-based systems.
More info on the BASH man page: