Необработанное исключение в Flup - PullRequest
Новая
       38

Необработанное исключение в Flup

6 голосов
/ 09 февраля 2009

Я стою перед страшным «Необработанным исключением», поднятым Флупом. Грустная часть - это поднятие на уровне веб-сервера (lighttpd + flup), а не на уровне приложения (Django). Таким образом, нет 500 электронных писем о том, где проблема.

Вся наша команда изо всех сил пыталась очистить базу кода, в случае каких-либо неоднозначных импортов и чего-то в этом роде, просто чтобы исключить вероятность возникновения ошибок из-за неоднозначного импорта. И мы убрали много вещей в коде. Все еще то же исключение.

Честно говоря, я действительно разочарован обработкой ошибок Flup. Это ничего вам не говорит. Хуже всего то, что он показывает то же самое «необработанное исключение» для пользователей. Как мне пройти это?

Я проверил логи lighttpd. Я вижу только «Ошибка интерфейса / соединение уже закрыто». Это происходит только тогда, когда мое приложение работает в режиме FCGI. Так что проблема в том, как на самом деле flup работает с моим кодом (приложением). Как мне пройти это?

Я проверил альтернативы для flup, но Django явно зависит от flup (что является еще одним ограничением и озадачило меня) (ссылка: django_src / django / core / servers / fastcgi.py строка: 100/131)

Как мне отладить (по крайней мере) этот сценарий и решить проблему? Пожалуйста, помогите мне. Приложение не работает в течение 3 дней.

Ответы [ 3 ]

9 голосов
/ 09 февраля 2009

Это указывает на ошибку задолго до того, как Django начинает обработку запроса, например, синтаксическая ошибка в модуле настроек. Самый быстрый способ отладить такую ​​проблему - включить отладку FastCGI. Это строка 128 в django/core/servers/fastcgi.py: 

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

Затем запустите приложение с таким измененным Django, вы увидите трассировку Flup во всей ее красе.

6 голосов
/ 08 ноября 2010

Я столкнулся с чем-то похожим - у нас Django стоит за NGINX, и мы позволяем Django обрабатывать 500 с - это работает в 99,9% случаев, но когда мы делаем обновления, иногда эти «необработанные исключения» проскальзывают. 1001 *

Django не переопределяет хуки flup для обработки ошибок, поэтому нам нужно сделать это самим, и позволить Django обрабатывать эти ошибки.

Первое переопределение flup.server.BaseFCGIServer.error к ошибкам через Django. Затем мы скажем 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 даже для ошибок уровня флопа!

3 голосов
/ 09 февраля 2009

Я не использую lighttpd или flup, так что это не столько ответ, сколько подсказки.

Я бы начал с попытки запустить PDB в файле вашего приложения или, по крайней мере, для записи в файл журнала перед вызовом метода .run () сервера flup. Таким образом, вы можете определить проблему как в fastcgi или в флюпе. См. Раздел Python Interactive Debugger в вики mod_wsgi. Это может дать вам идеи о том, как сделать то же самое с lighttpd и flup.

Тогда, если проблема в ошибке, вы поймаете исключение в pdb и сможете отлаживать оттуда.

Если проблема в lighttpd, то, возможно, у вас есть какая-то проблема в вашем конфигурационном файле, или, возможно, проблема с тем, как был построен lighttpd. Может быть, несоответствие системной библиотеки между lighttp и его модулем fastcgi?

Попробуйте запустить приложение под nginx + fastcgi и посмотрите, работает ли оно или, по крайней мере, дает вам лучшие сообщения об ошибках.

Кстати, автор flup ненавидит FCGI и даже больше не использует flup ... Я бы порекомендовал перейти на nginx или apache + mod_wsgi.

...