SIGINTは、SIGTERM、SIGQUIT、SIGKILLなどの他の終了信号とどのように関連していますか?
POSIXシステムでは、終了信号は通常次の順序になります(多くのMANページとPOSIX仕様による)。 SIGTERM-プロセスに終了を丁寧に要求します。正常に終了し、すべてのリソース(ファイル、ソケット、子プロセスなど)をクリーンアップし、一時ファイルを削除します。 SIGQUIT-より強力なリクエスト。クリーンアップが絶対に必要なリソースをクリーンアップしますが、一時ファイルは削除せず、デバッグ情報をどこかに書き込む可能性があります。一部のシステムでは、コアダンプが書き込まれます(信号がアプリによってキャッチされるかどうかに関係なく)。 SIGKILL-最も強力なリクエスト。プロセスは何もするように要求されることさえありませんが、システムはそれが好きかどうかに関わらず、プロセスをクリーンアップします。おそらくコアダンプが書き込まれます。 SIGINTはどのようにその画像に適合しますか?CLIプロセスは通常、ユーザーがCRTL + Cを押すとSIGINTによって終了しますが、バックグラウンドプロセスは、KILLユーティリティを使用してSIGINTによって終了することもできます。仕様またはヘッダーファイルで確認できないのは、SIGINTがSIGTERMよりも強いか弱いか、またはSIGINTとSIGTERMの間にまったく違いがあるかどうかです。 更新: 私がこれまでに見つけた終了信号の最も良い説明は、GNU LibC Documentationにあります。これは、SIGTERMとSIGQUITの間に意図された違いがあることを非常によく説明しています。 それはSIGTERMについて言います: これは、プログラムに終了を丁寧に要求する通常の方法です。 そしてそれはSIGQUITについて述べています: [...]プログラムエラー信号のように、プロセスを終了するとコアダンプを生成します。これは、ユーザーによって「検出」されたプログラムエラー状態と考えることができます。[...]特定の種類のクリーンアップは、SIGQUITの処理では省略されるのが最適です。たとえば、プログラムが一時ファイルを作成する場合、一時ファイルを削除することにより、他の終了要求を処理する必要があります。ただし、SIGQUITはそれらを削除しない方がよいため、ユーザーはコアダンプと組み合わせてそれらを調べることができます。 そしてSIGHUPも十分に説明されています。SIGHUPは実際には終了信号ではなく、単にユーザーへの「接続」が失われたことを意味するため、アプリはユーザーがそれ以上の出力(例:stdout / stderr出力)を読み取ることを期待できず、期待される入力がありません。もはやユーザー。ほとんどのアプリでは、終了することを意味します。理論的には、SIGHUPを受信すると、アプリがデーモンモードになり、バックグラウンドプロセスとして実行され、設定されたログファイルに出力が書き込まれるようにアプリを決定することもできます。すでにバックグラウンドで実行されているほとんどのデーモンの場合、SIGHUPは通常、構成ファイルを再検査する必要があることを意味するため、構成ファイルを編集した後、デーモンをバックグラウンドプロセスに送信します。 ただし、このページには、CRTL + Cから送信されるSIGINTに関する有用な説明はありません。SIGINTをSIGTERMとは異なる方法で処理する理由はありますか?もしそうなら、これはどのような理由であり、処理はどのように異なるのでしょうか?