Internal server error 500 with mod_wsgi

[Alessandro Ronchi]

With mod_wsgi I only get error logged into apache and not on the interactive trackback in the browser, also If i set DEBUG=True in my settings.

Is there any way to handle the django trackback as usual?

--
Alessandro Ronchi

SOASI
Sviluppo Software e Sistemi Open Source
http://www.soasi.com
http://www.linkedin.com/in/ronchialessandro

[Alessandro Ronchi]

On Thu, Nov 19, 2009 at 12:48 AM, Alessandro Ronchi <alessand...@soasi.com> wrote:

With mod_wsgi I only get error logged into apache and not on the interactive trackback in the browser, also If i set DEBUG=True in my settings.

Is there any way to handle the django trackback as usual?

mod_wsgi also doesn't send me the email of errors. I really need them. Is it possible to make python send me an email of every internal error also with mod_wsgi?

[Graham Dumpleton]

On Nov 19, 10:48 am, Alessandro Ronchi <alessandro.ron...@soasi.com>
wrote:

> With mod_wsgi I only get error logged into apache and not on the interactive
> trackback in the browser, also If i set DEBUG=True in my settings.
>
> Is there any way to handle the django trackback as usual?

Is the error definitely from Django and if so from what part of
Django?

Perhaps post example of traceback.

Have you looked at 'DEBUG_PROPAGATE_EXCEPTIONS' setting.

http://docs.djangoproject.com/en/dev/ref/settings/#debug-propagate-exceptions

Also check over comments against:

http://docs.djangoproject.com/en/dev/ref/settings/#debug

and when tracebacks may be suppressed.

Graham

[Alessandro Ronchi]

http://dpaste.com/122205/
is my log file.

I don't used DEBUG_PROPAGATE_EXCEPTIONS
but as far as I understand it defaults to False, so Django should handle the error with usual trackback, also with mod_wsgi?

this is my vhost.conf (i'm using plesk):
http://dpaste.com/122208/

and this is my wsgi app:
http://dpaste.com/122209/

[Karen Tracey]

On Wed, Nov 18, 2009 at 7:29 PM, Alessandro Ronchi <alessand...@soasi.com> wrote:

http://dpaste.com/122205/
is my log file.

Traceback shows it is dying during the load of middleware.  You would not get a pretty debug page for this even with DEBUG=True and running the development server: you'd get a bare traceback, which is what you see in the Apache log.  This is code that is not covered by the exception-catching-turn-it-into-a-pretty-page try/except block.  Ultimately it says (stripping out the referrer and leading timestamp, etc):

   File "/var/www/vhosts/hobbygiochi.com/django/satchmo_src/satchmo/apps/livesettings/functions.py", line 67, in get_config
     raise SettingNotSet('%s config group does not exist' % group),
SettingNotSet: <unprintable instance object>

Which seems to imply something wrong with your satchmo config.  I don't know satchmo but it seems to be trying to complain about a config group not existing.  However it seems to run into trouble reporting the name of that group. That <unprintable> message might be implying the group name has non-ASCII data in it, which is making the SettingNotSet instance unprintable.  That  may be a clue or may be completely wrong -- it's just the only kind of situation where I've seen that sort of <unprintable> message crop up.

Karen

[Alessandro Ronchi]

On Thu, Nov 19, 2009 at 2:02 AM, Karen Tracey <kmtr...@gmail.com> wrote:

On Wed, Nov 18, 2009 at 7:29 PM, Alessandro Ronchi <alessand...@soasi.com> wrote:

http://dpaste.com/122205/
is my log file.

Traceback shows it is dying during the load of middleware.  You would not get a pretty debug page for this even with DEBUG=True and running the development server: you'd get a bare traceback, which is what you see in the Apache log.  This is code that is not covered by the exception-catching-turn-it-into-a-pretty-page try/except block.  Ultimately it says (stripping out the referrer and leading timestamp, etc):

   File "/var/www/vhosts/hobbygiochi.com/django/satchmo_src/satchmo/apps/livesettings/functions.py", line 67, in get_config
     raise SettingNotSet('%s config group does not exist' % group),
SettingNotSet: <unprintable instance object>

I get the same problem also with an Assert False (a typical debug symbol I've used with mod_python).

http://dpaste.com/122226/

no browser and no email, only logs.

[Karen Tracey]

On Wed, Nov 18, 2009 at 8:28 PM, Alessandro Ronchi <alessand...@soasi.com> wrote:

I get the same problem also with an Assert False (a typical debug symbol I've used with mod_python).

http://dpaste.com/122226/

no browser and no email, only logs.

You seem to have put the assert False in settings.py, and the code is (still) dying during load of middleware, since that is triggering a load of settings.  Look at the top of the trace.  The code is here:

http://code.djangoproject.com/browser/django/tags/releases/1.1.1/django/core/handlers/wsgi.py#L230

That is, within the call to self.load_middleware().  The special handling of exceptions that produces pretty debug pages and sends error email isn't done until you get into get_response (called down several lines from the load_middleware()):

http://code.djangoproject.com/browser/django/tags/releases/1.1.1/django/core/handlers/base.py#L66

Specifically when that method call handle_uncaught_exception:

http://code.djangoproject.com/browser/django/tags/releases/1.1.1/django/core/handlers/base.py#L136

which either produces the pretty error page or sends email, depending on DEBUG setting. 

Really, you can get both pretty debug pages and emails with mod_wsgi as well as you can with the development server or mod_python.  I've seen both.  The problem with both exception traces you have shown is that the exception is occurring too early in the processing -- neither of these exceptions you have posted would ever result in a debug page or an error email, regardless of deployment setup.

Karen

[Alessandro Ronchi]

Really, you can get both pretty debug pages and emails with mod_wsgi as well as you can with the development server or mod_python.  I've seen both.  The problem with both exception traces you have shown is that the exception is occurring too early in the processing -- neither of these exceptions you have posted would ever result in a debug page or an error email, regardless of deployment setup.

You're right.

I dont' understand why the trackback refers to another project django source. the pythonpath is correct in django.wsgi and empty in shell.

Is there something wrong?

[Alessandro Ronchi]

On Thu, Nov 19, 2009 at 5:28 PM, Alessandro Ronchi <alessand...@soasi.com> wrote:

Really, you can get both pretty debug pages and emails with mod_wsgi as well as you can with the development server or mod_python.  I've seen both.  The problem with both exception traces you have shown is that the exception is occurring too early in the processing -- neither of these exceptions you have posted would ever result in a debug page or an error email, regardless of deployment setup.

You're right.

I dont' understand why the trackback refers to another project django source. the pythonpath is correct in django.wsgi and empty in shell.

Is there something wrong?

as you can see here:

http://dpaste.com/122437/

my python path is correct, but the trackback points to another django directory.

 

[Karen Tracey]

On Thu, Nov 19, 2009 at 11:51 AM, Alessandro Ronchi <alessand...@soasi.com> wrote:

On Thu, Nov 19, 2009 at 5:28 PM, Alessandro Ronchi <alessand...@soasi.com> wrote:

Really, you can get both pretty debug pages and emails with mod_wsgi as well as you can with the development server or mod_python.  I've seen both.  The problem with both exception traces you have shown is that the exception is occurring too early in the processing -- neither of these exceptions you have posted would ever result in a debug page or an error email, regardless of deployment setup.

You're right.

I dont' understand why the trackback refers to another project django source. the pythonpath is correct in django.wsgi and empty in shell.

Is there something wrong?

as you can see here:

http://dpaste.com/122437/

my python path is correct, but the trackback points to another django directory.

I don't see where that page shows the PYTHONPATH setting?  Based on the traceback the python path apparently includes:

/var/www/vhosts/detectorpoint.com/django/django_src
/var/www/vhosts/detectorpoint.com/django/satchmo_src
/var/www/vhosts/hobbygiochi.com/django/projects

In the wsgi script you pointed to earlier you have:

BASE = '/var/www/vhosts/hobbygiochi.com/django/'

sys.path.append(BASE + 'projects/')
sys.path.append(BASE + 'satchmo_src/satchmo/apps/')
sys.path.append(BASE + 'django_src/')
sys.path.append(BASE + 'libraries/')

So I guess you are looking to pull django and satchmo out of /var/www/vhosts/hobbygiochi.com/django/, not /var/www/vhosts/detectorpoint.com/django/.  I'd guess the detectorpoint.com paths are already in sys.path when your wsgi script runs, and they aren't being over-ridden because you append to the existing path instead of putting the paths you are adding in front.

Karen

[Alessandro Ronchi]

On Thu, Nov 19, 2009 at 7:26 PM, Karen Tracey <kmtr...@gmail.com> wrote:

So I guess you are looking to pull django and satchmo out of /var/www/vhosts/hobbygiochi.com/django/, not /var/www/vhosts/detectorpoint.com/django/.  I'd guess the detectorpoint.com paths are already in sys.path when your wsgi script runs, and they aren't being over-ridden because you append to the existing path instead of putting the paths you are adding in front.

I thought the same thing, but this is my python path as django error trackback:

['/var/www/vhosts/hobbygiochi.com/django/projects/', '/var/www/vhosts/hobbygiochi.com/django/django_src/', '/var/www/vhosts/hobbygiochi.com/django/satchmo_src/', '/var/www/vhosts/hobbygiochi.com/django/libraries/', '/usr/lib/python2.4/site-packages/setuptools-0.6c9-py2.4.egg', '/usr/lib/python2.4/site-packages/MySQL_python-1.2.2-py2.4-linux-i686.egg', '/usr/lib/python2.4/site-packages/pycrypto-2.0.1-py2.4-linux-i686.egg', '/usr/lib/python24.zip', '/usr/lib/python2.4', '/usr/lib/python2.4/plat-linux2', '/usr/lib/python2.4/lib-tk', '/usr/lib/python2.4/lib-dynload', '/usr/lib/python2.4/site-packages', '/usr/lib/python2.4/site-packages/Numeric', '/usr/lib/python2.4/site-packages/PIL', '/usr/lib/python2.4/site-packages/gtk-2.0']

is it possible that different apache vhosts share the same pythonpath also if configuration is different?
how can I check that?