settings.py seems to be cached or stuck

[Tom]

Hi all,

I am experiencing TemplateDoesNotExist errors. Initially I thought I
had my TEMPLATE_DIRS variable set incorrectly, but much
experimentation yielded nothing. I then noticed that on the browser
TemplateDoesNotExist error pages the TEMPLATE_DIRS setting reads as an
empty tuple (). I then tried changing several other settings in
settings.py including database name and engine, and adding and
removing installed apps. None of these changes are showing up in the
settings listed on error pages.

It seems like the settings file has been cached somewhere because
nothing I do to my settings.py file is making any difference. I have
even tried deleting the file altogether and still nothing changes. I
have also tried recreating my project from scratch, but still no joy.

This is really weird; does anybody have any ideas what is going on?

Thanks in advance,

Tom

[Tim Valenta]

Are you using the development server? There's definitely caching
funny-business in a production web server, but that should affect you
if you're using "manage.py runserver"

Does stopping and starting the development server change anything?

Tim

[Tom]

Sorry, I should have mentioned that this has only come up after
deploying the project to a production server using mod_wsgi. It works
absolutely fine under development.

Tom

[Crispin Wellington]

Have a read of the mod_wsgi documentation, particularly the page:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues

Because Django uses environment variables to access the settings file,
all kinds of strife can occur when running Django on top of mod_wsgi.
Essentially Django and mod_wsgi don't play nicely when mod_wsgi is in
its default configuration. You get applications swapping environments
and all kinds of inexplicable bizarre errors occuring.

As well as the environment problem, there is a particular insidious
issue with time zone settings using Django under mod_wsgi that affects
cookie expiry and thus django auth and login.

The best approach is to run mod_wsgi in daemon mode, and allocate a
specific process and thread pool to each django application. This way
you wont have python sub interpreters swapping applications they serve
and getting confused.

Hope this helps.

Regards

Crispin Wellington

> --
>
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
>
>

[Tim Valenta]

Yeah, production servers aren't really very friendly to changes.
Languages like PHP are specifically built to circumvent such woes.
You would have to actually bounce apache in order to get the changes
to take.

This is why the development server is so nice, because when you alter
certain files that it watches, it actually restarts automatically for
you. There's not really going to be a solution for this problem,
since this is inherent to production-class web servers, where PHP and
general CGI is the exception.

Hope that's not a big problem!

I still liked to run a production server version of my project, so I
made a local SVN repository which I would commit changes to. I
checked out a copy of the repository to where my production server
wanted to see it, and then put up a clumsy cron job would
automatically update the production machine's repository each day, and
bounce Apache for me.

That's about as close as it'll get, I think :P

Tim

[Karen Tracey]

On Tue, Nov 24, 2009 at 11:32 PM, Tim Valenta <tonights...@gmail.com> wrote:

Yeah, production servers aren't really very friendly to changes.
Languages like PHP are specifically built to circumvent such woes.
You would have to actually bounce apache in order to get the changes
to take.

This is why the development server is so nice, because when you alter
certain files that it watches, it actually restarts automatically for
you.  There's not really going to be a solution for this problem,
since this is inherent to production-class web servers, where PHP and
general CGI is the exception.

Hope that's not a big problem!

I still liked to run a production server version of my project, so I
made a local SVN repository which I would commit changes to.  I
checked out a copy of the repository to where my production server
wanted to see it, and then put up a clumsy cron job would
automatically update the production machine's repository each day, and
bounce Apache for me.

That's about as close as it'll get, I think :P

You don't give details on what your production environment is so I don't know if you can get closer there, but with mod_wsgi you can get closer.

With mod_wsgi in daemon mode just touching the wsgi script file will result in a reload on the next request.  You can even set things up so that it reloads automatically on source code changes.  Graham Dumpleton sets outs all the details in a blog entry here:

http://blog.dscpl.com.au/2008/12/using-modwsgi-when-developing-django.html

Karen

[Tom]

That is all really helpful; thanks very much everybody. My production
environment is Apache 2.2.9 on Fedora, so it looks as if the solution
Karen suggests will be workable, and I think I will give that a try as
it looks close to ideal.

Thanks again all; much appreciated.

Tom

[Graham Dumpleton]

On Nov 25, 3:23 pm, Crispin Wellington

<cwelling...@ccg.murdoch.edu.au> wrote:
> Have a read of the mod_wsgi documentation, particularly the page:http://code.google.com/p/modwsgi/wiki/ApplicationIssues
>
> Because Django uses environment variables to access the settings file,
> all kinds of strife can occur when running Django on top of mod_wsgi.
> Essentially Django and mod_wsgi don't play nicely when mod_wsgi is in
> its default configuration. You get applications swapping environments
> and all kinds of inexplicable bizarre errors occuring.

Your imagination is running amuck, no such thing happens. You can
quite happily run multiple Django instances in embedded mode, they
just need to be separated into distinct Python sub interpreters, which
is the default behaviour of mod_wsgi. So, unless you have played with
WSGIApplicationGroup to override the default, there should be an
issue.

FWIW, it is mod_python that doesn't separate them properly if you have
multiple Django instances in one VirtualHost. This is because
mod_python only gives by default a sub interpreter to each VirtualHost
ServerName. So, sure you aren't confused.

> As well as the environment problem, there is a particular insidious
> issue with time zone settings using Django under mod_wsgi that affects
> cookie expiry and thus django auth and login.

That is only an issue where you have distinct applications, be they
Django or PHP, with different requirements for setting TZ. Not an
issue if all use the same.

> The best approach is to run mod_wsgi in daemon mode, and allocate a
> specific process and thread pool to each django application.

Even though embedded mode will work and for very high performance
sites, so long as Apache configured properly, is better, for most
mortals daemon mode is safer.

Graham

[Graham Dumpleton]

On Nov 25, 3:58 pm, Karen Tracey <kmtra...@gmail.com> wrote:

> http://blog.dscpl.com.au/2008/12/using-modwsgi-when-developing-django...

Thanks Karen. Is annoying sometimes when you see people don't bother
reading past the single mod_wsgi page on Django site even though I put
disclaimers at front to try and encourage people to do so without
making it too blatant that what I wanted to say was 'STOP BEING LAZY
AND GO READ THE REAL MOD_WSGI DOCUMENTATION'. ;-)

Graham

[Graham Dumpleton]

On Nov 25, 4:52 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:

> On Nov 25, 3:23 pm, Crispin Wellington
>
> <cwelling...@ccg.murdoch.edu.au> wrote:
> > Have a read of the mod_wsgi documentation, particularly the page:http://code.google.com/p/modwsgi/wiki/ApplicationIssues
>
> > Because Django uses environment variables to access the settings file,
> > all kinds of strife can occur when running Django on top of mod_wsgi.
> > Essentially Django and mod_wsgi don't play nicely when mod_wsgi is in
> > its default configuration. You get applications swapping environments
> > and all kinds of inexplicable bizarre errors occuring.
>
> Your imagination is running amuck, no such thing happens. You can
> quite happily run multiple Django instances in embedded mode, they
> just need to be separated into distinct Python sub interpreters, which
> is the default behaviour of mod_wsgi. So, unless you have played with
> WSGIApplicationGroup to override the default, there should be an
> issue.

That of course should have read:

"""So, unless you have played with

WSGIApplicationGroup to override the default, there should NOT be an
issue."""

I have it when I leave out 'not' like that. :-)

Graham

> > > For more options, visit this group athttp://groups.google.com/group/django-users?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Crispin Wellington]

On Tue, 2009-11-24 at 21:52 -0800, Graham Dumpleton wrote:

> Your imagination is running amuck, no such thing happens. You can
> quite happily run multiple Django instances in embedded mode, they
> just need to be separated into distinct Python sub interpreters, which
> is the default behaviour of mod_wsgi. So, unless you have played with
> WSGIApplicationGroup to override the default, there should be an
> issue.

We run multiple Django apps through mod_wsgi, have not touched
WSGIApplicationGroup, and we see these applications occasionally shift
environment contexts under load. We know this because we get tracebacks
emailed to us from one application, with the environment and Django
settings of another application. Each application has its own .wsgi file
in its own directory running its own virtual python. We use
WSGIScriptAlias to map a URI path to the wsgi file. The wsgi file sets
up the virtualpython using site.addsitedir(). The wsgi file sets the
DJANGO_SETTINGS_MODULE to point to the applications settings file. When
we run mod_wsgi in daemon mode, the problems go away.

Regards

Crispin

[Graham Dumpleton]

On Nov 25, 6:43 pm, Crispin Wellington

I cant find your name against any posts to suggest that you have ever
reported this on the mod_wsgi mailing list, or if you have you cant
have hung around to help resolve it as this is something which would
have been investigated quite thoroughly to get to the bottom of it.

The closest similar problem can remember is people with badly
configured Apache such that they had duplicate or overlapping
VirtualHost configurations and Apache was executing requests in
context of wrong VirtualHost in some cases. They fixed up their Apache
configurations and all was fine. Most obvious case is people not
setting NameVirtualHost properly and the other as mentioned is people
fiddling with WSGIApplicationGroup.

At the moment there is only a suggestion of an issue. No details on
what version of mod_wsgi being used at the time or anything else in
the way of detail. Not much to go on.

One of the things that is most annoying about developing mod_wsgi is
people asking about or saying they have a problem, usually with
insufficient details, and you asking for more information, giving
answers or suggestions about how to investigate and those people then
never actually bother to come back and tell you what you need to know,
what they found and whether or how they fixed or worked around the
problem. You thus never know if there was a problem to be fixed or
not. For Django related stuff, a lot of the time you don't even get
that as people instead go off to #django IRC channel rather than
bringing the issue to the mod_wsgi mailing list where it belongs.
Sometimes I only find out about potential issues by trolling the
#django IRC logs after the fact and even then you can only speculate
whether it was a real issue or not.

Perhaps next time you will consider reporting the problem to the
mod_wsgi mailing list and helping to fully investigate it and help
determine if there is a problem in mod_wsgi or not. At the moment
there isn't believed to be any issues which would cause this.

Graham

[Tim Valenta]

> Thanks Karen. Is annoying sometimes when you see people don't bother
> reading past the single mod_wsgi page on Django site even though I put
> disclaimers at front to try and encourage people to do so without
> making it too blatant that what I wanted to say was 'STOP BEING LAZY
> AND GO READ THE REAL MOD_WSGI DOCUMENTATION'. ;-)

Since that had stemmed from what I had initially said, I'd briefly
defend the position I had taken, since my personal preference is to
not run my ever-changing development code on a production web server.
I've read that blog post Karen linked to a long time ago, but I
clearly forgot about it, given that I have never required my
production server to reload development files.

I've read the docs. I just forgot about this capability. I'm not
lazy :) Just busy. Apologies to the original thread-starter for my
inaccurate conclusion.

Tim

On Nov 24, 10:55 pm, Graham Dumpleton <graham.dumple...@gmail.com>
wrote: