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
、、などHUP
のINT
シグナルが確実に効果を発揮するようにしたい場合は、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)