Take the 2-minute tour ×

I have recently set up a web server, which currently hosts a couple of static page websites, and two django projects.

the two django projects are 'scalamoosh' and 'dentech' and are in separate directories respectively, in the home folder. Each have their own wsgi script which points to their respective settings.py file.

Recently though, I have been noticing a few 500 errors on 'dentech'. Usually a refresh will correct the problem, but this isn't acceptable, so I checked the apache error.log, and noticed that sometimes when I hit 'dentech' there is an exception raised about cannot find scalamoosh.settings in the dentech project. Somehow these two projects are crossing over and interfering with each other. I have not worked on scalamoosh enough yet to know if the problem is the same the other way around. Below is my exception.

[Sun Jul 08 13:30:34 2012] [error] Traceback (most recent call last):
[Sun Jul 08 13:30:34 2012] [error] File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 219, in __call__
[Sun Jul 08 13:30:34 2012] [error]    self.load_middleware()
[Sun Jul 08 13:30:34 2012] [error]      for middleware_path in settings.MIDDLEWARE_CLASSES:
[Sun Jul 08 13:30:34 2012] [error]    File "/usr/local/lib/python2.7/dist-packages/django/utils/functional.py", line 184, in inner
[Sun Jul 08 13:30:34 2012] [error]      self._setup()
[Sun Jul 08 13:30:34 2012] [error]    File "/usr/local/lib/python2.7/dist-packages/django/conf/__init__.py", line 42, in _setup
[Sun Jul 08 13:30:34 2012] [error]      self._wrapped = Settings(settings_module)
[Sun Jul 08 13:30:34 2012] [error]      raise ImportError("Could not import settings '%s' (Is it on sys.path?): %s" % (self.SETTINGS_MODULE, e))
[Sun Jul 08 13:30:34 2012] [error]  ImportError: Could not import settings 'scalamoosh.settings' (Is it on sys.path?): No module named scalamoosh.settings

Any help/advise would be greatly appreciated. Cheers

share|improve this question
add comment

4 Answers

up vote 2 down vote accepted

The issue you're running in to is that while mod_wsgi gives each Django app its own python interpreter, they still share the same OS environment which is where Django stores the name of the setting module. The work-around I found was to change the name of the enviroment variable that Django looks for the settings module in before creating the WSGI application object.

My slightly modified wsgi.py looks something like this:

import os

# change the env variable where django looks for the settings module
import django.conf

os.environ.setdefault("DJANGO_SECOND_SETTINGS_MODULE", "second.settings")

# file. This includes Django's development server, if the WSGI_APPLICATION
# setting points here.
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
share|improve this answer
This worked great. Thanks a lot! :) –  Scalamoosh Aug 10 '12 at 21:08
add comment

It doesn't look like you are using separate virtual environments for your two projects at the moment, and if not, I would highly recommend doing so and seeing if the problem persists thereafter. You can still use the same Apache instance, but run two separate instances of Django (and all the other requirements of the projects, which may or may not differ). This is normally the recommended approach for any Django project.

If you don't know about virtual environments, here's a quickstart tutorial on using virtualenv and Django, and I would also recommend using the very nice Virtualenv Wrapper by Doug Hellman. Hope this helps!

share|improve this answer
I'm experiencing the same problem, but I'm not sure if the virtualenv will solve that. The real problem is the DJANGO_SETTINGS_MODULE environment variable that gets overwritten by the other app. –  Tank Jul 10 '12 at 5:26
Thanks for the info regarding virtualenv. I have wanted to get it set up for a while now, but never got round to it. Unfortunately though, it did not solve my problem. Like @Tank mentioned, the DJANGO_SETTING_MODULE variable (in apache(?)) is getting overwritten each time a different app is used. –  Scalamoosh Jul 29 '12 at 19:52
add comment

The default configuration for mod_wsgi has the two Django sites running in separate sub interpreters of the same process. Unfortunately Django changed their generated wsgi.py in 1.4 and the new file breaks with this default behaviour of mod_wsgi. To fix the issue if using Django 1.4, go into the wsgi.py file and change:

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")


os.environ["DJANGO_SETTINGS_MODULE"] = "mysite.settings"

That is, don't use os.environ.setdefault() because it will not do anything when variable has already been set by other Django site in the other sub interpreter due to the way environment variables leak between sub interpreters.

Better still, use mod_wsgi daemon mode and create distinct daemon process groups for each site and delegate them to run in different sets of processes. This can solve a similar issue with older Django versions where a not quite correct Apache configuration for VirtualHosts has been used.

share|improve this answer
add comment

Are you using memcached for the cache, or any other caching method where the two instances could write in the same cache file? That could explain why the two environments get mixed up. In that case, simply add a KEY_PREFIX variables in your settings' CACHES dictionary.

    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '',
        'KEY_PREFIX': 'scalamoosh'
share|improve this answer
I don't currently have any caching set up on either of the sites, so doubt this will solve my problem. Thanks for the info though. –  Scalamoosh Jul 29 '12 at 19:54
add comment

Your Answer


