Fwd: Questions about SIGHUP behavior
Hi,
thanks for your detailed answer.
On Tue, Nov 12, 2013 at 6:02 PM, David F <debian@meta-dynamic.com> wrote:
> On 11/12/2013 07:35 AM, Steffen Dettmer wrote:
>>
>> 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.
>
> Short answer: I doubt that this ever worked as you think it did;
(I think at least when using a physical modem it should have been
worked, wasn't this what the signal was defined for?)
> Fast-forward to today: bash by default uses job control except when
> executing a script, and in the case of SSH, a pseudo-tty is used to simulate
> the "real" device and its driver [details at pty(7)].
Ahh yes, so this is the source of the SUGHUP delivered to the
shell, thanks for explaining.
> For the final piece of the puzzle, check the relevant section of bash(1):
> "The shell exits by default upon receipt of a SIGHUP. Before
> exiting, an interactive shell resends the SIGHUP to all jobs [...] If the
> huponexit shell option has been set with shopt, bash sends a SIGHUP to all
> jobs when an interactive login shell exits."
I did my tests all without changing huponexit, so I'd expect the
same behavior (I could understand whether bash always or never
resending SIGHUP, depending whether huponexit is applied to the
"exit caused by a signal")
> A little investigation with ps will show see why your sleep process didn't
> receive a SIGHUP: when job control is enabled, bash moves background jobs
> out of the foreground process group; they therefore won't receive a SIGHUP
But the shell process does receive a SIGHUP:
# ps -A -O sid,pgid|grep -e '\(sleep\|bash\)'
11702 11702 11702 S pts/0 00:00:00 -bash
11707 11702 11707 S pts/0 00:00:00 sleep 1h
root@NOMAD-BLN-R3200Xstd:~# strace -p 11702
Process 11702 attached - interrupt to quit
read(0, 0xbfa6975f, 1) = -1 EIO (Input/output error)
--- SIGHUP (Hangup) @ 0 (0) ---
--- SIGCONT (Continued) @ 0 (0) ---
[...]
kill(-11707, SIGHUP)
[...]
kill(11702, SIGHUP) = 0
sigreturn() = ? (mask now [])
--- SIGHUP (Hangup) @ 0 (0) ---
Process 11702 detached
In this test, it behaves like expected: bash gets SIGHUP and
resends to the background process group 11707 using
"kill(-11707, SIGHUP)".
I repeated this test (with and without strace) and noticed, that
in all cases when using strace, the background sleep process
terminate along with the SSH session and in cases when not using
strace in most (!) cases the sleep process continued to exist,
but I also found a few cases where the sleep process did
terminate.
> Note that had bash
> exited due to receiving a SIGHUP *itself* (which would happen e.g. if sshd
> died and released the pty), it would have delivered the SIGHUP to all of its
> jobs, foreground and background, which is one reason why you want to use
> commands like nohup, disown, etc. if you want to really be sure that your
> background commands continue to run even after you logout.
this was my assumption, but my observation is different.
I see several cases where I ended SSH using ~. causing SIGHUP to
be delivered to bash, but and a background process continued to
tun.
> ~ % ssh localhost
[...]
> ~ % exit
> logout
> Connection to localhost closed.
I think this does not lead to a SIGHUP delivered to bash, I think
you have to end SSH session using "~." or maybe closing the xterm.
My test a bit more in detail.
Client (with prompt "$") opens SSH session to test system (with
prompt "#"). On this pts/0, observation is made using "ps".
On a second xterm on the Client a second SSH session is opened
(pts/1) and the command "sleep 1h&" is issued.
On the first xterm, the ps command is issued.
Result: sleep 1h process exists.
On the second xterm, the SSH session is disconnected using SSH
escape "~.".
On the first xterm, the second ps command is issued.
Result: no sleep 1h process anymore.
Repeat.
On the first xterm, the ps command is issued.
Result: sleep 1h process exists.
On the second xterm, the SSH session is disconnected using SSH
escape "~.".
On the first xterm, the second ps command is issued.
Result: sleep 1h process still exists.
Here the transscript; the first xterm 18 space intended, I hope
that it reads better.
<second xterm> <first xterm>
$ ssh 172.22.9.1
#
$ ssh 172.22.9.1
# sleep 1h&
[1] 12147
# ps -A -O sid,pgid|grep -e '\(sleep\|-bash\)'
12132 12132 12132 S pts/0 00:00:00 -bash
12140 12140 12140 S pts/1 00:00:00 -bash
12147 12140 12147 S pts/1 00:00:00 sleep 1h
12149 12132 12148 S pts/0 00:00:00 grep -e \(sleep\|-bash\)
# Connection to 172.22.1.9 closed.
$
# ps -A -O sid,pgid|grep -e '\(sleep\|-bash\)'
12132 12132 12132 S pts/0 00:00:00 -bash
12151 12132 12150 S pts/0 00:00:00 grep -e \(sleep\|-bash\)
### (no sleep in ps)
### repeat
$ ssh 172.22.9.1
# sleep 1h&
[1] 12160
# ps -A -O sid,pgid|grep -e '\(sleep\|-bash\)'
12132 12132 12132 S pts/0 00:00:00 -bash
12156 12156 12156 S pts/1 00:00:00 -bash
12160 12156 12160 S pts/1 00:00:00 sleep 1h
12162 12132 12161 S pts/0 00:00:00 grep -e \(sleep\|-bash\)
# Connection to 172.22.1.9 closed.
$
# ps -A -O sid,pgid|grep -e '\(sleep\|-bash\)'
12132 12132 12132 S pts/0 00:00:00 -bash
12160 12156 12160 S ? 00:00:00 sleep 1h
12164 12132 12163 S pts/0 00:00:00 grep -e \(sleep\|-bash\)
### (sleep still in ps)
Maybe it is some race condition? Unfortunately trying to use
"strace" to see whats happening influences the behavior.
Regards,
Steffen
Reply to: