[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] Prevent Win32 tunnels from leaving orphan server processes on remote

From: Bob Denny <rdenny_at_dc3.com>
Date: Wed, 21 Oct 2009 08:33:57 -0700

See
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407949

[[[
Specific fix for issue #2580 on Win32: Don't do instant kill on tunnel

* subversion/libsvn_ra_svn/client.c
  (make_tunnel): Let tunnel exit normally
]]]

I hope this can make it into 1.7.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2409838

--- subversion-1.6.6rc\subversion\libsvn_ra_svn\client.c Thu Oct 15 21:50:48 2009 UTC
+++ svn-work\subversion\libsvn_ra_svn\client.c Wed Oct 21 15:10:41 2009 UTC
@@ -488,8 +488,24 @@
    * See also the long dicussion in issue #2580 if you really
    * want to know various reasons for these problems and
    * the different opinions on this issue.
+ *
+ * On Win32, APR does not support KILL_ONLY_ONCE. It only has
+ * KILL_ALWAYS and KILL_NEVER. Other modes are converted to
+ * KILL_ALWAYS, which immediately calls TerminateProcess().
+ * This instantly kills the tunnel, leaving sshd and svnserve
+ * on a remote machine running indefinitely. These processes
+ * accumulate. The problem is most often seen with a fast client
+ * machine and a modest internet connection, as the tunnel
+ * is killed before being able to gracefully complete the
+ * session. In that case, svn is unusable 100% of the time on
+ * the windows machine. Thus, on Win32, we use KILL_NEVER and
+ * take the lesser of two evils.
    */
+#ifdef WIN32
+ apr_pool_note_subprocess(pool, proc, APR_KILL_NEVER);
+#else
   apr_pool_note_subprocess(pool, proc, APR_KILL_ONLY_ONCE);
+#endif
 
   /* APR pipe objects inherit by default. But we don't want the
    * tunnel agent's pipes held open by future child processes
Received on 2009-10-21 17:34:12 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.