defunkt and open processes

[naxat88@…]

Hello,

browsing the source-code/wiki/timeline/... with GitPlugin results in defunkt git processes and some other processes won't close properly after serving the request. After some time the operating system runs out of memory and it won't be possible to ssh into the server anymore :(. Unfortunately I haven't found out how to reproduce the bug properly :(. ps aux | grep gi[t] prints the following processes:

www-data  3273  0.0  0.0   4948  1232 ?        S    15:31   0:00 git --git-dir=/pub/scm/snip-fu/ cat-file blob bca73b2b96c5f68566fc08547489dfdf8a6babbb
www-data  3562  0.2  0.0      0     0 ?        Z    15:35   0:00 [git] <defunct>

I'm using Trac 0.11, Python 2.5, git 1.5.6.3 on Debian Etch 4.0 with the latest svn-version of the plugin. My config looks like:

[git]
cached_repository = true
persistend_cache = true

kind regards

[matt@…]

I also encountered this problem, I've attached gitplugin.fix.patch above. This refactors the popen code to use the subprocess module and makes sure to wait() on the opened process to ensure that the process is closed.

As a footnote, I expect only people with persistent python interpreters (I was using mod_python) to suffer from this bug. The old popen code was very poorly thought out, it left persistent processes open because it relied on them being reaped when the parent interpreter died, this never happens in mod_python. Net result is that the git cat-file processes got left open and gradually filled all the ram in the machine.

[anonymous]

Replying to matt@sysctl.co.uk:

I also encountered this problem, I've attached gitplugin.fix.patch above. This refactors the popen code to use the subprocess module and makes sure to wait() on the opened process to ensure that the process is closed.

As a footnote, I expect only people with persistent python interpreters (I was using mod_python) to suffer from this bug. The old popen code was very poorly thought out, it left persistent processes open because it relied on them being reaped when the parent interpreter died, this never happens in mod_python. Net result is that the git cat-file processes got left open and gradually filled all the ram in the machine.

:-(

actually, the idea behind the current code was to rely on the garbage collector in order to avoid having to read all input at once synchronously, and instead be able to pass file descriptors to the upper layers, which could then decide to read only a part... I had lazy evaluation in mind when I coded this, and the hope to reduce the amount of in-memory buffers...

[matt@…]

Granted it isn't an awful idea, it falls a bit flat on Linux though :(. The processes won't disappear until they've been waited on (to read the exit code), it looks as if nothing that gets given the popened process bothers doing this. Though this isn't your fault anyway, it still causes massive memory problems when it goes pear-shared in mod_python.

I've been using the modified GitPlugin on my server for a couple of days now, without any problems so far. Certainly hasn't left any processes lying around. While the lazy evaluation idea is nice, the net result was far from what you probably expected. Sounds like you're a prolog man ;)

[Herbert Valerio Riedel]

actually, I've got a bit of a Haskell fetish (not that I'd dislike Prolog...)

anyway, right now I starting to wonder whether tracd has the same issue, and also if there are other resource leaks with the combination mod_python+Trac lurking around...

[naxat88@…]

I'm actually using tracd behind an apache proxy and it has this issue.

[mail@…]

I can confirm this patch fixes this behaviour. Thanks!

Running on Gentoo:

• apache-2.2.9
  
• mod_python-3.3.1
  
• python-2.5.2
  
• git-1.5.6.4
  
• trac-0.11.2
  
• track-hacks.org gitplugin from Nov. 21th, 2008
  

[bernat@…]

I also have this bug using trac-git from Debian Lenny (2008/07/10 + some patches).

Is it any issue with the patch provided?

[Tim Hatch]

IIRC close_fds=True is not supported on Windows.

[Herbert Valerio Riedel]

(In [5375]) GitPlugin: converted os.popen3() call to subprocess.Popen() and wait for process termination (addresses #3675)