I've been running uwsgi for about a year and I've run into a situation that I can't seem to sort out. I'm not positive there is a good solution, but maybe someone with far more knowledge than I could shed some light. I'll give some background, please bear with me.
I run uwsig behind nginx to run a simple mercurial hgweb server. My uwsgi configuration is pretty basic: "-M -p 4 -d /var/log/$daemon_name.log --pidfile /run/$daemon_name.pid --pythonpath $hgwebpath --module $hgwebmodule" However, I recently added buildbot to our setup, which is triggered by a commit hook in hgweb. It's all built in stuff, I didn't write any of it. Unfortunately this hook uses fork, and so generates defunct uwsgi instances when it occurs. It appears to be a known issue with the buildbot. I decided uwsgi's --reaper option looked like it might help me out. It did the trick, very handy since I didn't want to wade into the buildbot codebase. Like the manual for --reaper says "you should fix your process spawning usage (if you can) ..." and I don't think I can. However, after enabling reaper I noticed that very large commit pushes to hgweb over http would cause the process to be killed. It would happen anytime a push of 20MB or larger was pushed up to the server. (This is extremely rare, we just happen to have a project that carries this much baggage). After a lot of reading and testing, I found that by removing the --reaper option from uswgi, the commits would no longer be killed. I could push up as large a bundle as I liked (+100MB). However, without the reaper my buildbot is back to leaving zombies all over the place. Do any of you know more about the --reaper option, and if there is any additional control over how it determines what a zombie process is? Or is there is a different uwsgi option I should use? I fully realize uwsgi is not the problem here; I blame uwsig and buildbot. But since uwsgi is so flexible I wondered if there might be a way to have my cake and eat it too, so to speak. Big thanks for any feedback. -Andrew -- Andrew Fischer _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
