I managed to determine that the caching back-end was at fault in the previous steps, and from there I manually went through the code of the Django project and saw a few discrepancies in how the various developers had assigned their caching keys.
The use of the cache.set method is part of the low-level Django cache API and must be invoked manually so Django itself wasn't really at fault here, it was simply a human error - like it often is. Although that it made mod_wsgi seg fault isn't exactly optimal, there must be some other way of handling this scenario. You can read more about the low-level Django cache API here: http://docs.djangoproject.com/en/dev/topics/cache/#the-low-level-cache-api Paul On Feb 24, 4:20 pm, Frédéric Sidler <[email protected]> wrote: > How did you discover that and does Django use whitespace by default or is it > application dependant. > > My configuration is almost the same except I use mysql instead of > postgresql. I also use cmemcache and libmemcache instead of python-memcache. > > On Tue, Feb 24, 2009 at 5:10 PM, Paul Skarseth <[email protected]>wrote: > > > > > Just to specify what exactly caused the seg fault. If a Django cache > > key contains whitespace, such as: > > > cache.set(u'my key', value) > > > It induces a seg fault of mod_wsgi. As I mentioned previously, I don't > > know exactly why this is, but maybe some other inquisitive soul feels > > like getting to the bottom of it. > > > Paul > > > On Feb 24, 1:18 pm, Paul Skarseth <[email protected]> wrote: > > > Right, after a lengthy process it turns out that the Django project > > > itself was making an illegal call to the Django cache backend. If the > > > CACHE_BACKEND setting was removed from the Django settings file the > > > site loads perfectly. I can't say I know why this caused mod_wsgi to > > > seg fault, but the source of the error seems to be in the Django > > > project code. > > > > I'm sorry to have taken up your time with an issue that turned out to > > > not be directly connected to mod_wsgi after all. > > > > Paul > > > > On Feb 24, 12:27 pm, Paul Skarseth <[email protected]> wrote: > > > > > I saw "WSGIApplicationGroup %{GLOBAL}" mentioned in the documentation, > > > > but that's only supported from version 2.0 and up, right? The version > > > > of mod_wsgi that lives in the Ubuntu 8.04 repositories is 1.3-1, which > > > > is somewhat ancient. I'm tempted to upgrade to 2.3-1 using the debian > > > > package found here: > >http://packages.debian.org/stable/python/libapache2-mod-wsgi > > > > > But doing so would fault my initial decision as to use the LTS version > > > > of Ubuntu, aiming for stability by using tried and proven versions > > > > opposed to the latest and greatest. Alternatively pester the Ubuntu > > > > maintainers to upgrade mod_wsgi in the repositories. But I digress. > > > > > I will supply a gdb stack trace shortly. Thanks for helping with this. > > > > > Paul > > > > > On Feb 24, 11:46 am, Graham Dumpleton <[email protected]> > > > > wrote: > > > > > > Did you explicitly try forcing it to run in main interpreter? Use: > > > > > > WSGIApplicationGroup %{GLOBAL} > > > > > > Try for the gdb stack trace if you can though. > > > > > > Graham > > > > > > On 24/02/2009, at 10:30 PM, Paul Skarseth wrote: > > > > > > > Thanks for the fast reply, Graham. > > > > > > > I've gone through the documentation, but I couldn't find a use case > > > > > > fitting my dilemma. As for the Apache modules, the only additional > > > > > > modules installed besides the ones that come with a new > > installation > > > > > > of Apache is mod_wsgi and mod_php5, mod_python is not installed. > > The > > > > > > php mod is required by phpPgAdmin. Could this be a problem? Having > > to > > > > > > disable phpPgAdmin would be a big loss, but I'll try to remove it > > and > > > > > > its dependencies to see if it rectifies the problem. > > > > > > > Paul > > > > > > > On Feb 24, 11:06 am, Graham Dumpleton <[email protected]> > > > > > > wrote: > > > > > >> On 24/02/2009, at 9:59 PM, Paul Skarseth wrote: > > > > > > >>> Hi, > > > > > > >>> I've made a guide as how to set up an efficient and robust server > > to > > > > > >>> host and serve Django projects and I've opted to use Apache2 > > coupled > > > > > >>> with mod_wsgi; the only problem is that the mod_wsgi process > > keeps > > > > > >>> seg > > > > > >>> faulting. A note to keep in mind, this is done in a 64-bit > > > > > >>> environment. > > > > > > >>> The guide is located here: > >http://ethics-gradient.blogspot.com/2009/02/django-and-ubuntu-804-chr > > > > > >>> ... > > > > > > >>> The first issue is, if you simply run this command - "sudo > > apt-get > > > > > >>> install apache2 libapache2-mod-wsgi" - in Ubuntu 8.04 the newly > > > > > >>> restarted Apache process will continuously seg fault. For some > > > > > >>> reason, > > > > > >>> the user must manually stop apache, then start it; a simple call > > to > > > > > >>> the restart command doesn't work either. > > > > > > >>> But then, once mod_wsgi is set to load a Django project using the > > > > > >>> settings noted in the aforementioned guide, each request results > > > > > > >>> in a: > > > > > >>> "[notice] child pid xxxx exit signal Segmentation fault (11)" > > > > > > >>> I enabled "LogLevel info" but the additional log messages didn't > > > > > > >>> tell > > > > > >>> me much: > > > > > > >>> [info] mod_wsgi (pid=9251): Create interpreter 'test.gen.ki|'. > > > > > >>> [info] [client 127.0.0.1] mod_wsgi (pid=xxxx, process='gen.ki', > > > > > >>> application='test.gen.ki|'): Loading WSGI script '/home/django/ > > > > > >>> domains/ > > > > > >>> gen.ki/private/apache/genki.wsgi'. > > > > > >>> [error] [client 127.0.0.1] Premature end of script headers: > > > > > >>> genki.wsgi > > > > > >>> [info] mod_wsgi (pid=9270): Attach interpreter ''. > > > > > >>> [info] mod_wsgi (pid=9270): Enable monitor thread in process > > > > > >>> 'gen.ki'. > > > > > >>> [info] mod_wsgi (pid=9270): Enable deadlock thread in process > > > > > >>> 'gen.ki'. > > > > > > >>> If you have any insight as to why this might be happening, I > > would > > > > > >>> be > > > > > >>> very grateful if you would be willing to part with it. The guide > > > > > >>> should provide the necessary information as to how the system is > > set > > > > > >>> up, but please ask if there's anything missing. > > > > > > >> Have you read the documentation, in particular the sections which > > > > > >> talk about circumstances where crashes can occur. > > > > > >> http://code.google.com/p/modwsgi/wiki/InstallationIssues > > > > > >> http://code.google.com/p/modwsgi/wiki/ApplicationIssues > > > > > > >> Normally the problem is going to be a mismatch in shared library > > > > > >> versions used by Apache, PHP or some other Apache module and what > > a > > > > > >> Python module uses. In some cases the problem can be because of > > third > > > > > >> party Python modules not designed to run in sub interpreters. Not > > > > > >> knowing what your application does and what major Python modules/ > > > > > >> packages it uses, again makes it harder to guess. > > > > > > >> 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 -~----------~----~----~----~------~----~------~--~---
