問題タブ [broken-pipe]

2 つのプロセスをパイプし、パイプの「出力」で 1 つを強制終了すると、最初のプロセスが「Broken Pipe」シグナルを受信するために使用され、通常はそれも終了していました。例：ランニング

SuSE8またはそれ以前のリリースでは、すぐにレスポンシブ シェルに戻ります。今日それを試しているとき、手動で強制終了するまで、do_something_tensiveは明らかにまだ実行されています。プログラムが「壊れたパイプ」を無視するようにする何かが変更されたようです（glib？シェル？）...

あなたの誰かがこれについてのヒントを持っていますか? 以前の動作を復元する方法は? なぜ変更されたのですか (または、常に複数のセマンティクスが存在するのはなぜですか) ?

edit : さらにテスト (strace を使用) すると、「SIGPIPE」が生成されていることがわかりますが、プログラムは中断されていません。シンプルな

エンドレスに続きます

レスが殺されたとき。プログラムでシグナルハンドラをプログラムして確実に終了させることはできますが、SIGPIPEでプログラムを強制的に終了させる環境変数またはシェルオプションをもっと探しています

もう一度編集: tcsh 固有の問題 (bash が適切に処理) と端末依存 (Eterm 0.9.4) のようです。

TCPまたはローカルUNIXソケットで接続を受け入れ、単純なコマンドを読み取り、（コマンドに応じて）応答を送信する小さなサーバープログラムがあります。

問題は、クライアントが答えに興味がなく、場合によっては早期に終了する可能性があることです。そのため、そのソケットに書き込むとSIGPIPE、サーバーがクラッシュします。

ここでのクラッシュを防ぐためのベストプラクティスは何ですか？行の反対側がまだ読んでいるかどうかを確認する方法はありますか？（select()ソケットは書き込み可能であると常に表示されるため、ここでは機能しないようです）。SIGPIPEまたは、ハンドラーでをキャッチして無視する必要がありますか？

クライアント接続ごとに新しいスレッドを作成する単純なマルチスレッド ゲーム サーバーを Python で作成しました。ときどき、壊れたパイプ/SIGPIPE エラーが原因でサーバーがクラッシュすることがわかりました。プログラムが存在しなくなったクライアントに応答を返そうとしたときに、それが起こっていると確信しています。

これに対処する良い方法は何ですか? 私の好みの解決策は、プログラム全体を終了するのではなく、クライアントへのサーバー側接続を閉じて先に進むことです。

PS:この質問/回答は、一般的な方法で問題を扱っています。具体的にどのように解決すればよいですか？

次のPHPスクリプトがあります。

私が実行した10回のうち約7回、gitは次のエラーを出します：

シェルから直接同等のコマンドを実行すると、このエラーは発生しません。

私はすでに試しました：

• 他の PHP 実行関数の使用: exec、system、popen;
• コマンド全体を引数として bash に渡します。つまり、exec('bash -c '.$cmd);

何が起こっているのか誰にも分かりませんか？

solarisでは、send()呼び出しで壊れたソケットを検出する方法は? 私は信号を使用したくありません。
SO_NOSIGPIPE と MSG_NOSIGNAL を試しましたが、どちらも Solaris では使用できず、プログラムが「壊れたパイプ」エラーで強制終了されました。

壊れたパイプを検出する方法はありますか?

ありがとう！

このエラーが発生し続けますMemCacheError（パイプが壊れています）： Railsアプリでパイプが壊れていますが、その理由がわかりません。

コントローラでmemcachedにアクセスRails.cacheすると、最初の1つまたは2つの読み取り/書き込みで常に壊れたパイプエラーがスローされるようです。しかし、新しいオブジェクトを作成してmemcachedにアクセスすると、ActiveSupport::Cache::MemCacheStore.newこのエラーは発生しないようです。

また、別のrubyプロセスでmemcachedにアクセスしますが、memcachedにアクセスする方法に関係なく、最初の読み取りで常にこのエラーが発生します。読み取りを再試行するだけで回避策を実装しましたが、idの方が長期的な解決策があります。

現在、この問題が発生するのは、memcachedを再起動した後だけです。Rails2.3.5とmemcached1.4.4を使用しています（memcached 1.2.2でもこれを試しました）。

Django 1.2 開発サーバーを実行していますが、Chrome または Safari でそこからページを読み込むたびに、Broken Pipe エラー メッセージが表示されます。私の同僚も、開発サーバーからページをロードするときにエラーを受け取ります。Opera または Firefox を使用している場合、これらのエラーは発生しません。

誰でも私を助けることができますか？私はこれに夢中になります！

これをオンラインで投稿している人がたくさんいることは知っていますが、解決策を見つけることができませんでした.

Web サイトが 6 ～ 8 時間以上アクセスされていない場合、Errno::EPIPE を受け取ります。ruby-mysql ドライバーに関係している可能性があると読みましたが、解決策は見つかりませんでした。これが完全なトレースです。パッセンジャーとmysqlを使用して、ApacheでRuby on Railsサーバーを実行しています。助けてくれてありがとう！！！

記事 (または記事のコレクション) を PDF にレンダリングするために、Mediawiki Collection Extension と mwlib をインストールしました。これは、単一の記事と最大 20 の記事を含むコレクションで非常にうまく機能します。

大きなコレクションをレンダリングすると、解析ページのパーセンテージ カウンター (レンダリングが成功すると 100% になる) が 1% のままになります。

mwrender.log を見ると、Error 32 - Pipe Broken エラーが表示されます。インターネットで検索すると、エラー 32 は、受信プロセス (パイプの後の部分) がクラッシュするか、応答しないことが原因であることがわかります。

ここから先はなかなか進みません。さらに手がかりはどこで探すべきですか? 死んだのは MySQL サーバーへの接続でしょうか?

アプライアンス全体は、ターンキー Linux Mediawiki VM で実行されます。

ピア側のソケットが閉じられたときに壊れたパイプのエラーがスローされることを知っています。

しかし、私のテストでは、ピア側が閉じているときにこちら側で即時の「送信」呼び出しを行っても、必ずしもパイプの破損エラーが発生するとは限らないことに気付きました。

例えば：

ピア側でソケットを閉じた後 (close を呼び出してクリーン クローズを試み、ピアを強制終了して異常なクローズを試みました)、40 バイトを送信しようとすると、パイプが壊れることはありませんが、 40000バイトを送信すると、すぐに壊れたパイプエラーが発生します。

壊れたパイプの正確な原因とその動作を予測できますか?