SIGPIPEを防ぐ（または適切に処理する）方法

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

通常、を無視SIGPIPEして、コードでエラーを直接処理します。これは、Cのシグナルハンドラーが実行できる操作に多くの制限があるためです。

これを行う最もポータブルな方法は、SIGPIPEハンドラーをに設定することSIG_IGNです。これにより、ソケットまたはパイプの書き込みによってSIGPIPE信号が発生するのを防ぎます。

SIGPIPE信号を無視するには、次のコードを使用します。

signal(SIGPIPE, SIG_IGN);

send()通話を使用している場合、別のオプションは、通話ごとに動作をオフにするMSG_NOSIGNALオプションを使用するSIGPIPEことです。すべてのオペレーティングシステムがMSG_NOSIGNALフラグをサポートしているわけではないことに注意してください。

最後に、一部のオペレーティングシステムでSO_SIGNOPIPE設定できるソケットフラグを検討することもできsetsockopt()ます。これSIGPIPEにより、設定されているソケットへの書き込みだけが原因で発生するのを防ぎます。

もう1つの方法は、ソケットを変更して、write（）でSIGPIPEを生成しないようにすることです。これは、SIGPIPEのグローバルシグナルハンドラーが不要なライブラリではより便利です。

ほとんどのBSDベースの（MacOS、FreeBSD ...）システム（C / C ++を使用している場合）では、次の方法でこれを行うことができます。

int set = 1;
setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int));

これにより、SIGPIPEシグナルが生成される代わりに、EPIPEが返されます。

私はパーティーに遅刻しましたSO_NOSIGPIPEが、移植性がなく、システムで動作しない可能性があります（BSDのようです）。

Linuxシステムを使用していない場合の良い代替策は、send（2）呼び出しにフラグSO_NOSIGPIPEを設定することMSG_NOSIGNALです。

例置き換えるwrite(...)ことにより、send(...,MSG_NOSIGNAL)（参照nobarのコメント）

char buf[888];
//write( sockfd, buf, sizeof(buf) );
send(    sockfd, buf, sizeof(buf), MSG_NOSIGNAL );

この投稿では、SO_NOSIGPIPEもMSG_NOSIGNALも使用できない場合のSolarisの解決策について説明しました。

代わりに、ライブラリコードを実行する現在のスレッドでSIGPIPEを一時的に抑制する必要があります。これを行う方法は次のとおりです。SIGPIPEを抑制するには、まず保留されているかどうかを確認します。存在する場合、これはこのスレッドでブロックされていることを意味し、何もする必要はありません。ライブラリが追加のSIGPIPEを生成する場合、保留中のSIGPIPEとマージされますが、これは何もしません。SIGPIPEが保留されていない場合は、このスレッドでブロックし、すでにブロックされているかどうかも確認します。その後、書き込みを自由に実行できます。SIGPIPEを元の状態に復元する場合、次のことを行います。SIGPIPEが最初に保留されていた場合は、何もしません。それ以外の場合は、現在保留中であるかどうかを確認します。発生した場合（つまり、outアクションが1つ以上のSIGPIPEを生成したことを意味します）、このスレッドで待機します。したがって、保留ステータスをクリアします（これを行うには、タイムアウトをゼロにしてsigtimedwait（）を使用します。これは、悪意のあるユーザーがSIGPIPEをプロセス全体に手動で送信したシナリオでブロックを回避するためです。この場合、保留中と表示されますが、他のスレッドが変更を待つ前にそれを処理してください）。保留状態をクリアした後、このスレッドでSIGPIPEのブロックを解除しますが、元々ブロックされていなかった場合のみです。

https://github.com/kroki/XProbes/blob/1447f3d93b6dbf273919af15e59f35cca58fcc23/src/libxprobes.c#L156のコード例

SIGPIPEをローカルで処理する

ローカルで何が起こっているのか、どのように対処するのかについてより多くのコンテキストがあるため、グローバルシグナルイベントハンドラーではなくローカルでエラーを処理するのが通常最善です。

アプリの1つに通信レイヤーがあり、アプリが外部アクセサリと通信できるようにしています。書き込みエラーが発生すると、通信レイヤーで例外をスローし、それをバブルアップさせてtry catchブロックで処理し、そこで処理します。

コード：

ローカルで処理できるようにSIGPIPE信号を無視するコードは次のとおりです。

// We expect write failures to occur but we want to handle them where 
// the error occurs rather than in a SIGPIPE handler.
signal(SIGPIPE, SIG_IGN);

このコードはSIGPIPEシグナルが発生するのを防ぎますが、ソケットを使用しようとすると読み取り/書き込みエラーが発生するので、それを確認する必要があります。

パイプの遠端のプロセスが終了するのを防ぐことはできません。書き込みが完了する前に終了すると、SIGPIPEシグナルを受け取ります。シグナルをSIG_IGNした場合、書き込みはエラーで返されます。そのエラーに注意して対処する必要があります。ハンドラーでシグナルをキャッチして無視するのは良い考えではありません-パイプが機能しなくなったことに注意し、プログラムの動作を変更して再度パイプに書き込まないようにする必要があります（シグナルが再度生成されて無視されるため）繰り返しますが、もう一度やり直すと、プロセス全体が長時間続き、CPUパワーが大量に消費される可能性があります）。

または、ハンドラーでSIGPIPEをキャッチして無視する必要がありますか？

私はそれが正しいと信じています。相手側が記述子を閉じたときを知りたい場合、それがSIGPIPEによって通知されます。

サム

Linuxマニュアルによると：

EPIPE接続指向のソケットでローカルエンドがシャットダウンされました。この場合、MSG_NOSIGNALが設定されていない限り、プロセスはSIGPIPEも受け取ります。

しかし、Ubuntu 12.04の場合は正しくありません。私はそのケースのテストを作成し、私は常にSIGPIPEなしでEPIPEを受け取ります。2回目に同じ壊れたソケットに書き込もうとすると、SIGPIPEが生成されます。したがって、この信号が発生した場合にSIGPIPEを無視する必要はありません。これは、プログラムの論理エラーを意味します。

ここでクラッシュを防ぐためのベストプラクティスは何ですか？

みんなのようにシグパイプを無効にするか、エラーをキャッチして無視してください。

行の反対側がまだ読んでいるかどうかを確認する方法はありますか？

はい、select（）を使用してください。

select（）は、ソケットが書き込み可能であると常に表示するため、ここでは機能しないようです。

読み取りビットを選択する必要があります。おそらく書き込みビットは無視できます。

遠端がファイルハンドルを閉じると、selectは読み取り可能なデータがあることを通知します。行ってそれを読むと、0バイトが返されます。これは、ファイルハンドルが閉じられたことをOSが通知する方法です。

書き込みビットを無視できないのは、大量のボリュームを送信している場合で、もう一方の端がバックログされ、バッファがいっぱいになる可能性があります。その場合、ファイルハンドルに書き込もうとすると、プログラム/スレッドがブロックまたは失敗する可能性があります。書き込み前にselectをテストすると、それから保護されますが、反対側が正常であること、またはデータが到着することを保証するものではありません。

書き込むときと同様に、close（）からsigpipeを取得できることに注意してください。

Closeは、バッファリングされたデータをすべてフラッシュします。もう一方の端がすでに閉じられている場合は、閉じることができず、シグパイプが表示されます。

バッファー付きTCPIPを使用している場合、書き込みが成功したということは、データが送信するためにキューに入れられたことを意味するだけであり、送信されたことを意味するわけではありません。closeの呼び出しが成功するまで、データが送信されたことはわかりません。

Sigpipeは、問題が発生したことを通知しますが、何をすべきか、何をすべきかについては通知しません。

最新のPOSIXシステム（Linuxなど）では、sigprocmask()関数を使用できます。

#include <signal.h>

void block_signal(int signal_to_block /* i.e. SIGPIPE */ )
{
    sigset_t set;
    sigset_t old_state;

    // get the current state
    //
    sigprocmask(SIG_BLOCK, NULL, &old_state);

    // add signal_to_block to that existing state
    //
    set = old_state;
    sigaddset(&set, signal_to_block);

    // block that signal also
    //
    sigprocmask(SIG_BLOCK, &set, NULL);

    // ... deal with old_state if required ...
}

以前の状態を後で復元したい場合は、old_state安全な場所に保存してください。その関数を複数回呼び出す場合は、スタックを使用するか、最初または最後のみを保存するかold_state、特定のブロックされた信号を削除する関数を使用する必要があります。

詳細については、manページを参照してください。