Django Broken pipe en mode Debug

J'ai django 1.3 sur le serveur distant derrière Nginx.

Si je lance django avec apache + mod_wsgi, je peux regarder les erreurs dans les fichiers de log d'apache. C'est ok, mais j'aimerais avoir dans la console.

Si je lance django propre serveur de développement, j'ai des erreurs avec stacktrace en console uniquement lorsque DEBUG = False. En mode DEBUG console sorties

Exception happened during processing of request from (..., ...)
Traceback (most recent call last):
  File "/usr/local/python/lib/python2.7/SocketServer.py", line 284, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/local/python/lib/python2.7/SocketServer.py", line 310, in process_request
    self.finish_request(request, client_address)
  File "/usr/local/python/lib/python2.7/SocketServer.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/python/lib/python2.7/site-packages/django/core/servers/basehttp.py", line 570, in __init__
    BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
  File "/usr/local/python/lib/python2.7/SocketServer.py", line 641, in __init__
    self.finish()
  File "/usr/local/python/lib/python2.7/SocketServer.py", line 694, in finish
    self.wfile.flush()
  File "/usr/local/python/lib/python2.7/socket.py", line 301, in flush
    self._sock.sendall(view[write_offset:write_offset+buffer_size])
error: [Errno 32] Broken pipe

Je veux comprendre pourquoi? Pourquoi django juste sortie sans nom d'Exception? Pourquoi est-il dépendent de la variable DEBUG.

Cette erreur se produit surtout des vues sur l'extérieur quand je n'ai pas accès à l'objet de demande. Donc, je ne peux pas l'attraper dans l'intergiciel (middleware ou de l'utilisation de la journalisation gestionnaire.

Mise à JOUR. J'ai remarqué que si je demande à django directement le serveur je n'ai jamais Cassé la pipe. Donc, la question peut se produire alors que proxy Nginx django?

Je n'ai pas eu ce problème sur un serveur en ligne, mais il se produit de temps en temps sur le serveur de développement de django sur mon ordinateur local.. je n'ai pas été en mesure de résoudre ce soit
Il pourrait juste être NGINX expirer avant que django envoie la réponse. Quel est le "proxy_read_timeout" est activée dans votre nginx.fichier conf?

InformationsquelleAutor San4ez | 2011-10-27

broken-pipe django

55

Ce n'est pas vraiment un problème avec votre site, de plus avec le Django devserver: voir ce Django billet. Pour dire les choses crûment, juste l'ignorer car c'est une erreur connue, et ne sera pas corrigé.

Dans ce billet, les commentaires d'une explication est donnée:

Selon plusieurs sources, le "Broken Pipe" est un navigateur caprice. Par exemple, le navigateur lit à partir de la prise de courant et décide alors que l'image de ce qu'il lit, apparemment, n'a pas changé. Le navigateur maintenant, c' (de force) ferme la connexion, car il n'a pas besoin de plus de données. L'autre extrémité de cette prise (le python runserver) nous pose un socket exception d'indiquer au programme que le client a Cassé le support de tuyau'.
- Je vous remercie. J'ai vu que l'ancien billet avant. J'ai juste mis à jour question.
InformationsquelleAutor jro
8

Nginx directive proxy_intercept_errors off; (désactivé par défaut) est ce dont j'avais besoin
- Salut San4ez, comme vous le dites, cela semble être désactivé par défaut. Comment avez explicitement la désactivation de cette de résoudre votre problème? (Je pourrais avoir un problème lié...)
- Je ne suis pas tout à fait comprendre votre question. Imaginez, nginx procurations demande à django en amont et reçoit de l'état d'erreur (400 ou plus). Si proxy_intercept_errors est désactivé, nginx réponses page d'erreur comme c'est à partir de django. Sinon nginx arrêt de la lecture django réponse et l'envoyer à l'utilisateur page d'erreur personnalisée. Django serveur (ou tout autre) déclenche une erreur que le client ne lit pas de prise de broken pipe
- Compris; et en fait cela a fonctionné pour moi. C'est juste étrange parce que si proxy_intercept_errors est désactivée par défaut, explicitement éteindre devrait avoir aucun effet. Voir wiki.nginx.org/HttpProxyModule#proxy_intercept_errors
- Oui, bien sûr. Mais j'ai eu nginx config où cette option a été activée par quelqu'un
- La droite. Qui a du sens. Bizarrement, il a travaillé pour moi aussi, donc je suppose que la clé doit être généré dans un fichier quelque part dans certaines versions.
InformationsquelleAutor San4ez

La nginx directive (cocher la réponse) ne fonctionne pas pour moi, mais la combinaison de singe de patchs de Igor Katson et Michael_Scharf n':

def patch_broken_pipe_error():
    """Monkey Patch BaseServer.handle_error to not write
    a stacktrace to stderr on broken pipe.
    http://stackoverflow.com/a/22618740/362702"""
    import sys
    from SocketServer import BaseServer
    from wsgiref import handlers

    handle_error = BaseServer.handle_error
    log_exception = handlers.BaseHandler.log_exception

    def is_broken_pipe_error():
        type, err, tb = sys.exc_info()
        return repr(err) == "error(32, 'Broken pipe')"

    def my_handle_error(self, request, client_address):
        if not is_broken_pipe_error():
            handle_error(self, request, client_address)

    def my_log_exception(self, exc_info):
        if not is_broken_pipe_error():
            log_exception(self, exc_info)

    BaseServer.handle_error = my_handle_error
    handlers.BaseHandler.log_exception = my_log_exception

patch_broken_pipe_error()

Vous pouvez également activer proxy_ignore_client_abort option dans votre conf nginx. Dans ce cas, nginx ne cassera pas la connexion avec le backend si le client (navigateur web) est-ce que.
Ce code doit être mis en settings.py - à l'aide de Django 1.5.

InformationsquelleAutor Rick Mohr

Ici est une façon de prévenir les pour imprimer le message sur stderr. Juste monkey patch l'
BaseServer.handle_error fonction. C'est comment je le fais:

def patch_broken_pipe_error():
    """Monkey Patch BaseServer.handle_error to not write
    a stacktrace to stderr on broken pipe.
    https://stackoverflow.com/a/7913160"""
    import sys
    from SocketServer import BaseServer

    handle_error = BaseServer.handle_error

    def my_handle_error(self, request, client_address):
        type, err, tb = sys.exc_info()
        # there might be better ways to detect the specific erro
        if repr(err) == "error(32, 'Broken pipe')":
            # you may ignore it...
            logging.getLogger('mylog').warn(err)
        else:
            handle_error(self, request, client_address)

    BaseServer.handle_error = my_handle_error


patch_broken_pipe_error()

InformationsquelleAutor Michael_Scharf

2

J'ai été en mesure de se débarrasser de ce par

proxy_buffering off;

Cela s'arrête tampon de réponse de serveur mandaté. Cela conduit à d'autres problèmes de back-end de l'application verrouillée pendant longtemps si le client est sur une connexion extrêmement lente.

Le conditionner pour les demandes particulières, l'utilisation X-Accel-mise en mémoire Tampon=pas de dans l'en-tête de réponse.

InformationsquelleAutor rane
2

Je suis venu avec un quick and dirty monkey patch (je ne sais pas si il supprime tout utile erreurs), qui se débarrasse de cette fâcheuse erreur lors de l'utilisation de "./manage.py runserver" ou de l'exécution LiveServerTestCase tests.

Il suffit de l'insérer n'importe où dans votre code, si vous avez besoin de:
```
# Monkeypatch python not to print "Broken Pipe" errors to stdout.
import SocketServer
from wsgiref import handlers
SocketServer.BaseServer.handle_error = lambda *args, **kwargs: None
handlers.BaseHandler.log_exception = lambda *args, **kwargs: None
```
InformationsquelleAutor Igor Katson
0

Je suis tombé sur cette question lors de l'utilisation tilelite. C'est en fait causée par une connu, et maintenant corrigé, bug en python. Vous pouvez résoudre ce problème en appliquant le correctif suivant:

http://bugs.python.org/issue14574

Sinon, vous pouvez télécharger l'une des plus récentes versions de python.

InformationsquelleAutor Jason Huntley
0

Je l'ai corrigé.
Si vous utilisez des liens je.e, balise d'ancrage, à l'intérieur de la page, vous avez à faire face à la "Borken Pipe" du problème. Utilisez simplement à l'intérieur de la balise link href='#'. Ne laissez pas l'attribut href vide. Elle permettra d'éviter ce type d'erreur.

InformationsquelleAutor Gopi Kirupanithi

Vous devez vous connecter pour publier un commentaire.