シグナル ハンドラがない場合、SIGTERM は SIGKILL と同じように動作しますか?

シグナル ハンドラがない場合、SIGTERM は SIGKILL と同じように動作しますか?

SIGTERMとSIGKILLのほとんどの説明では、SIGKILLは

SIGTERM や SIGINT とは対照的に、[...] をキャッチしたり無視したりすることはできません [...] (ウィキペディア

SIGTERM と SIGKILL の違いはこれだけでしょうか? 特に、プロセスが SIGTERM ハンドラーをインストールしていない場合、プロセスに SIGTERM を送信するか SIGKILL を送信するかで何か違いがあるのでしょうか?

答え1

シグナル設定がない場合、SIGTERMおよびは、SIGKILL少なくとも強制終了されたプロセスの観点からは、およびを含む、デフォルトでプロセスを終了する他のシグナルと同様に、実質的に同等SIGUSR1ですSIGUSR2イルカチュ指摘されているように、親プロセスは子プロセスを終了させたシグナルを通知されます(これにより、シェルはシグナルを区別し、例えば「終了」と「ユーザー定義シグナル 1」)。

Wikipedia で述べられているように、SIGKILLキャッチしたり無視したりすることはできませんがSIGTERM、これはプロセスが無効にするためにハンドラをインストールする必要がなくSIGTERM、単にブロックしたり無視したりできることを意味します (sighold()sigrelse()そしてsigignore())。

POSIXの詳細なセクションとして信号処理の根拠. Linuxのsignal(7)マンページにもシグナルの詳細が記載されています。

答え2

SIGTERM と SIGKILL の唯一の違いはこれだけですか?

いいえ。

SIGKILLとキャッチされていないものの大きな違いSIGTERMは、前者は起きろ停止したプロセス(すぐに自身を破壊できる)に対して、後者は の後にのみ効果を発揮しますSIGCONT

簡単な例:

$ sleep 1000 & sleep 1; kill -TSTP $!
[1] 6455

[1]+  Stopped                 sleep 1000
$ kill -TERM 6455
$ jobs
[1]+  Stopped                 sleep 1000
$ kill -CONT 6455
$ jobs
[1]+  Terminated              sleep 1000

TERM、、などHUPINTシグナルが確実に効果を発揮するようにしたい場合は、CONTシグナルとペアにする必要があります (順序は任意)。

bashの組み込み関数の魔法のため、人々はそれをすぐには理解できないかもしれない。停止したkillジョブを参照するジョブID(またはpidの否定)と一緒に使用する%%1仕事、 それはそれを全て自分で行う舞台裏:

/* Give PID SIGNAL.  This determines what job the pid belongs to (if any).
   If PID does belong to a job, and the job is stopped, then CONTinue the
   job after giving it SIGNAL.  Returns -1 on failure.  If GROUP is non-null,
   then kill the process group associated with PID. */
int
kill_pid (pid, sig, group)

関連情報