http://bugzilla.mindrot.org/show_bug.cgi?id=52
------- Additional Comments From djm at mindrot.org 2002-01-23 17:37 -------
This is a known issue and has been discussed extensively on the mailings list.
There is difference of opinion as to whether this is a bug or whether it is
correct behaviour.
A good description of the issue comes from a text file in Redhat's source
RPM:
------------------------------------
About the hang-on-exit bug: this is the TODO item which shows up when you run
"ssh server 'sleep 20 & exit'". Feel free to add the text
directly to TODO (I
didn't, but only because it's a lot of detail that might not belong).
* The shell starts up, and starts its own session. As a
side-effect, it gets its own process group.
* The child forks off sleep, and because it's in the
background, puts it into its own process group. The sleep
command inherits a copy of the shell's descriptor for the
tty as its stdout.
* The shell exits, but doesn't SIGHUP all of its child PIDs
like it probably should.
* The sshd server attempts to read from the master side of the
pty, and while there are still process with the pty open, no
EOF is produced.
* The sleep command exits, closes its descriptor, sshd detects
the EOF, and the connection gets closed.
Attempts at fixing this in sshd, and why they don't work:
* SIGHUP the sshd's process group.
- The shell is in its own process group.
* Track process group IDs of all children before we reap them
(via an extra field in Session structures which holds the
pgid for each child pid), and SIGHUP the pgid when we reap.
- Background commands are in yet another process group.
* Close the connection when the child dies.
- Background commands may need to write data to the
connection. Also prematurely truncates output from some
commands (scp server, the famous "dd if=/dev/zero bs=1000
count=100" case).
Known-good workarounds:
* bash: shopt huponexit on
* tcsh: none
* zsh: setopt HUP (usually the default setting)
(taken from email from Jason Stone to openssh-unix-dev, 5
May 2001)
* pdksh: ?
This appears to affect rsh as well: it behaves the same with 'sleep 20 &
exit'.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.