On 3/3/07, Max Bowsher <maxb1@ukf.net> wrote:
> 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?
Daniel Berlin did (he read our code):
http://svn.haxx.se/users/archive-2005-11/0194.shtml
> 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.
Maybe the problems indicated in dannyb's post don't relate to modern
ssh versions anymore?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 3 17:22:11 2007