SIGKILL init process（PID 1）

Question

私はシグナル9（SIGKILL）をinitプロセス（PID 1）に送信することに関して奇妙な問題に直面しています。 シグナルハンドラを介してSIGKILLを無視することはできません。 SIGKILLをinitに送信しようとすると、何も起こっていないことに気付きました。 initは終了しません。この振る舞いを理解しようとすると、私はstraceを使ってinitプロセスに自分自身を取り付けることを決めました。今、奇妙な部分が来る。 straceでinitプロセスを "見て" SIGKILLを送ると、システムがクラッシュします。

私の質問はなぜこれが起こっているのですか？プロセスを見るとシステムがクラッシュするのはなぜですか、そうでないとクラッシュしないのはなぜですか？私が言ったように、どちらの場合も、私はSIGKILLをinitに送ります。 CentOS 6.5、Debian 7、Archでテスト済み。

ありがとうございます！

Answer 1

initが終了すると、Linuxカーネルが故意に強制的にシステムクラッシュを起こします（http://lxr.free-electrons.com/source/kernel/exit.c?v=3.12#L501、特にpanicのコールを参照）。そのため、安全装置として、カーネルはinitに任意の致命的なシグナルを配信しません、とSIGKILLが除外されていません（私はよく分からないが、コードの流れを畳み込む十分に（http://lxr.free-electrons.com/ident?v=3.12&i=SIGNAL_UNKILLABLEを参照）が、私容疑者カーネルによって生成されたSIGSEGVまたはそれに類するものが通過する）。

処理1に対してptrace(2)（straceが使用するシステムコール）を適用すると、明らかにこの保護が無効になります。これはカーネルのバグだと言えます。私は、このバグを見つけるためにコードを掘り下げるのに不十分な熟練しか持っていません。

他のUnixの亜種が同じ終了時のクラッシュ・セマンティクスまたは信号保護をinitに適用するかどうかわかりません。 が終了する場合（少なくともそれがそうであれば、_exitを呼び出すことによって）OSがパニックではなくクリーンなシャットダウンまたはリブートを実行するのは合理的ですが、私の知る限り、すべての最新のUnixの亜種には専用のシステムがあります代わりにこれを要求するための呼び出し（reboot(2)）。