On 11 August 2010 00:14, bo <[email protected]> wrote: > Hi all, > > I've recently inherited a django site that's been behaving very > strangely of late. When the app starts up it runs fine for a while, > but after some time (anywhere between 1 hour and 24 hours, possibly > depending on server load) it starts to consistently return 500 errors. > > Given that it runs fine to begin with, I'm tending to rule out the > standard apache permissions issues that everyone runs into at one > point or another. As far as I can tell, apache has all the permissions > it needs to read files, write pyc files in place, etc. > > When the site starts to fail, the error in the apache log refers to a > particular line in one of our app's models.py files: > > > [Tue Aug 10 22:20:16 2010] [error] [client 127.0.0.1] from > glue.models import BaseContent, ContactMixin, LocationMixin > [Tue Aug 10 22:20:16 2010] [error] [client 127.0.0.1] ImportError: > cannot import name BaseContent > > > (where those are all models that are properly defined elsewhere in the > django app) > > This would normally provide a clue as to where the problem is (a path > issue, perhaps?), except that the error disappears if you force the > system to regenerate the .pyc for the failing model.py. It will then > work happily for a while, until the same issue comes up again some > hours later. It seems like something is periodically causing this > particular pyc to be unusable by mod_wsgi.
That solution doesn't make too much sense as once a Python module is loaded into memory, the .pyc file on disk is ignored. For that to make a difference, you would also have to be restarting the processes. What else are you doing besides removing the .pyc file? Are you also restarting Apache, or if using daemon mode, touching the WSGI script file? Also post the relevant mod_wsgi configuration from Apache configuration file. > This still feels like a permissions issue, as the built-in django > runserver can load the model without problems, even when mod_wsgi is > failing. > > Has anyone seen anything like this before? The last time I talked to a Django developer, they were of the opinion that people are having these sorts of problems because they are not following the rules in respect of how Django is supposed to be used. Personally, and as I have blogged at: http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html I have issues in respect of Django WSGI handler not setting up process environment the same as the Django development server. Specifically, development server preloads a lot of stuff when code still running single threaded. With WSGI handler, lazy loading occurs, potentially under context of concurrent requests running in multiple threads. Either Django itself may have problems with multithreading still, or even the way your own code lazily imports stuff it needs may be the cause. I also have issues with fact that Django development server allows for modules to be imported via multiple package paths and whether than double loading also causes issues. So, try the new WSGI script file at end of that blog post. Do however please try and provide as much information as possible, starting with my questions above. Although I suspect a problem and that WSGI script may resolve it for some people, no closer to working out what the actual problem is. In general people use the new WSGI script file contents and then cant be bothered helping to try and duplicate the original problem and perhaps provide a mini Django site which exhibits the problem and what URLs were hit when problem first started and what code that mapped to. 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.
