Questions about SIGHUP behavior
Hi,
Debian 7.2 with /bin/bash as login shell (via /etc/passwd), shopt
huponexit off (as by default), bash run via SSH from other host.
When closing shell with CTRL-D, "sleep &" continues to run. I had
expected I had to use nohup, setsid, disown or a combination of them
in order to keep background jobs running after ending a shell session.
Was "shopt huponexit" used to be on in the past (or non-existing and
behaving like if it had been on) or do I incorrectly remember? I think
I remember correctly, otherweise the "nohup" tool would not be needed
and probably would not exist...
When closing shell with CTRL-D, "cat &" does not continue to run,
because it receives SIGTERM. I had expected it behaves like sleep. I
cannot test "nohup cat", because nohup also redirects inputs and thus
cat instantly terminates, but anyway nohup should not change behavior
of SIGTERM. Why are cat and sleep different? Note: in "strace sleep",
I don't see that file handles get closed, so it is not obviously
related to that, as I initially assumed.
When aborting SSH session with "~.", "sleep &" continues to run. I had
expected that the sshd process sends a SIGHUP to the process session,
but ps told that bash does not run in the process session as sshd, but
in an own session. strace shows that the bash process receives a
SIGHUP, but it does not send SIGHUP (but there is no "shopt huponhup
off"). As I understand the man page of bash, I had expected that bash
sends SIGHUP to all created process groups (i.e. my "sleep &"), unless
disown was used.
I tried to see who is sending the SIGHUP and ran strace on the parent
process sshd, but I saw now kill() invocation. To go for sure I even
ran strace on the parent parent process (the "master" sshd process),
but also saw no kill (but the SIGCHLD handling as expected). Where
does the SIGHUP received by "-bash" come from?
Best regards,
Steffen
Reply to: