Unixシグナルの仕組み — 「終わってね」の合図と後片付け

ひよこ

Ctrl+Cを押すと、アプリが止まるのはどうして？

ペンギン先生

Unixの端末では、通常SIGINTという中断の合図が前景のプロセスグループへ送られるよ。シグナルはプロセスやスレッドへ届く通知で、何をするかは種類と設定で変わるんだ。

ひよこ

合図が来たら、必ず自分で後片付けする？

ペンギン先生

何もしない場合の既定動作があるよ。SIGTERMは通常終了するけれど、後片付けの手順が自動で書かれるわけではない。アプリが終了処理を用意するんだ。

ひよこ

SIGTERMとSIGKILLは、どちらも終了なら同じ？

ペンギン先生

SIGTERMはハンドラで対応できる。SIGKILLは捕捉も無視もブロックもできず、その後のアプリ自身の後片付けは頼めないよ。終了を待つ時間も合わせて考えるんだ。

ひよこ

合図の番号を覚えれば、どのOSでも使える？

ペンギン先生

番号は環境によって異なるものがあるから、名前と意味を中心に覚えよう。Windowsのプロセス停止をUnixのシグナルと同じ操作だと考えないことも大切だよ。

ひよこ

Pythonでも、合図を受け取れる？

ペンギン先生

signal.signalで処理を登録できるよ。下では自分のプロセスへSIGINTを送り、フラグを立ててから通常の処理で片付ける。Pythonのハンドラは通常メインスレッドで実行されるんだ。

ひよこ

Cでも、ハンドラで何でも呼んでいいの？

ペンギン先生

違うよ。低水準の非同期ハンドラではasync-signal-safeな操作に制限される。PythonやNode.jsの実行モデルと混ぜない。フラグだけ立てる方法と、パイプで通知するself-pipeも別の工夫だね。

ひよこ

Dockerのstopなら、必ず10秒で片付ける？

ペンギン先生

最初の合図や待ち時間は設定で変わるよ。Linuxコンテナの既定は一般に10秒、Windowsは30秒。シェルがアプリへ合図を渡さない問題やPID 1の特別な扱いも確認するんだ。

ひよこ

安全に終了するには、何から考える？

ペンギン先生

新しい受付を止め、処理中の仕事をどう終えるか決め、必要な保存や接続終了をして期限内に終わる流れを用意する。同じ終了要求が重なっても困らないこと、途中で止まっても復旧できることを試そう。

まずは、自分へ合図を送ってみる

Python 3が使えるなら、signal-demo.pyへ保存し、python signal-demo.pyで試します。他のプロセスへ停止命令を送る実験ではありません。

import signal

stopping = False

def request_stop(signum, frame):
    global stopping
    stopping = True

signal.signal(signal.SIGINT, request_stop)
print("作業を開始")
signal.raise_signal(signal.SIGINT)
if stopping:
    print("合図を受けて、片付け")
print("終了")

作業を開始
合図を受けて、片付け
終了

ハンドラではフラグを変え、普通の処理で表示します。これは短い仕組みの練習で、実際のサーバーが処理中の要求を待つ実装は別に必要です。Pythonのハンドラは、低水準のCハンドラ内でそのまま実行されず、通常メインスレッドで後から実行されます。

3つの合図を分ける

SIGHUPを設定再読込に使うのは、そのアプリがそう実装した場合です。合図の名前だけで設定ファイルが自動的に読み直されるわけではありません。また、標準シグナルは、保留中に同じ種類を何回送っても、その回数すべてがキューに残るとは限りません。

終了処理は、アプリが用意する

Webサーバーなら、新規受付を止め、処理中の要求の完了や打ち切りを決め、保存や接続終了を行います。外部の停止期限より長く待ち続けると、後片付けの途中で強制終了されることもあります。SIGKILLで止まっても、他のプロセスやDBが状態を持ち続ける場合を考え、再開や再試行を設計します。

Cの非同期ハンドラでは、printfやmalloc等を自由に呼べません。volatile sig_atomic_tのフラグを変える工夫と、パイプ等で通常のイベントループへ知らせるself-pipeは区別しましょう。Python・Node.js等ではランタイムのハンドラ実行条件を読みます。

もう少し詳しく：コンテナの停止

Docker stopの最初のシグナルはSTOPSIGNAL等で変わり、待ち時間も変更できます。明示されないときの既定はLinuxコンテナで10秒、Windowsコンテナで30秒です。全コンテナへ固定した10秒を当てはめません。

LinuxのPID 1には特別なシグナルの扱いがあります。シェルを入口にして子のアプリへ合図が伝わらないこともあるため、exec形式で起動する方法や--init等を検討します。initを入れたら後片付けが自動で完成するわけではなく、アプリ側の終了手順も必要です。

🐧 ペンギン先生のまとめ：「シグナル」って出てきたら「動いているプログラムへ送る、短い合図」と思えばだいたいOK！

プログラムの実行単位はOSの仕組み、コンテナの起動はDocker入門で学べます。

参考資料

• Linux man-pages：signal(7) — 既定動作・SIGKILL・配送と保留
• Python：signal — raise_signal・メインスレッド・実行モデルとWindows
• Linux man-pages：signal-safety(7) — Cの非同期ハンドラの安全な操作
• Docker：container stop — 停止シグナルと待ち時間の条件
• Docker：Dockerfile ENTRYPOINT — シェル形式とexec・PID 1への伝達