タグ付けされた質問 「broken-pipe」

TCPまたはローカルUNIXソケットでの接続を受け入れ、単純なコマンドを読み取り、コマンドに応じて応答を送信する小さなサーバープログラムがあります。問題は、クライアントがときどき回答に関心を持たずに早く終了する可能性があるため、そのソケットに書き込むとSIGPIPEが発生し、サーバーがクラッシュすることです。ここでクラッシュを防ぐためのベストプラクティスは何ですか？行の反対側がまだ読んでいるかどうかを確認する方法はありますか？（select（）は、ソケットが書き込み可能であると常に表示するため、ここでは機能しないようです）。または、ハンドラーでSIGPIPEをキャッチして無視する必要がありますか？

260 c  io  signals  broken-pipe  sigpipe 

現在、Pythonで構築されたアプリを使用しています。パソコンで動かすと問題なく動作します。 しかし、それを運用サーバーに移動すると、次のように添付されたエラーが表示され続けます。 いくつかの調査を行ったところ、サーバーがデータの送信でビジー状態のときにエンドユーザーのブラウザーが接続を停止する理由がわかりました。 なぜそれが起こったのか、そしてそれが私のパソコンで動作しているときに、本番サーバーで正しく実行されない根本的な原因は何でしょうか。アドバイスは大歓迎です Exception happened during processing of request from ('127.0.0.1', 34226) Traceback (most recent call last): File "/usr/lib/python2.7/SocketServer.py", line 284, in _handle_request_noblock self.process_request(request, client_address) File "/usr/lib/python2.7/SocketServer.py", line 310, in process_request self.finish_request(request, client_address) File "/usr/lib/python2.7/SocketServer.py", line 323, in finish_request self.RequestHandlerClass(request, client_address, self) File "/usr/lib/python2.7/SocketServer.py", line 641, in __init__ self.finish() …

120 python  broken-pipe 

ピア側のソケットを閉じると、パイプの破損エラーがスローされることを知っています。 しかし、私のテストでは、ピア側が閉じているときにこちら側ですぐに「送信」呼び出しを行うと、必ずしもパイプの破損エラーが発生するとは限らないことに気付きました。 例えば： ピア側のソケットを閉じた後（closeを呼び出してクリーンクローズを試み、ピアを強制終了して異常なクローズを試みました）、40バイトを送信しようとすると、パイプが壊れることはありませんが、 40000バイトを送信すると、すぐに壊れたパイプエラーが発生します。 パイプの破損の正確な原因とその動作を予測できますか？

83 c  broken-pipe