[Bug 52] ssh hangs on exit

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Mon Mar 13 14:40:02 EST 2006


tsi at ualberta.ca changed:

           What    |Removed                     |Added
 Attachment #667 is|0                           |1
           obsolete|                            |

------- Comment #23 from tsi at ualberta.ca  2006-03-13 14:39 -------
Created an attachment (id=1098)
 --> (http://bugzilla.mindrot.org/attachment.cgi?id=1098&action=view)
Updated patch against 4.3p2

Well, one effective way for a user to become "lowly" is to believe one is in
the position to dictate.  Often, in such cases, there's money involved.

Attached is a rework of my prior fix, for 4.3p2 and to fix a few bugs I've run
into since then, including the race condition mentioned earlier.  This works
with all protocol versions and there is no data loss.

This version of the patch turns out to be quite small but you might wish to
recode its overloading of detach_close.

The intent here is to continue reading from the tty, after the child shell has
terminated, until there is an error.  On OpenBSD (and I suspect other
CSRG-based variants), that error will be EIO, whereas on Linux, IRIX, SunOS,
etc., it will be EAGAIN.  That's because SysV variants do not "close" the tty
when its controlling process exits.

The reason the hang doesn't occur on OpenBSD is that the tty's change of status
is reported through select(2), but isn't on SysV variants. 

Under compat20, this only affects the channel associated with the tty.  Thus,
if other channels are open (forwarding, etc.), the connection with the client
will remain open.

Damien, that `dd` command should redirect its stderr to /dev/null so you will
always get 262144.  A nitpick to be sure, but your posting was just the thing I
needed to duplicate the problem reliably enough to debug it.  Thanks.

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

More information about the openssh-bugs mailing list