Make sure you read: http://blog.dscpl.com.au/2012/10/requests-running-in-wrong-django.html
If you are using setdefault() method for setting DJANGO_SETTINGS_MODULE you will have that issue if more than one site running in a process. That post details others things you can get wrong as well. Graham On 16/10/2013, at 10:49 PM, Hanne Moa <[email protected]> wrote: > It's just WSGIScriptAlias in all of them, no AddHandler/SetHandler. The most > important thing to run is Django but there's now also trac on one of them. > Apache also front several things (acting as proxy) in addition. > > The "all over the place" was that there are several > devel-copies of the same site and the wrong copy was being loaded. Known > problem when WSGIProcessGroup is either wrong or missing if google is to be > believed. > > > > On 12 October 2013 04:40, Graham Dumpleton <[email protected]> wrote: > Both are valid configurations and can work, but achieve different results. > > What you don't show is how you are mounting the WSGI applications. Are you > using WSGIScriptAlias or are you using AddHandler/SetHandler? Also what web > framework are you running? > > Without that information and also a better description of the actual > errors/problems you were getting, is hard to suggest why the first > configuration would give you a problem. > > For all I know when you are saying 'with code being imported/run from all > over the place, seemingly at random' you might be talking about code being > loaded at times you don't expect, albeit still the right code. That can well > be the case with embedded mode because it is a multiprocess configuration on > Linux systems. > > Graham > > On 11/10/2013, at 9:47 PM, Kaleissin - <[email protected]> wrote: > >> I took over development of a site recently and was having trouble with code >> being imported/run from all over the place, seemingly at random. On the >> dev-server, multiple copies of the same site was running, some with >> WSGIDaemonProcess (mod_wsgi 3.3), others embedded. Having them all use >> WSGIDaemonProcess didn't solve the problem (and yes, there were >> WSGIProcessGroup in the same file). >> >> Turns out: >> >> The staging copy runs two daemon-processes, one single-threaded (processes=1 >> threads=1 set explicitly) and one not. One <Location> was set to use the >> single threaded group, several, but not all, other locations were set to use >> the multithreaded group. I moved the multithreaded WSGIProcessGroup to the >> level of the virtual host, and kept the singlethreaded WSGIProcessGroup for >> the one spot it was needed. No more clashes, code was fetched from the right >> place. However... The <location> that needs to be single threaded isn't, >> judging by the errors I get. >> >> If I read >> https://modwsgi.readthedocs.org/en/latest/configuration-directives/WSGIProcessGroup.html >> correctly, a WSGIProcessGroup set inside a <location> overrides the >> WSGIProcessGroup set outside. Is this correct, and if so, why isn't the one >> location with an override actually overidden? >> >> Secondly, if: >> >> WSGIDaemonGroup foo >> WSGIDaemonGroup bar >> WSGIProcessGroup foo >> >> <location /xux> >> WSGIProcessGroup bar >> </location> >> >> <location /gurba> >> .. >> </location> >> >> <location /meepmeep> >> # Non-python stuff >> </location> >> >> properly separates the processes while: >> >> WSGIDaemonGroup foo >> WSGIDaemonGroup bar >> >> <location /xux> >> WSGIProcessGroup bar >> </location> >> >> <location /gurba> >> WSGIProcessGroup foo >> </location> >> >> <location /meepmeep> >> # Non-python stuff >> </location> >> >> doesn't, shouldn't that be documented? >> >> Or am I barking up the wrong tree here? >> >> >> K >> >> -- >> You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/modwsgi. >> For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/groups/opt_out.
