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 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.
