9

まず、過去にここで同様の質問があったことを知っています。

しかし、その質問には適切に答えられませんでした。代わりに、シグナルをキャッチするために何をすべきかの提案に転用されました。

明確にするために、シグナルを処理するために必要なことは何でもしました。パイプを介してメイン プロセスを監視するデーモンをフォークするアプリケーションがあります。メイン プロセスがクラッシュした場合 (セグメンテーション フォールトなど)、必要なすべての情報をパイプに書き込んで中止するシグナル ハンドラがあります。

目標は、アプリケーションに何か悪いことが起こったときに、SIGHUP、SIGUSR1 などの「通常の」操作を台無しにすることなく、できるだけ多くの情報を取得することです。

私の質問は次のとおりです。どのシグナルをキャッチする必要がありますか? 私がそれらをキャッチしなければ、とにかくアプリケーションが中止されるというシグナルを意味します。

これまでのところ、次のリストを作成しました。

  • SIGINT (^C、ユーザーが開始しますが、知っておくと便利です)
  • SIGTERM (kill <pid>シェルから、または知る限り、OutOfMemory の結果である可能性があります)
  • シグセグ
  • シジル
  • シグペ
  • シグバス
  • シグイット

私が何かを見逃しているかどうか誰かが知っていますか? kill -lそれらの多くを持っています... :)

4

3 に答える 3

9

UNIX 環境 (Stevens) の高度なプログラミングのコピーを見ています。シグナルに関するセクションの表によると、次の POSIX シグナルは、キャッチしない場合、デフォルトでプロセスを終了します。使用していないこれらすべてを監視することは不合理ではありません。

  • SIGABRT
  • SIGALRM
  • シグペ
  • サイハイアップ
  • シジル
  • シギント
  • シグキル
  • シグパイプ
  • シグイット
  • シグセグ
  • SIGTERM
  • SIGUSR1
  • SIGUSR2

SIGKILL を除くこれらすべてをキャッチできますが、SIGKILL があまり頻繁に表示されないことを願っています。

シグナルのマニュアル ページ ( man 7 signal) には、システムの適切なリストが記載されていることに注意してください。これは POSIX リストであり、アーキテクチャによって異なる場合があります。

于 2012-11-04T14:06:37.103 に答える
5

シグナルをキャッチしてコードをパイプに書き込むべきではありません。これは不要であり、フェイルセーフではありません。

フェイルセーフではない理由を指摘するために、リンク先の質問からの回答を引用させてください。

今、あなたはそれをより良くする方法と、なぜ「不要」だと私が言ったのか疑問に思っているかもしれません.

waitpidsyscallの戻りコードはWIFSIGNALED()、プロセスが正常に終了したかシグナルによって終了したかを確認するために使用できWTERMSIG()、シグナル番号を返します。

これはフェールセーフであり、ハンドラやパイプは必要ありません。さらに、プロセスを終了するすべてのシグナルを報告するため、何をキャッチするかを心配する必要はありません。

于 2012-11-04T13:59:23.423 に答える
1

それは依存します: 何か悪いことが起こったことをユーザーに知らせるのに役立つ場合は、好きなシグナルです。ただし、SIGKILL と SIGSTOP はキャッチできません。

于 2012-11-04T13:49:49.277 に答える