500.html not showing w/ mod_python

[Shev]

Hi all - I'm using apache2 and mod_python (sitting behind nginx) and
the latest trunk version of django, and have setup the 500.html error
template as suggested. Unfortunately, it doesn't seem to work -
whenever there's a problem causing django to throw an exception, I end
up seeing the simple and ugly default apache "Internal Server Error"
page instead of my custom 500.html error page.

My custom 404.html page works just fine, so I'm puzzled why its
500.html cousin isn't working. Also, though I've setup the ADMINS
param in the settings file, I never get any emails when exceptions are
thrown (though I guess if the 500.html isn't being used, that should
be expected).

Any ideas? Thanks in advance for any help!

[Karen Tracey]

What traceback do you see exactly?  I can think of two possibilities -- either your 500.html is not being found, or you are running into something where Django is not catching the exception (see for example http://code.djangoproject.com/ticket/6094 for cases where Django does not yet trap exceptions).  The exact traceback would hopefully point to one or the other of these.

Karen

[Shev]

Thanks for the feedback - I'm not seeing any traceback - just the
vanilla "Internal Server Error" page that apache2 comes with,
seemingly for all exceptions (e.g. failed import, bad template
operation, bad logic in a view, etc. etc.) When I turn DEBUG = True
on in the settings, then the standard Django traceback/error page
comes on just fine - but I don't want that to show on the production
server, of course.

Is it possible that the 500.html is not being found yet the 404.html
is being found? Both files are in the same place and have the same
ownership/permissions, and the 404.html *is* working.



On Jan 14, 11:47 pm, "Karen Tracey" <kmtra...@gmail.com> wrote:

> On Jan 14, 2008 11:36 PM, Shev <odon...@gmail.com> wrote:
>
>
>
>
>
> > Hi all - I'm using apache2 and mod_python (sitting behind nginx) and
> > the latest trunk version of django, and have setup the 500.html error
> > template as suggested. Unfortunately, it doesn't seem to work -
> > whenever there's a problem causing django to throw an exception, I end
> > up seeing the simple and ugly default apache "Internal Server Error"
> > page instead of my custom 500.html error page.
>
> > My custom 404.html page works just fine, so I'm puzzled why its
> > 500.html cousin isn't working. Also, though I've setup the ADMINS
> > param in the settings file, I never get any emails when exceptions are
> > thrown (though I guess if the 500.html isn't being used, that should
> > be expected).
>
> > Any ideas? Thanks in advance for any help!
>
> What traceback do you see exactly? I can think of two possibilities --
> either your 500.html is not being found, or you are running into something

> where Django is not catching the exception (see for examplehttp://code.djangoproject.com/ticket/6094for cases where Django does not

[Karen Tracey]

On Jan 15, 9:34 am, Shev <odon...@gmail.com> wrote:
> Thanks for the feedback - I'm not seeing any traceback - just the
> vanilla "Internal Server Error" page that apache2 comes with,
> seemingly for all exceptions (e.g. failed import, bad template
> operation, bad logic in a view, etc. etc.) When I turn DEBUG = True
> on in the settings, then the standard Django traceback/error page
> comes on just fine - but I don't want that to show on the production
> server, of course.
>

Then you need to check the apache error log, the traceback should be
included there.

> Is it possible that the 500.html is not being found yet the 404.html
> is being found? Both files are in the same place and have the same
> ownership/permissions, and the 404.html *is* working.
>

Seems unlikely, but without a traceback its hard to be sure.

Karen

[Shev]

On Jan 15, 10:05 am, Karen Tracey <kmtra...@gmail.com> wrote:
> Then you need to check the apache error log, the traceback should be
> included there.

What should I be looking for? The tracebacks are there in the log,
but I've found it never provides the useful and accurate information
that the Django debugging page does; the only way I can effectively
debug is to see what Django thinks is wrong. Thanks!

[Karen Tracey]

 
Bare tracebacks provide more limited information than a Django debug page, but they're still accurate and informative, since they still tell you the sequence of calls that led to the error.  If you're having trouble making sense of what's in the log someone from the list may be able to help if you post the information.  I suspect copy/pasting it from the log to an email might mangle it rather badly, so posting it to someplace like dpaste.com and then providing a pointer to it on the list might be best.

As for what to be looking for, if it's a case of Django not finding the 500.html, you should see something like:

       raise TemplateDoesNotExist, name
TemplateDoesNotExist: 500.html

at the end of the traceback in the log.  If that's not the problem, it'll be something else...but without seeing what's actually in the log it's hard for me to guess what it might be.

Karen

[Shev]

Sorry to have not replied sooner. I figured out the two things going
on about this problem, both my mistakes:

1) I neglected to turn PythonDebug to "On" in my apache conf file.
Ooops.

2) My 500.html extends a base template and also assumes a populated
RequestContext like all my other templates. Belatedly I realized that
the standard django 500 handler doesn't pass through any context
variables that I relied on in TEMPLATE_CONTEXT_PROCESSORS. A custom
500 handler does the trick. Ah well, RTFM.

Hope this helps someone else in the future.





On Jan 15, 1:58 pm, "Karen Tracey" <kmtra...@gmail.com> wrote: