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
Received on Sat Nov 5 02:23:39 2005