On Apr 20, 2009, at 10:46 PM, Kyle McKay wrote:
> Thanks for your details. I can now reproduce the problem you describe
> provided I'm using a version of OpenSSH sshd that does not contain the
> fix for OpenSSH Bug 85 and the ssh client connects to it using
> Protocol 2:
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=85
>
> The bug is actually endemic to the sshd code, not the ssh code.
>
> To test whether or not any particular sshd suffers from the bug, do
> this:
>
> ssh -2 <ssh_host_to_test> yes | true
Wow, NICE job tracking that down!
This is rather insidious, because it's actually an SSHv2 protocol
specification deficiency, not actually an implementation bug. Thus, it
occurs if *either* the client *or* the server isn't patched, e.g., a
OpenSSH_3.9p1 connecting to a OpenSSH_5.1p1 machine still sees this
hang. Furthermore, the fix to the hang is an OpenSSH-specific protocol
extension, which OpenSSH will only send to other OpenSSH
implementations.
See "3. connection: Channel write close extension" in:
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL?rev=1.12;content-type=text%2Fplain
> Whether or not to fix the zombie problem (it should definitely be
> fixed ASAP) is a different issue from whether or not to revert support
> for issue 2580. Deciding to revert issue 2580 support also happens to
> fix the zombie problem.
Indeed.
Despite all the above talk about ssh, I think ultimately this truly is
a subversion bug. SVN is responsible for both ends of the connection.
When the subversion client gets a SIGPIPE on its output, it can do
something to make sure it cleans up properly. One way to do this is to
kill the ssh client process, like it did before.
There are other alternatives, although they're probably enough work
that they're not doable in the 1.6 patch series. Perhaps the svnserve
process to notice that its *input* pipe had been closed, and abort the
connection. This, ssh *does* support: "ssh hostname cat < /dev/null"
never hangs on any version of ssh I know of, demonstrating that if
svnserve similarly noticed a closed input, it could properly shut
down. Or perhaps the client could upon receipt of a signal, not exit
immediately, but instead send a "cancel" command to the server,
read&discard further data from ssh, and wait for the ssh process to
exit first. Or perhaps there's yet another solution.
Of course, Subversion *could* simply declare that it requires that you
use OpenSSH >= 5.1, but IMO that isn't very sensible. Not only is this
version rather new and many people aren't using it yet, but it really
is an *OpenSSH* dependency. Other clients or servers won't do. So, I
do think the change made for issue 2580 should be reverted...at least
for now.
At my workplace, nearly everything is using ssh versions < 5.1, and it
would cause serious hurt for the svn server if people used unpatched
subversion 1.6 clients which don't shutdown their ssh tunnels. I
already reverted r35533 in the subversion build I created, and told
everyone else to do the same if they make custom builds. But I imagine
the same issue will occur for many other organizations.
James
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1836728
Received on 2009-04-21 07:58:49 CEST