Unixシグナルの仕組み ― プロセスへの「合図」を理解する

そのとおり！ シグナルはカーネルからプロセスに送られる「ソフトウェア割り込み」だよ。たとえば「そろそろ終了してね」とか「設定ファイルを読み直して」みたいな合図をプロセスに伝える仕組みだね。電話の着信音みたいなもので、プロセスは今やっている処理を一時中断してシグナルに対応するんだ。

代表的なものを紹介するね。SIGTERMは「お行儀よく終了してね」、SIGKILLは「問答無用で強制終了」、SIGINTは「ユーザーが中断を要求したよ」（Ctrl+Cで送られる）、SIGHUPは「端末が切断されたよ」、SIGUSR1とSIGUSR2は「アプリが自由に使っていい汎用シグナル」だよ。番号で言うとSIGTERMが15、SIGKILLが9、SIGINTが2だね。

まずkillコマンドやkillシステムコールで「PID○○にシグナル△△を送って」とカーネルに依頼するよ。カーネルはそのプロセスの情報に「保留シグナル」としてマークするんだ。プロセスがカーネルからユーザー空間に戻るタイミング（システムコールの戻りやタイマー割り込みの後）でシグナルが配送されて、登録されたシグナルハンドラが呼ばれるよ。

書けるよ！ CならsigactionやSignal関数、Node.jsならprocess.on('SIGTERM', ...)、Pythonならsignal.signalモジュールで登録するんだ。ハンドラを登録しなかった場合はデフォルト動作が実行される。SIGTERMやSIGINTのデフォルトは「プロセス終了」だよ。

まさにシグナルの活用例だよ。Webサーバーを例にすると、SIGTERMを受け取ったら「新しいリクエストの受付を止める → 処理中のリクエストを完了させる → DB接続をクリーンに閉じる → 終了コード0で終了」という流れだね。いきなり電源を抜くんじゃなくて、ちゃんと片付けてから退室するイメージだよ。

いいところに気づいたね。コンテナ内の最初のプロセスはPID 1になるんだけど、Linuxカーネルの仕様でPID 1はシグナルハンドラを明示的に登録していないシグナルを無視するんだ。つまりdocker stopでSIGTERMが送られても、アプリがハンドラを登録していなければ何も起きない。10秒後にSIGKILLで強制終了されてしまうよ。

tiniやdumb-initという軽量initプロセスをPID 1として起動して、アプリをその子プロセスにする方法があるよ。Docker自体にも--initオプションがあるんだ。これでシグナルが正しくアプリに転送されるようになるよ。

本当だよ。SIGKILLとSIGSTOPだけはハンドラを登録できないし、ブロックもマスクもできない。カーネルが直接プロセスを終了するからね。だからkill -9（SIGKILL）は「最後の手段」なんだ。SIGKILLだとファイルの書きかけやDB接続が中途半端な状態で残る可能性があるから、まずSIGTERMを送って、それでもダメなときだけSIGKILLを使うのがベストプラクティスだよ。

これはベテランでも踏みがちな罠だよ。シグナルハンドラ内で呼んでいいのは「async-signal-safe」な関数だけなんだ。mallocやprintfはasync-signal-safeじゃないから、ハンドラ内で呼ぶとデッドロックやメモリ破壊が起きうる。安全な方法は、ハンドラ内ではフラグ変数をセットするだけにして、メインループでそのフラグをチェックして後処理する「self-pipe trick」パターンだよ。

そうだよ。systemctl stopを実行するとsystemdはまずExecStopで指定されたコマンドを実行し、なければSIGTERMを送る。TimeoutStopSecで指定された秒数待っても終了しなければSIGKILLを送るんだ。KillSignalディレクティブでSIGTERM以外のシグナルを指定することもできるよ。たとえばnginxのようにSIGQUITでグレースフルシャットダウンするサービスでは、KillSignal=SIGQUITと設定するのが定石だね。