You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Quest <qu...@lysator.liu.se> on 2005/11/04 20:52:58 UTC
svn+ssh breaks with ControlSocket
It would seem that svn brutally kills the ssh process it starts, so
that ssh client can't remove it's ControlSocket. The dangling
controlsocket fools following ssh connections to believe they should
use multiplexed sessions, and fails when they can't use the
controlsocket.
[21:44] svn ls svn+ssh://venerable/mnt/data/svnroot/plonesvnview
Enter passphrase for key '/home/quest/.ssh/id_rsa':
Control socket connect(/tmp/ctl_quest@windwards.net): Connection refused
Enter passphrase for key '/home/quest/.ssh/id_rsa':
This would seem to be a misfeature in ssh, but svn really shouldn't be
so harsh to its spawned ssh client. Hence I feel this is a bug in svn
and am looking for agreement. What say you?
--
"Making digital data less copyable is like making water less wet."
-- Cory Doctorow
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn+ssh breaks with ControlSocket
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-11-05 16:02:50 -0500, Daniel Berlin wrote:
> Right, you are better off starting the master connection in
> your .profile or something
Better than the .profile: I have SVN_SSH=$HOME/scripts/ssh, which
is a wrapper to ssh that starts the master connection if need be,
but I need a specific test for each server, or I would need to
write a parser for the .ssh/config file in order to get the socket
name.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn+ssh breaks with ControlSocket
Posted by Daniel Berlin <db...@dberlin.org>.
On Sat, 2005-11-05 at 03:49 +0100, Vincent Lefevre wrote:
> On 2005-11-04 20:21:58 -0500, Daniel Berlin wrote:
> > On Fri, 2005-11-04 at 21:52 +0100, Quest wrote:
> > "
>
> There could be a solution concerning the SIGTERM: capture the
> stderr output from ssh with a pipe and send it back to stderr
> (the one of the client) until a SIGTERM is sent. Once SIGTERM
> has been sent, the stderr output from ssh should be ignored.
> I don't know if this can be done in practice...
>
> But anyway, the user shouldn't configure ssh to make svn open
> a master ssh connection, as such a connection must remain open
> until the user no longer needs ssh connections to the same host.
Right, you are better off starting the master connection in
your .profile or something
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn+ssh breaks with ControlSocket
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-11-04 20:21:58 -0500, Daniel Berlin wrote:
> On Fri, 2005-11-04 at 21:52 +0100, Quest wrote:
> > It would seem that svn brutally kills the ssh process it starts, so
> > that ssh client can't remove it's ControlSocket. The dangling
> > controlsocket fools following ssh connections to believe they should
> > use multiplexed sessions, and fails when they can't use the
> > controlsocket.
> >
> > [21:44] svn ls svn+ssh://venerable/mnt/data/svnroot/plonesvnview
> > Enter passphrase for key '/home/quest/.ssh/id_rsa':
> > Control socket connect(/tmp/ctl_quest@windwards.net): Connection refused
> > Enter passphrase for key '/home/quest/.ssh/id_rsa':
> >
> > This would seem to be a misfeature in ssh, but svn really shouldn't be
> > so harsh to its spawned ssh client. Hence I feel this is a bug in svn
> > and am looking for agreement. What say you?
>
>
> "
> /* Arrange for the tunnel agent to get a SIGKILL on pool
> * cleanup. This is a little extreme, but the alternatives
> * weren't working out:
> * - Closing the pipes and waiting for the process to die
> * was prone to mysterious hangs which are difficult to
> * diagnose (e.g. svnserve dumps core due to unrelated bug;
> * sshd goes into zombie state; ssh connection is never
> * closed; ssh never terminates).
> * - Killing the tunnel agent with SIGTERM leads to unsightly
> * stderr output from ssh.
> */
> apr_pool_note_subprocess(pool, proc, APR_KILL_ALWAYS);
> "
There could be a solution concerning the SIGTERM: capture the
stderr output from ssh with a pipe and send it back to stderr
(the one of the client) until a SIGTERM is sent. Once SIGTERM
has been sent, the stderr output from ssh should be ignored.
I don't know if this can be done in practice...
But anyway, the user shouldn't configure ssh to make svn open
a master ssh connection, as such a connection must remain open
until the user no longer needs ssh connections to the same host.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svn+ssh breaks with ControlSocket
Posted by Daniel Berlin <db...@dberlin.org>.
On Fri, 2005-11-04 at 21:52 +0100, Quest wrote:
> It would seem that svn brutally kills the ssh process it starts, so
> that ssh client can't remove it's ControlSocket. The dangling
> controlsocket fools following ssh connections to believe they should
> use multiplexed sessions, and fails when they can't use the
> controlsocket.
>
> [21:44] svn ls svn+ssh://venerable/mnt/data/svnroot/plonesvnview
> Enter passphrase for key '/home/quest/.ssh/id_rsa':
> Control socket connect(/tmp/ctl_quest@windwards.net): Connection refused
> Enter passphrase for key '/home/quest/.ssh/id_rsa':
>
> This would seem to be a misfeature in ssh, but svn really shouldn't be
> so harsh to its spawned ssh client. Hence I feel this is a bug in svn
> and am looking for agreement. What say you?
"
/* Arrange for the tunnel agent to get a SIGKILL on pool
* cleanup. This is a little extreme, but the alternatives
* weren't working out:
* - Closing the pipes and waiting for the process to die
* was prone to mysterious hangs which are difficult to
* diagnose (e.g. svnserve dumps core due to unrelated bug;
* sshd goes into zombie state; ssh connection is never
* closed; ssh never terminates).
* - Killing the tunnel agent with SIGTERM leads to unsightly
* stderr output from ssh.
*/
apr_pool_note_subprocess(pool, proc, APR_KILL_ALWAYS);
"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org