So I don't forget. http://code.google.com/p/modwsgi/issues/detail?id=231
:-) Graham On 4 March 2011 12:08, Graham Dumpleton <[email protected]> wrote: > Okay, that one specific case will cause sys.path to grow. > > What happens is that on very first load of WSGI script file, if it > fails at global level it will log error and then throw what was loaded > away and so will look as if never loaded. If the script isn't fixed > then every subsequent request will do the same thing and because > adding to sys.path is cumulative and before where the error is, it > will keep growing. > > It is hard to protect against that case in mod_wsgi. I should document > this specific case as a sub not in that reloading source code > document. > > Anyway, this is why WSGI scripts, even with daemon mode should perhaps > protect against doing cumulative actions at global scope in WSGI > script file without checking if already done. > > Graham > > On 4 March 2011 11:52, bc <[email protected]> wrote: >> --------------------------------------------------------------------------------------- >> import os >> import sys >> import site >> >> >> f=open('/tmp/wsgi.log', 'a') >> os.chmod('/tmp/wsgi.log', 0666) >> >> >> sitedir = '/blah/blah/blah' >> >> print >> f, 'pid', os.getpid(), 'before addsitedir', sys.path >> site.addsitedir(sitedir) >> print >> f, 'after addsitedir', sys.path >> >> import blorf >> ---------------------------------------------------------------------------------------------- >> >> Send a few requests, and you should see sys.path growing (or at least >> after you've exercised each pid at least once). >> >> Not sure if it's important, but I'm using different process groups as >> well as different application groups. The process groups are to >> provide different security contexts, i.e. they run as different apache >> users, and can access different resources. The application groups are >> to provide different developer python contexts, much like the userdir >> example in the docs. There's an application group per-developer, and >> an "alpha" application group. >> >> On Mar 3, 3:54 pm, Graham Dumpleton <[email protected]> >> wrote: >>> Can you send me an actual test script to try with. Running around >>> trying to get stuff ready for my US trip so anything to make it easier >>> for me will be most appreciated. >>> >>> On 4 March 2011 10:46, bc <[email protected]> wrote: >>> >>> >>> >>> > I strongly suspect this is due to uncaught, or badly handled >>> > exceptions. It doesn't happen on requests that don't throw exceptions. >>> > In that case I see sys.path updated once for each daemon process >>> > (exactly as I would expect). But sending requests that eventually >>> > abort with a (slient) 500 causes the sys.path update with every >>> > request. >>> >>> > This is easy to reproduce by making a script that dumps sys.path to a >>> > file, does a addsitedir(), and then does "import blorf", or some such >>> > thing to force an error. Sending requests will then return a 500 every >>> > time, and every time sys.path gets longer. >>> >>> > On the other hand, if I make requests that complete without error, >>> > sys.path doesn't grow. If I "touch" the wsgi script, I see sys.path >>> > gets reset before addsitedir() is called again, so I assume a new >>> > subinterpreter has been created properly, with a clean scope. >>> >>> > On Mar 3, 2:00 pm, Graham Dumpleton <[email protected]> >>> > wrote: >>> >> On 4 March 2011 08:53, bc <[email protected]> wrote: >>> >>> >> > On Mar 3, 1:37 pm, Graham Dumpleton <[email protected]> >>> >> > wrote: >>> >> >> Don't use embedded mode. Preferably use daemon mode and you will not >>> >> >> have this problem. >>> >>> >> > I thought I was. I have a number of WSGIDaemonProcess directives, each >>> >> > running as a different user. I'm assigning WSGIProcessGroup via >>> >> > mod_rewrite. I can dump mod_wsgi.process_group from my wsgi script, >>> >> > and verify that the script runs as the correct user (as assigned by >>> >> > mod_rewrite). >>> >>> >> Also check mod_wsgi.application_group and ensure that you haven't >>> >> delegated multiple WSGI applications to the same process/application >>> >> group. Do that and they will all run in same interpreter and if the >>> >> WSGI script of each does same virtualenv setup you will get >>> >> duplication. >>> >>> >> Suggest ensuring that: >>> >>> >> LogLevel info >>> >>> >> at least is set and then Apache error logs will provide details of >>> >> pid/process group/application group that WSGI script files are being >>> >> loaded into. Presuming that logging isn't being lost. :-( >>> >>> >> Graham >>> >>> > -- >>> > You received this message because you are subscribed to the Google Groups >>> > "modwsgi" group. >>> > To post to this group, send email to [email protected]. >>> > To unsubscribe from this group, send email to >>> > [email protected]. >>> > For more options, visit this group >>> > athttp://groups.google.com/group/modwsgi?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/modwsgi?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
