Flup에서 처리되지 않은 예외

Question

나는 Flup에 의해 제기 된 두려워한 "처리되지 않은 예외"를 직면하고 있습니다. 슬픈 부분은 webserver (lighttpd + flup) 레벨에서 발생하고 어플리케이션 레벨 (Django)에서는 발생하지 않습니다. 따라서 문제가있는 곳에 대해서는 500 건의 이메일이 발송되지 않습니다.

우리 팀 전체가 코드베이스를 정리하고 모호한 수입과 그와 같은 누군가를 생각해 내기 위해 애썼지 만 모호한 수입으로 인한 오류 발생 가능성을 없애기 위해 애썼다. 그리고 우리는 코드에서 많은 것들을 정리했습니다. 여전히 같은 예외입니다.

나는 솔직히 말해서 Flup의 오류 처리에 실망합니다. 그것은 당신에게 아무 것도 말하지 않습니다. 최악의 경우, 사용자에게 동일한 "처리되지 않은 예외"를 표시합니다. 이걸 어떻게 통과시켜야합니까?

lighttpd 로그를 확인했습니다. 내가 보는 것은 "Interface Error/Connection already closed."입니다. 응용 프로그램이 FCGI 모드에서 실행될 때만 발생합니다. 그래서 문제는 flup이 실제로 내 코드 (응용 프로그램)를 다루는 방법입니다. 이걸 어떻게 통과시켜야합니까?

나는 flup에 대한 대안을 확인하지만, 장고 명시 적으로 flup에 따라 달라집니다 (또 하나 개의 제한이다, 나를 의아해) (참조 : django_src/장고/코어/서버/fastcgi.py 라인 : 100/131)

이 시나리오를 디버그 (최소한)하고 문제를 해결하려면 어떻게해야합니까? 제발 도와주세요. 신청서가 3 일간 다운되었습니다.

Answer 1

나는 lighttpd 나 flup을 사용하지 않으므로, 힌트만큼이나 답이 아니다.

필자는 flup 서버 .run() 메소드를 호출하기 전에 앱 파일에서 PDB를 실행하거나 로그 파일에 적어도 쓰는 것으로 시작하겠다. 그렇게하면 fastcgi 또는 flup에있는 것으로 문제를 식별 할 수 있습니다. mod_wsgi 위키의 Python Interactive Debugger 섹션을 참조하십시오. Lighttpd와 flup을 사용하여 동일한 작업을 수행하는 방법에 대한 아이디어를 얻을 수 있습니다.

그런 다음 문제가 flup 인 경우 pdb에서 예외를 catch하고 거기에서 디버깅 할 수 있습니다.

문제가 lighttpd 인 경우 구성 파일에 문제가 있거나 lighttpd가 작성된 방식에 문제가있을 수 있습니다. lighttp와 fastcgi 모듈 사이에 시스템 라이브러리 불일치가있을 수 있습니까?

nginx + fastcgi에서 앱을 실행 해보고 작동하는지 또는 더 나은 오류 메시지를 제공하는지 확인하십시오.

Btw, 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 

는 다음과 같은 수정 장고와 응용 프로그램을 실행, 당신은 모든 영광에서 Flup 역 추적을 볼 수 있습니다.

Answer 3

NGINX 뒤에 Django가 있는데, Django가 500s를 처리하도록 허용합니다. 이는 99.9 %의 시간 동안 작동하지만 업그레이드를 수행 할 때 때때로 이러한 "처리되지 않은 예외"가 통과됩니다.

장고는 오류 처리를 위해 flup의 후크를 오버라이드하지 않으므로 스스로 처리해야하고 장고가 이러한 오류를 처리하도록해야합니다.

장고를 통해 오류가있는 경우 flup.server.BaseFCGIServer.error이 우선 적용됩니다. 그런 다음 Django에 수정 된 BaseFCGIServer을 사용하여 이러한 오류를 확인합니다.

파이썬이 멋지 기 때문에, 우리는 속임수를 사용하고 모든 것을 한 곳에서 정확히 스케치합니다. 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 

이제 flup 수준의 오류도 장고 스택 추적을 즐길 수 있습니다!