59

Nginxの背後にあるリモートサーバーにdjango 1.3があります。

django を apache + mod_wsgi で実行すると、apache ログ ファイルでエラーを確認できます。大丈夫ですが、コンソールに入れたいです。

django 独自の開発サーバーを実行すると、DEBUG = False の場合にのみコンソールでスタック トレースのエラーが発生します。DEBUG モードのコンソール出力

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

理由を知りたいですか？なぜdjangoは名前のない例外を出力するのですか? DEBUG 変数に依存するのはなぜですか。

このエラーは、リクエスト オブジェクトにアクセスできない場合に、主にビューの外で発生します。そのため、ミドルウェアやロギング ハンドラーを使用してキャッチすることはできません。

アップデート。djangoサーバーに直接リクエストしても、壊れたパイプが得られないことに気付きました。Nginxプロキシdjango中に問題が発生する可能性がありますか?

4

10 に答える 10

66

これは実際にはサイトの問題ではなく、Django devserver の問題です。このDjango チケットを参照してください。率直に言えば、既知のエラーであり、修正されないため、無視してください。

そのチケットのコメントでは、非常に明確な説明が提供されています。

多くの情報源によると、「壊れたパイプ」は通常のブラウザーの癖です。たとえば、ブラウザはソケットから読み取り、読み取っていた画像が明らかに変更されていないと判断します。ブラウザはこれ以上のデータを必要としないため、(強制的に) 接続を閉じます。このソケットのもう一方の端 (python runserver) は、クライアントが「ソケット パイプを壊した」ことをプログラムに伝えるソケット例外を発生させます。

于 2011-10-27T08:03:35.753 に答える
12

Nginx ディレクティブproxy_intercept_errors off;(デフォルトでは無効) が必要でした

于 2011-10-28T08:45:35.200 に答える
7

nginx ディレクティブ (チェック済みの回答) は機能しませんでしたが、Igor Katson と Michael_Scharf のモンキー パッチを組み合わせると、次のようになりました。

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()
于 2014-03-24T19:24:43.977 に答える
3

"./manage.py runserver" を使用したり、LiveServerTestCase テストを実行したりするときに、この迷惑なエラーを取り除く、迅速で汚いモンキー パッチ (有用なエラーを抑制するかどうかはわかりません) を思いつきました。

コード内の必要な場所に挿入するだけです。

# 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
于 2013-03-26T23:43:58.750 に答える
3

私はこれを取り除くことができました

proxy_buffering オフ;

これにより、プロキシされたサーバーの応答バッファリングが停止します。これにより、クライアントの接続が非常に遅い場合、バックエンド アプリケーションが長時間ロックされるという別の問題が発生します。

特定のリクエストに対して条件付きにするには、レスポンス ヘッダーでX-Accel-Buffering=noを使用します。

于 2013-03-16T06:44:06.567 に答える
0

tileliteの使用中にもこの問題に遭遇しました。これは、実際には Python の既知のバグが原因で、現在は修正されています。この問題は、次のパッチを適用することで解決できます。

http://bugs.python.org/issue14574

それ以外の場合は、Python の最新のビルドの 1 つをダウンロードできます。

于 2013-03-25T20:46:32.743 に答える