Linux や Unix 系 OS を扱っていると、日常的に登場する概念のひとつが「シグナル（Signal）」です。
特にサーバー運用やアプリケーション開発をしていると、SIGTERM や SIGKILL といった名前をよく目にします。
- プロセスを安全に停止したい
- コンテナを落とすときにどう扱われる？
- kill コマンドの挙動がよく分からない
こうした疑問を持った経験がある方も多いはずです。
この記事では、シグナルの中でも特に混同されやすい SIGTERM と SIGKILL の本質的な違い を、
初心者の方にも分かりやすく整理して解説していきます。
シグナルとは何か？
まず前提として、シグナル（Signal）とは OS がプロセスに送る通知や命令のことです。
プロセス（アプリケーションやサービス）に対して、
「実行を止めて」「再読み込みして」「終了しなさい」といった指示を送るための仕組みです。
Linux では、プロセス間通信（IPC：Inter-Process Communication）の一種として歴史的に利用されてきました。
例えば、以下のような場面でシグナルが利用されます。
killコマンドでプロセスを停止- Ctrl + C を押したとき
- システムシャットダウン時の通知
- コンテナの停止（Docker / Kubernetes）
- サーバー運用中の設定再読み込み
こうした操作の裏側で、OS がプロセスにシグナルを送り、適切な処理を促しています。
SIGTERM と SIGKILL はなぜ重要なのか？
シグナルは数多くありますが、その中でも SIGTERM（15番）と SIGKILL（9番） は特に重要です。
理由としては、
- プロセス終了時の正しい扱いに直結する
- コンテナ・サーバー運用で必ず扱う
- 誤解したまま運用するとデータ破損・不正終了の原因になる
といったケースが多いためです。
どちらも「プロセスを終了させる」ためのシグナルではありますが、
両者は根本的に性質が異なり、使いどころもまったく違います。
SIGTERM：プロセスに“丁寧に終わってもらう”ためのシグナル
SIGTERM（Signal Terminate） は、プロセスに対して
「できれば安全に終了処理をして、終わってください」
という 礼儀正しい終了依頼 にあたります。
特徴
- プロセスは このシグナルを受け取ってから終了処理を開始できる
- キャッシュの書き出し、接続のクローズ、ログ保存などが可能
- ハンドリング（受け取り後の処理）をプログラム側で自由に定義できる
- プロセスが無視することも technically は可能
簡易的なイメージ（擬似コード）
シグナル受信: SIGTERM
→ 現在の処理を停止
→ キャッシュやファイルを保存
→ 接続を閉じる
→ "丁寧に" 終了アプリが自分で「終わる準備」をしてから停止できるため、
安全性が高い終了方法 と言えます。
補足：kill コマンドのデフォルトは SIGTERM
kill <PID>とだけ書いた場合、実は SIGTERM が送られます。
多くの人が「kill は即終了」と思いがちですが、標準的には「丁寧な終了」です。
SIGKILL：OS が強制的にプロセスを “〇す” シグナル
SIGKILL（Signal Kill） は、文字通りプロセスを即座に強制終了させるシグナルです。
プログラム側で捕捉（ハンドリング）したり、無視したりすることは一切できません。
特徴
- OS がプロセスを「問答無用で直ちに終了」
- データ保存や後処理の機会なし
- ハンドリング不可
- プロセスがフリーズしていても確実に終了できる
簡易イメージ
シグナル受信: SIGKILL
→ （後処理なし）
→ 即終了これだけ聞くと便利に思えますが、
安全な終了処理ができないため、データ破損やファイル不整合のリスクがあります。
本質的な違い：丁寧な終了 vs 強制終了
ここまで説明した内容を踏まえて、両者の本質的な違いを整理します。
1. プログラム側でハンドリングできるか
| シグナル | ハンドリング |
|---|---|
| SIGTERM | 可能 |
| SIGKILL | 不可能 |
安全にアプリを終了させたい場合は SIGTERM が必須です。
2. データ保全処理ができるか
| シグナル | 保存・クリーンアップ処理 |
|---|---|
| SIGTERM | できる |
| SIGKILL | できない |
ログやキャッシュを書き込む必要があるアプリは SIGTERM を前提に作られています。
3. 強制終了の度合い
| シグナル | 強制度 |
|---|---|
| SIGTERM | 低い（依頼） |
| SIGKILL | 最高（強制） |
SIGKILL は最後の手段です。
4. 主な用途の違い
- SIGTERM → サーバー停止、アプリ再起動、デプロイ時の優雅な shutdown など
- SIGKILL → プロセスがハングしている、無限ループ状態、応答がないなど “緊急避難的な終了” に限定
実際の運用でありがちな誤解
ここからは、現場でよくある「誤解」について触れておきます。
どれもトラブルにつながりやすいので注意が必要です。
誤解 1：kill は即〇するコマンド
実際には kill のデフォルトは SIGTERM。
すぐ〇なない場合は、プロセスが後処理をしている可能性があります。
すぐに SIGKILL を送るとデータ破損の原因になるので注意。
誤解 2：SIGTERM を送ったらすぐ終了すべき
プロセスは、終了前にやるべき仕事があります。
- DB への書き込み待ち
- ファイル保存
- キャッシュ同期
- セッション処理
こうした処理が完了するまで、数秒〜数十秒かかることもあり得ます。
誤解 3：プロセスが落ちていれば SIGKILL でOK
SIGKILL はあくまで最終手段。
アプリやサーバー構成によっては、強制終了により状態が壊れるケースがあります。
Docker や Kubernetes では特に重要な概念
コンテナ環境では、シグナルの扱いが影響範囲を大きく左右します。
Docker
docker stop は内部で次の流れで動きます：
- SIGTERM を送る（優雅な終了を期待）
- 指定秒数（デフォルトで 10 秒）待つ
- それでも終わらなければ SIGKILL を送る
つまり、SIGTERM を正しく扱わないアプリは“強制終了される運命”になります。
Kubernetes（k8s）
Pod の停止時も同様で、
- SIGTERM → Graceful Shutdown（猶予あり）
- SIGKILL → 猶予時間を過ぎたら強制終了
という流れが基本です。
コンテナ開発者にとって、SIGTERM のハンドリングはほぼ必須スキルといえます。
シグナルを送るときの基本ルール
- まず SIGTERM を送る（丁寧に依頼する）
- 一定時間待つ
- 終わらなければ、必要に応じて SIGKILL を送る（最終手段）
現場ではこの流れを徹底するだけでも、
トラブルが劇的に減ることがあります。
一問一答（簡単まとめ）
- SIGTERM と SIGKILL の違いは？
-
SIGTERM は「丁寧な終了依頼」、SIGKILL は「即座の強制終了」。
- まずどちらを使うべき？
-
SIGTERM（安全に終わらせるため）。
- SIGKILL はいつ使う？
-
プロセスが完全にハングしているなど、緊急時のみ。
- コンテナではなぜ重要？
-
stop 時に SIGTERM → SIGKILL の順で送られるため、正しく扱わないとまともに終了できない。
まとめ：SIGTERM と SIGKILL の違いを理解することは安全な運用につながる
SIGTERM と SIGKILL はどちらも「プロセス終了のためのシグナル」ですが、
その性質や影響はまったく異なります。
- SIGTERM は安全な終了処理ができる（優雅な終了）
- SIGKILL は手加減なしの強制終了（最終手段）
- 運用では必ず SIGTERM →（必要があれば）SIGKILL の順で扱う
- コンテナ時代のアプリは SIGTERM 対応が必須
この違いを理解することで、サーバー運用やアプリ開発の品質は確実に高まります。
特にコンテナ・クラウドが当たり前になった現在、
SIGTERM の正しい扱いは避けて通れない基本スキルです。
