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

[PATCH] fix for ssh zombies introduced with r35533

From: Kyle McKay <mackyle_at_gmail.com>
Date: Sat, 28 Mar 2009 16:04:18 -0700

Fix ssh zombie problem introduced with revision 35533

* subversion/libsvn_ra_svn/client.c
   (make_tunnel): Fully detach tunnel process to avoid having it
                  receive signals while restoring the original
                  apr_pool_note_subprocess to avoid creating zombies.

As detailed in this thread:


regarding the change introduced into client.c by revision 35533:


On Mar 27, 2009, at 09:51, Hyrum K. Wright wrote:
> The case which drove r35533 was a user who uses ssh connection
> pooling for svn connections.

Change r35533 removed the call to to apr_pool_note_subprocess meaning
that Subversion never reaps any of its children. This may be okay for
a short-lived process, but is not okay for a long-lived process such
as a GUI tool that has linked with the Subversion library.

If the GUI tool runs long enough, it can create so many un-reaped
zombie processes that system resources are exhausted and it becomes
impossible to spawn any new processes.

The attached patch restores the original call to
apr_pool_note_subprocess thus guaranteeing no zombies are ever
created. It also arranges for the tunnel process to become detached
so that it can "die in piece, in its own time, on its own terms" as
the log comment for revision 35533 mentions, but without causing
zombie processes to be created.

This change retains full compatibility with ssh connection pooling
while eliminating the zombie problem. See issue #2580 for the
original impetus for the change made in revision 35533.




To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].

Received on 2009-03-29 17:34:47 CEST

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

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