views:

50

answers:

2

Hi. When I run my django project on apache with mod_wsgi, I receive something like that:

    [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145] Traceback (most recent call last):
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]   File "/usr/local/lib/python2.6/site-packages/Django-1.1.1-py2.6.egg/django/core/handlers/wsgi.py", line 245, in __call__
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]     response = middleware_method(request, response)
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]   File "/usr/local/lib/python2.6/site-packages/Django-1.1.1-py2.6.egg/django/contrib/sessions/middleware.py", line 28, in process_response
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]     if request.session.get_expire_at_browser_close():
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]   File "/usr/local/lib/python2.6/site-packages/Django-1.1.1-py2.6.egg/django/contrib/sessions/backends/base.py", line 229, in get_expire_at_browser_close
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]     if self.get('_session_expiry') is None:
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]   File "/usr/local/lib/python2.6/site-packages/Django-1.1.1-py2.6.egg/django/contrib/sessions/backends/base.py", line 63, in get
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]     return self._session.get(key, default)
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]   File "/usr/local/lib/python2.6/site-packages/Django-1.1.1-py2.6.egg/django/contrib/sessions/backends/base.py", line 172, in _get_session
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]     self._session_cache = self.load()
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]   File "/usr/local/lib/python2.6/site-packages/Django-1.1.1-py2.6.egg/django/contrib/sessions/backends/db.py", line 18, in load
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]     return self.decode(force_unicode(s.session_data))
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]   File "/usr/local/lib/python2.6/site-packages/Django-1.1.1-py2.6.egg/django/contrib/sessions/backends/base.py", line 93, in decode
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]     encoded_data = base64.decodestring(session_data)
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]   File "/usr/local/lib/python2.6/base64.py", line 321, in decodestring
        [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145]     return binascii.a2b_base64(s)
 [Wed Mar 10 08:46:43 2010] [error] [client 10.13.1.145] Error: Incorrect padding

Is there any suggestion, clue or solution?

A: 

Sounds like one of the entries in the django_session table might be malformed. Either inspect the table and remove the broken row, or you can truncate the table altogether if you can live with that.

Ignacio Vazquez-Abrams
Generally on development server work fine. Error ocure on the first run. syncdb is only thing done before first test
hubertus
The problem lay in the database. Thanks
hubertus
A: 

Here are a few suggestions for places to look:

  1. Your paths in the traceback point to /usr/local/lib/python2.6/ ... maybe you built mod_wsgi with a different version of Python, especially the system installed version probably in /usr/lib/pythonX.X. When building mod_wsgi you need to use this:

    ./configure --with-python=/usr/local/bin/python2.6

  2. Check your apache error log to see if there are any useful messages in there, especially ones that are documented at mod_wsgi Installation Issues.

  3. When you run syncdb, even for the "first time", are you seeing messages about the auth tables being created? Maybe you still have an old auth table in your database and can fix the problem by completely dropping the database and starting from scratch (or doing something like manage.py reset

Van Gale
In respect of (1), if mod_wsgi was built against system Python it should find it okay at runtime okay. It is the other way around which is normally the problem where compiled to use alternate version but still finds the system one at runtime. That it is using /usr/local version suggests that isn't the issue, unless they made the mistake of manually setting up sys.path in some way so that it looked in installation directories for a different version of Python than what mod_wsgi was built for. So mixing installations can be a problem, but it would have required them to have caused the problem.
Graham Dumpleton
The problem lay in the database. Thanks for help
hubertus
Going foreward, sometimes other apps like Track like use mod_python instead mod_wsgi. It can be problem when mod_python load other instance of python that we expect running mod_wsgi
hubertus