Unhandled exception in Flup

Question

I came across the terrible "unhandled exception" raised by Flup. The sad part is raising at the webserver level (lighttpd + flup), and not at the application level (Django). Thus, there are no 500 messages about where the problem is.

Our entire team struggled to clear the code base, despite any ambiguous imports and some similar things, just to eliminate the possibility of errors due to ambiguous imports. And we cleared a lot of things in the code. All the same exceptions.

To be honest, I'm really disappointed with Flup error handling. It doesn’t say anything. Worst of all, it shows the same "Unhandled Exception" for Users. How do I get through this?

I checked the lighttpd logs. All I see is "Interface Error / Connection Already Closed." This only happens when my application is in FCGI mode. So the problem is how flup actually deals with my code (application). How do I get through this?

I checked alternatives for flup, but Django clearly depends on flup (which is another limitation and puzzles me) (Link: django_src / django / core / servers / fastcgi.py line: 100/131)

How do I debug (at least) this script and solve the problem? Please help me. The application does not work for 3 days.

Answer 1

I do not use lighttpd or flup, so this is not an answer as far as hints are given.

I would start by trying to run the PDB in your application file, or at least write to the log file before you call the .run () flp server method. This way you can identify the problem as being in fastcgi or in flup. See the Python Interactive Debugger section on the mod_wsgi wiki. This may give you ideas on how to do the same with lighttpd and flup.

Then, if the problem is in flup, you will catch the exception in pdb and you can debug from there.

If the problem is lighttpd, you probably have some kind of problem in your configuration file or maybe a problem with how lighttpd was created. Perhaps there is a system library mismatch between lighttp and its fastcgi module?

Try running the application under nginx + fastcgi and see if this works or at least gives you the best error messages.

Btw, the author of flup hates FCGI and doesn't even use flup anymore ... I would recommend switching to nginx or Apache + mod_wsgi.

Answer 2

This indicates an error long before Django starts processing the request, for example, a syntax error in the settings module. The fastest way to debug such a problem is to enable FastCGI debugging. This is line 128 in django/core/servers/fastcgi.py :

 wsgi_opts['debug'] = False # Turn off flup tracebacks 

Then run the application with such a modified Django, you will see the Flup trace in all its glory.

Answer 3

I hit something like this - we have Django behind NGINX and we allow Django to process 500 - it works 99.9% of the time, but when we do updates, sometimes these “Unhandled Exceptions” skip.

Django does not override flip hooks for error handling, so we need to do this ourselves, and let Django handle these errors.

First, override the flup.server.BaseFCGIServer.error errors in Django. Then we tell Django to use our modified BaseFCGIServer to see these errors.

Since Python is awesome, we will cheat and simply disarm it all in one place, django.core.servers.fastcgi.py . Here we go:

 # django.core.servers.fastcgi.py def runfastcgi(argset=[], **kwargs): # ... # Paste his hack right after the `module` try/catch. # Override BaseFCGIServer.error to use Django error handling. # http://trac.saddi.com/flup/browser/flup/server/fcgi_base.py#L1210 def patch_error(self, req): import sys from django.conf import settings from django.core import urlresolvers from django.core.handlers.wsgi import WSGIRequest urlconf = settings.ROOT_URLCONF urlresolvers.set_urlconf(urlconf) resolver = urlresolvers.RegexURLResolver(r'^/', urlconf) # No access to 'environ' so rebuild WSGIRequest. # http://trac.saddi.com/flup/browser/flup/server/fcgi_base.py#L1077 environ = req.params environ.update(self.environ) environ['wsgi.version'] = (1,0) environ['wsgi.input'] = req.stdin self._sanitizeEnv(environ) wsgireq = WSGIRequest(environ) # http://code.djangoproject.com/browser/django/trunk/django/core/handlers/base.py#L177 response = self.application.handle_uncaught_exception(wsgireq, resolver, sys.exc_info()) # TODO: NGINX figures this out, but other servers might not. # http://trac.saddi.com/flup/browser/flup/server/fcgi_base.py#L1104 req.stdout.write('Status: 500\r\n') req.stdout.write('Content-Type: text/html\r\n\r\n' + response.content) WSGIServer.error = patch_error 

Now you can use Django stack traces even for level-level errors!