Kyle McKay wrote:
> 1. Short term. Revert change 35533 and then change the
> APR_KILL_ALWAYS to an APR_KILL_NEVER. This will likely eliminate most
> of the zombie problems for long-lived processes using the Subversion
> library while remaining compatible with ssh connection pooling
> 2. Longer term. Add an option to ~/.subversion/config file ([tunnels]
> section?) that lets you select the apr_kill_conditions_e value passed
> to apr_pool_note_subprocess with it defaulting to APR_KILL_NEVER if
> not given (apr-kill-condition = ... ?).
In my testing of the svn 1.6 client, I found that I end up with a
*lot* of ssh connections to the server sitting around doing nothing.
They aren't zombies, they're fully-fledged ssh processes hanging
around doing nothing with no svn process left to talk to. This could
get very bad on the server if a lot of users end up with a lot of open
It's easily reproducible for with the following trivial command:
for x in `seq 1 10`; do svn log $repos|head; done
You end up with 10 ssh processes left on your machine in the
background, and similarly on the server side. And they seem to stay
that way forever. They don't die "in their own time", they stick
around forever (at least 2 days, I don't know if they'd die at some
This is not reasonable...and didn't happen on older versions of svn.
I'll note that the comment which was removed in r35533 even seemed to
*SAY* this was one of the reasons for the kill to exist!
I also tested with Kyle's patch from the end of bug 2580. As I'd
expect, it does not help this problem one bit, since it only attempts
to solve the zombie problem, not the ssh-hangs-around-forever problem.
However, backing out 35533 *does* fix the issue.
I'd like to recommend that the right thing to do now is simply revert
If people want to do ssh connection-pooling, they can simply open up a
control connection first, and setup svn to never be a control-master.
Received on 2009-04-02 22:59:01 CEST