Two mod_wsgi Django apps on one Apache are trying to use each other's config files

Question

I have two unrelated mod_wsgi Django apps, which need to be served from two virtual hosts in one instance of Apache2.

I've made each a virtual host, each with its own directory, settings.py and wsgi.py.

The error I keep seeing is:

[Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] mod_wsgi (pid=6375): Exception occurred processing WSGI script '/srv/app1/app1/wsgi.py'., referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ [Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] Traceback (most recent call last):, referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ [Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 219, in __call__, referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ [Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] self.load_middleware(), referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ [Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", line 39, in load_middleware, referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ [Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] for middleware_path in settings.MIDDLEWARE_CLASSES:, referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ [Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] File "/usr/local/lib/python2.7/dist-packages/django/utils/functional.py", line 184, in inner, referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ [Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] self._setup(), referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ [Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 42, in _setup, referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ [Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] self._wrapped = Settings(settings_module), referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ [Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 95, in __init__, referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ [Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] raise ImportError("Could not import settings '%s' (Is it on sys.path?): %s" % (self.SETTINGS_MODULE, e)), referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ [Wed Jun 03 16:31:48 2015] [error] [client 1.2.3.4] ImportError: Could not import settings 'app0.settings' (Is it on sys.path?): No module named app0.settings, referer: http://app1.example.com/admin/mdtconfig/locationtoservice/ 

app0.wsgi:

import os import sys sys.path.append('/srv/app0') os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app0.settings") from django.core.wsgi import get_wsgi_application application = get_wsgi_application() 

app1.wsgi:

import sys sys.path.append('/srv/app1') import os os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app1.settings") from django.core.wsgi import get_wsgi_application application = get_wsgi_application() 

How can the two apps be getting muddled?

A request for a page from app1 is complaining that it can't load the settings from app0 - why is it even trying?

---

Update:

I'm particularly concerned that each wsgi.py is setting DJANGO_SETTINGS_MODULE to it's own settings name - is this the cause of the problem?

Answer 1

Read:

• http://blog.dscpl.com.au/2012/10/requests-running-in-wrong-django.html

Do not use os.environ.setdefault(), use os.environ[].

Also use daemon mode of mod_wsgi and not embedded mode.

• http://blog.dscpl.com.au/2012/10/why-are-you-using-embedded-mode-of.html

---

To add to this after your update, the setting of the environment variable is usually not an issue as your two applications would run in different sub interpreter contexts of the process. Where it falls down is because you are using os.environ.setdefault() as this will not do anything if the environment variable is already set. That environment variables are actually process wide, means that which ever WSGI script file sets it first will win. This problem doesn't occur when you use os.environ[] as it will overwrite the environment variable for the sub interpreter context and ignore that inherited from process wide level, so read the blog posts and do what is explained.