[Bug 52] ssh hangs on exit

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=52





------- Comment #22 from sam_bravard at yahoo.com  2006-03-11 14:11 -------
Letting this bug languish for years without a solution isn't helping us (the
users).  We care about real-world use, and in real world use a hanging process
that I've asked to exit is an administration burden.  Auto-deploy/maintenance
scripts can't be run automatically without writing some sort of shootdown
watchdog, etc.

This patch solves a real need.  If you don't like the way this patch works,
then by all means create an alternate solution, but let's get the problem fixed
already.

If you must, create an option to make this behavior selectable or better yet an
environment variable.  Something that I can set and just leave on all the time.

It's not one author vs. openssh, there are easily thousands of ssh users that
want this fixed (hell I've just talked with 8 of them and everyone is shocked
to hear this is even a debate).  We'll accept loosing the last few bytes if we
can guarantee a disconnect.  

Please help us.

On behalf of the lowly users,

Sam

(In reply to comment #21)
> (In reply to comment #20)
> > That is in fact is the correct behaviour. Please check out how rsh and the
> > commercial ssh work: if the user types "exit" in a shell, all further I/O,
> > both reads and writes, are ignored. The rationale for this long-standing
> > convention is: if you want more I/O, don't type "exit"! 
> 
> The example test in Comment #19 *doesn't* do any IO after "dd" exits, but there
> is still data in the pipe/socket buffer that gets lost by your patch. The same
> applies to any interactive program that is producing data around the time it
> exits.
> 
> > > (set -e ; while [ 1 ] ; do
> > >     ssh -qttp2222 linux-qemu "dd if=/dev/zero bs=256k count=1" |
> > >     wc -c ; done)
> > 
> > Because you tried to be clever and pretend to be an interactive tty
> > session, even though you are not. 
> 
> You are completely missing the point. This is simple test to demonstrate that
> your patch loses data on ttys. 
> 
> A real-world mainfestation of this problem with your patch could be an
> interactive ncurses app's endwin() cleanups being truncated, resulting in a
> corrupted terminal state.
> 
> > I highly recommend it; it's about time that this silly bug be fixed once
> > and for all. Let's move forward now...
> 
> I'd love to see this bug fixed, but your patch introduces new problems. Just
> because you haven't noticed, or consider them relevant to you them doesn't mean
> that they don't exist.
> 




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