docker stop と docker kill の違いを解説【安全な停止 vs 強制終了】

コンテナを止めるコマンド、2つあるけどどっちを使う？

Dockerでコンテナを停止するとき、docker stop と docker kill の2つのコマンドが用意されています。どちらもコンテナを止めるコマンドですが、「どちらを使えばいいの？」「違いは何？」と迷ったことはありませんか。

この記事では、両コマンドの仕組みの違いを比較表やシグナルの解説を交えてわかりやすく説明します。適切に使い分けて、データ損失やトラブルを防ぎましょう。

結論：通常は docker stop。docker kill は最終手段

まず結論からお伝えします。

• 通常のコンテナ停止 → docker stop を使う
• docker stop で止まらない場合 → docker kill を使う

docker stop はプロセスに「終了してください」と丁寧にお願いするコマンドです。一方、docker kill はOSが強制的にプロセスを終了させるコマンドです。日常的なコンテナ操作では、まず docker stop を使うのが正しい選択です。

docker stop と docker kill の比較表

このように、docker stop はプロセスに終了処理の猶予を与え、docker kill は問答無用で即座に終了させるという大きな違いがあります。

docker stop の仕組み

SIGTERM → 待機 → SIGKILL の流れ

docker stop は、以下の2段階でコンテナを停止します。

1. コンテナのメインプロセスに SIGTERM（シグナル番号15）を送信する
2. デフォルトで 10秒間 プロセスの終了を待つ
3. 10秒経っても終了しない場合、SIGKILL（シグナル番号9）を送信して強制終了する

つまり、docker stop はまず「丁寧にお願い」し、それでもダメなら「強制終了」するという仕組みです。

# コンテナを通常停止（10秒の猶予あり）
docker stop my-container

# 猶予時間を30秒に変更
docker stop --time=30 my-container

# 猶予時間を短く（5秒）
docker stop -t 5 my-container

–time / -t オプション

--time（短縮形 -t）オプションを使うと、SIGTERMを送信してからSIGKILLを送るまでの待機時間を変更できます。データベースなど終了処理に時間がかかるコンテナでは、猶予時間を長めに設定するのが安全です。

💡 補足
Webサーバーやデータベースのように、接続中のリクエストの処理完了やデータの書き込みが必要なアプリケーションでは、SIGTERMを受け取ってから安全に終了するための処理（グレースフルシャットダウン）が実装されています。docker stop はこの仕組みを活かすことができます。

docker kill の仕組み

SIGKILL を即座に送信

docker kill は、デフォルトでコンテナのメインプロセスに SIGKILL（シグナル番号9）を即座に送信します。猶予時間はありません。プロセスは終了処理を行う暇もなく、OSカーネルによって強制終了されます。

# コンテナを強制終了
docker kill my-container

–signal オプションで任意のシグナルを送信

docker kill には --signal オプションがあり、SIGKILL以外のシグナルを送信することもできます。

# SIGHUPを送信（設定ファイルのリロードなどに使う）
docker kill --signal=SIGHUP my-container

# SIGTERMを送信（docker stopと同じシグナル）
docker kill --signal=SIGTERM my-container

💡 補足
--signal オプションを使えば、コンテナを停止せずにシグナルを送ることもできます。例えば、Nginxコンテナに SIGHUP を送ると、プロセスを再起動せずに設定ファイルをリロードさせることが可能です。

SIGTERM と SIGKILL の違い

両コマンドの違いを理解するためには、Linuxのシグナルの仕組みを知っておくことが大切です。

SIGTERM はプロセスに「終了してください」という通知です。プロセスはこのシグナルを受け取ると、ファイルへのデータ書き込みや接続のクローズなどの終了処理を行ってから安全に終了できます。ただし、プロセス側でSIGTERMを無視するように実装されている場合は、送信しても終了しません。

SIGKILL はプロセスではなく、OSカーネルが直接プロセスを終了させます。プロセスがキャッチ（捕捉）したり無視したりすることは不可能で、終了処理を行う余地はありません。

いつ docker kill を使うべきか

基本的には docker stop を使い、docker kill は以下のケースでのみ使いましょう。

• docker stop を実行してもコンテナが停止しない（フリーズしている）
• プロセスがSIGTERMを無視する実装になっている
• 開発中で、データ損失を気にせずに素早くコンテナを止めたい

⚠️ 注意
本番環境のデータベースコンテナに docker kill を使うのは避けてください。書き込み中のデータが破損するリスクがあります。必ず docker stop で停止し、猶予時間が足りない場合は -t オプションで延長しましょう。

終了コードの違い

コンテナの停止方法によって、終了コード（Exit Code）が異なります。docker ps -a で確認できます。

# docker stop で停止した場合
$ docker ps -a
CONTAINER ID   IMAGE    STATUS                     
abc123         nginx    Exited (0) 5 seconds ago    

# docker kill で停止した場合
$ docker ps -a
CONTAINER ID   IMAGE    STATUS                      
def456         nginx    Exited (137) 3 seconds ago

• Exited (0)：正常終了。プロセスが終了処理を完了して自ら終了した
• Exited (137)：SIGKILLによる強制終了。137 = 128 + 9（シグナル番号）

コンテナが Exited (137) で終了している場合は、SIGKILLで強制終了されたことを意味します。意図しない137終了が頻発する場合は、docker stop の猶予時間が短すぎるか、アプリケーションの終了処理に問題がある可能性を疑いましょう。コンテナの終了コードについて詳しくは「コンテナがすぐ終了する（Exited）」の記事も参考にしてください。

まとめ

この記事では、docker stop と docker kill の違いを解説しました。

• docker stop は SIGTERM → 10秒待機 → SIGKILL の2段階で安全に停止する
• docker kill は SIGKILL を即座に送信して強制終了する
• 通常は docker stop を使い、docker kill はフリーズ時の最終手段として使う
• 終了コードは正常終了が 0、SIGKILL による強制終了が 137

コンテナの停止はコンテナのライフサイクルの重要なステップです。両コマンドの違いを正しく理解して、安全なコンテナ運用を実践しましょう。その他のDockerコマンドについては「Docker主要コマンド一覧」もあわせてご確認ください。

Dockerの基礎を動画で体系的に学びませんか？

実務で使う基礎だけを3時間に凝縮。環境構築から丁寧に解説しています。

クーポン割引で講座を見る →