Flup中未处理的异常

Question

我正面临着由Flup引发的可怕的“未处理异常”。可悲的是它是在not服务器(lighttpd+flup)级别提出的，而不是在应用程序级别(Django)提出的。所以没有500封关于问题所在的电子邮件。

我们的整个团队努力清理代码库，以防有任何模棱两可的导入和类似的人，只是为了消除由于模棱两可的导入而引发错误的机会。我们清理了代码中的很多东西。仍然是同样的例外。

坦率地说，我真的对Flup的错误处理感到沮丧。它不会告诉你任何事情。最糟糕的是，它向用户显示了相同的“未处理异常”。我怎么才能通过这个？

我查了lighttpd的日志。我看到的只是“接口错误/连接已关闭”。只有当我的应用程序在FCGI模式下运行时，它才会发生。所以问题在于flup实际上是如何处理我的代码(应用程序)的。我怎么才能通过这个？

我检查了flup的替代品，但Django明确地依赖于flup (这是另一个限制，令人困惑的me)(Reference:django_src/django/core/servers/fastcgi.py行:100/ 131)

我如何调试(至少)这个场景并解决问题？请帮帮我。应用程序已停机3天。

Answer 1

我没有使用lighttpd或flup，所以这不是一个答案，而是一个提示。

首先，我会尝试在应用程序文件中运行PDB，或者至少在调用flup服务器的.run()方法之前写入日志文件。这样，您就可以确定问题是出现在fastcgi中还是出现在flup中。请参阅mod_wsgi维基中名为Python Interactive Debugger的部分。这可能会给你一些关于如何用lighttpd和flup做同样的事情的想法。

然后，如果问题是flup，您将在pdb中捕获异常，并可以从那里进行调试。

如果问题出在lighttpd上，那么您的配置文件中可能存在某种类型的问题，或者可能是lighttpd的构建方式有问题。也许在lighttp和它的fastcgi模块之间存在系统库不匹配？

尝试在nginx+fastcgi下运行你的应用程序，看看它是否有效，或者至少能给你更好的错误消息。

顺便说一句，flup hates FCGI and doesn't even use flup anymore的作者...我建议改用nginx或apache+mod_wsgi。

Answer 2

这表示在Django开始处理请求之前就出现了错误，比如设置模块中的语法错误。调试此类问题的最快方法是打开FastCGI调试。这是django/core/servers/fastcgi.py中的第128行

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

然后用这样修改过的Django运行应用程序，你会看到Flup回溯的整个辉煌。

Answer 3

我遇到了类似的事情-我们在NGINX后面有Django，我们允许Django处理500s - 99.9%的时间是有效的，但当我们进行升级时，有时这些“未处理的异常”会漏掉。

Django没有覆盖flup的钩子来处理错误，所以我们需要自己来做，让Django来处理这些错误。

首先通过Django覆盖flup.server.BaseFCGIServer.error到错误。然后，我们将告诉Django使用修改后的BaseFCGIServer来查看这些错误。

因为Python很棒，所以我们会作弊，把所有的东西都放在一个地方，django.core.servers.fastcgi.py。我们开始吧：

# 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

现在您可以享受Django堆栈跟踪，即使是flup级别的错误！