Peter Samuelson wrote:
> Background for the dev@svn list and the openssh maintainers: I'm
> commenting on a Debian bug report, http://bugs.debian.org/413102, where
> 'svn log svn+ssh://...' sometimes encounters a broken pipe due to the
> ssh subprocess dying too soon. I explain below.
>
>
> [Peter Samuelson]
>> It seems that in the 'svn log' case, the session pool, passed into
>> [libsvn_ra_svn/client.c] open_session(), is destroyed too early, thus
>> killing ssh. I'll try to investigate further.
>
> OK, svn is not actually buggy. Here is what happens:
>
> 'svn log svn+ssh://...' fires off _two_ ssh processes. (Erik Huelsmann
> explains on IRC that this is intentional, connections are treated as
> lightweight, libsvn_ra makes no attempt to reuse connections for
> efficiency.)
>
> The first ssh process finishes its business and is explicitly killed
> (by apr, when the session pool is destroyed). The second connection is
> still active.
>
> That would be fine ... IF the two ssh processes were independent, which
> normally they are. But not if you use the "ControlMaster auto"
> feature! This causes ssh to do its own connection pooling: the first
> ssh process sets itself up as a "master" and the second one detects the
> master and becomes a slave. People use this feature for efficiency,
> since setting up and tearing down ssh connections really isn't cheap.
> (There's the network protocol and the cryptography, but also password
> prompting and such.)
>
> So I'm still trying to think of ideas how to proceed here. It's really
> not svn's fault that launching two ssh processes, then killing the
> first, effectively kills the second as well. On the other hand, it's
> not really ssh's fault that a master process is being explicitly killed
> while still in use. (Left on its own, the master would wait until all
> its slave connections are closed, before dying.)
>
> Note, one workaround is to explicitly instantiate an ssh connection
> pool master, with 'ssh -M', before using 'svn log'. Another is to set
> SVN_SSH='ssh -o ControlMaster=no' (or the equivalent in
> ~/.subversion/config). Does anyone have any better ideas, for either a
> fix or a workaround?
I wonder why svn kills the ssh processes at all. It seems to me that svn
should simply close its pipes to the subprocess, and leave it to the
subprocess to determine when to exit.
That would solve this problem rather nicely - can anyone see any
potential flaws?
Obviously, there's the chance that a buggy tunnel agent might not exit,
but really, that's the fault of the agent, not of Subversion, so I
don't see that the Subversion client needs to care about that,
especially not at the cost of inhibiting this OpenSSH feature.
Max.
Received on Sat Mar 3 15:59:27 2007