On nginx+fastcgi server site works except for /admin/ Unhandled Exception

[Dave Dash]

I'm getting the dreaded:

Unhandled Exception

An unhandled exception was thrown by the application.


Whenever I try to access /admin on my app under nginx+fastcgi.

To be sure, I tried the development server on the same machine and /
admin/ gave me the django admin prompt as expected.

I'm curious how to debug this.

[Jarek Zgoda]

Dave Dash napisał(a):

The "Enhandled Exception" is thrown by flup when it encounters condition
it is unable to cope with, because django did not handle 500 error (i.e.
exception thrown in request middlewares).

The easiest way is to turn debug on in flup (this requires modification
in either flup or django code, unfortunately). This way, you'd get exact
description of problem flup encountered when communicating with your
application. We got tons of such errors in (apparently) semi-random
places when we missed something in settings.

--
Jarek Zgoda
Skype: jzgoda | GTalk: zg...@jabber.aster.pl | voice: +48228430101

"We read Knuth so you don't have to." (Tim Peters)

[Malcolm Tredinnick]

For a start, what process is throwing an Unhandled Exception? Is it
Django (doubtful)? Or whatever Python fastcgi wrapper you are using? Or
is this "exception" not really a Python exception at all, but the same
word being used by, e.g., nginx?

Secondly, any application that throws an UnhandledException must surely
be logging the details somewhere (or the maintainer should be taken out
for a quick conversation with some of the more hefty participants at the
next conference he attends). So look in the error logs for clues.

Thirdly, try to narrow down where in the whole request-response pathway
the exception is being raised. Is any Django code being called? For
example, if you put some printing to a debug log into one of the views
of the admin app, is it printed? Or put some debugging printing into
django/core/handlers/wsgi.py to work out how far it gets there (since
that's the main wrapper function around the whole request handling).

At the moment, the only information you have is equivalent to a radio
report saying "there's a traffic jam somewhere in the city". It's not
going to help you or anybody else avoid the problem.

Hopefully that will give you some ideas.

Regards,
Malcolm

--
A clear conscience is usually the sign of a bad memory.
http://www.pointy-stick.com/blog/

[Jarek Zgoda]

Malcolm Tredinnick napisał(a):

> Secondly, any application that throws an UnhandledException must surely
> be logging the details somewhere (or the maintainer should be taken out
> for a quick conversation with some of the more hefty participants at the
> next conference he attends). So look in the error logs for clues.

I'm sorry to say but this is how flup works. The "Unhandled Exception"
is an output of flup's own error middleware.

[Dave Dash]

Hi Jarek,

Modifying django.core.servers.fastcgi.py was just what I needed to
find out where my "traffic jam" was.

I had an OperationalError from my sqlite3 database. I not only had to
update the permissions on sqlite3, but also on its containing
directory.

Worked like a charm. Hope this helps others.

-d