ssh takes forever to interrupt-- known problem?

Chris Olin chris@chrisolin.com
Thu Oct 10 12:54:00 GMT 2013


On 10/10/13 at 03:29am, Don Hatch wrote:
> On Wed, Oct 09, 2013 at 10:51:58PM -0400, Larry Hall (Cygwin) wrote:
> > OK, I'm going to assume that 'sshd' was actually started when
> > you tried the latest rounds of tests.  If this wasn't the case, you have
> > another (probably non-Cygwin) SSH server running which is causing the
> > problem.  You'll need to shut that service down and start the Cygwin
> > one before trying again.
> 
> Right, if I want to connect to sshd on the windows machine,
> I start the cygwin sshd manually if I haven't already.
> However I can reproduce the problem with no cygwin sshd running at all,
> by ssh'ing from the cygwin/windows machine to a linux machine.
> 
> > 
> > Beyond that, you could try invoking invoking 'yes' through 'strace' and
> > see if the output there gives you any clues.
> 
> Tried that, on the linux machine I was ssh'ed into.
> What I found was:
>     - if I ctrl-c approximately 1/8 to 1/4 second after starting "yes",
>       the program receives it and is killed 2.5 seconds later,
>       but the output (about 62558 bytes of "y\n"s)
>       takes 30 seconds more to finish spewing.
>     - if I ctrl-c approximately 1 second after starting "yes",
>       the program receives it and is killed 5.25 seconds later,
>       but the output (about 119278 bytes of "y\n"s)
>       takes 57 seconds more to finish spewing.
> 
> So I'm thinking there's a buffer somewhere in all this
> that is (too) capable of quickly recieving and buffering a whole lot of data,
> but there's a bottleneck somewhere after that buffer
> that makes it take a long time for the data to dribble out to the terminal.
> I wonder where that buffer is, and if there's a way to decrease
> the buffer size so that output-bound programs will block sooner,
> for decreased throughput and increased interactivity,
> which would be what I want, I think.
>       
> > You could also try cutting
> > down your path to eliminate potential interactions.
> 
> I straced ssh when ssh'ing into the linux box...
> no programs were run other than c:\cygwin\bin\ssh.exe
> so that eliminates that possibility, right?
> 
> > try adding "detect_bloda" to your Cygwin environment variable to see if
> > it points to some conflicting program/service:
> > 
> > <http://cygwin.com/cygwin-ug-net/using-cygwinenv.html#cygwinenv-implemented-options>
> 
> Tried setting env CYGWIN=detect_bloda
> and ran ssh again, didn't see anything different (although I'm not sure exactly
> what I should expect to see if it detects something fishy).
> 
> > 
> > If those don't provide any clues, I'm out of ideas. :-(
> > 
> Hope not :-)  I appreciate your eyes on this.
> 
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> 

WFM. http://showterm.io/68154da99e25927f4dacb

Instead of viewing this as a software issue, is it possible something is
blocking SSH connections to localhost, causing SSH to hang?

What does `ssh -vv` tell you?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple



More information about the Cygwin mailing list