Dockerコンテナが起動しない・すぐ停止する原因と確認手順
Exited・Restartingなど、Dockerコンテナが期待どおり動かない場合の障害調査です。原因が分からないうちにrestartやrmを繰り返さないことを優先します。
この記事の目的
Docker daemonへの接続障害と、コンテナ内アプリの終了を分け、ログ・終了コード・設定を順番に調べます。
最初にやること
docker context show→docker ps -a→docker logs→docker inspectで状況を記録します。
docker rm -fやdocker compose down -vを初手で実行しないでください。web01などのコンテナ名、Composeサービス名・ポートは例です。Docker context・ホスト・保存先を実環境で確認してください。関連するガイド
Dockerの基本操作ガイド
コンテナの状態確認、起動・停止、接続先の基本操作へ戻ります。
記事を読む →DockerDocker Compose設定と安全な反映
対象と原因を絞り、変更前後の確認手順へ進みます。
記事を読む →DockerDockerログ確認・容量対策
docker logsとログドライバー、保存容量の設計を確認します。
記事を読む →1. 最初に確認する4コマンド
コマンドに指定するコンテナ名は、docker ps -aで確認したものに置き換えます。docker inspectの全出力はSecretsや環境変数を含む場合があります。
2. ExitedとRestartingを分ける
| 結果 | 確認すること |
|---|---|
| Exited (0) | 常駐サービスではなく正常に終了する一時ジョブか確認 |
| Exited (1)等 | アプリログ、起動引数、設定、環境変数を確認 |
| Exited (137) | SIGKILL・OOMKilledの真偽・ホスト側イベントを確認。137だけでOOMと断定しない |
| Restarting | restart policy、終了コード、前回ログを確認 |
| daemon接続エラー | Docker context、daemon、ソケット権限、接続環境を確認 |
3. 終了理由とアプリHealthを分ける
| 結果 | 判断・次の調査 |
|---|---|
| ExitCode 0でExited | 正常終了型ジョブか常駐サービスかを確認。常駐想定ならCMD・ENTRYPOINT・アプリログを調査 |
| ExitCode 137 | SIGKILLによる終了の可能性。OOMKilled、ホストメモリ、管理者操作・終了猶予を照合し、137だけでOOMと断定しない |
| runningでunhealthy | プロセスは生存。Healthcheckの実行結果とアプリ依存先を確認して原因を切り分ける |
| healthcheck-not-configured | 正常・異常は未判定。業務エンドポイントやアプリログなど別の確認方法を使う |
繰り返し再起動する前に証跡を確保し、設定変更後は起動状態だけでなく業務機能が復旧したことを確認してください。
4. OOMとホストのリソース不足
OOMKilledがtrueであればメモリ不足で強制終了した重要な根拠です。メモリ上限・ホストメモリ・コンテナの起動プロセスを合わせて判断します。
Linuxのメモリ不足・高負荷ガイドでホスト側の調査もできます。
5. ポート・マウント・権限
address already in useはホスト側のポート競合、permission deniedは実行ユーザー・ファイル権限・SELinux等の問題が考えられます。
--privilegedや無制限のchmodを、原因不明の権限エラーの暫定対処に使わないでください。6. Docker Composeで起動しない
Composeファイル、環境変数、実行プロジェクト、アプリのログを照合します。詳しい設定検証はCompose設定と安全な反映ガイドを参照してください。
7. 復旧時の注意と再確認
修正したら、docker ps -aの稼働状態だけでなく、アプリ応答、ログ、restart回数、保存データを確認してから完了とします。
関連する確認手順：ポートが既に使われている場合。
関連する確認手順：Docker daemonへ接続できない場合。
8. 終了コード・状態別の対処方針
終了コード単独では根本原因を断定できません。まずDocker context、終了理由、直前ログ、RestartPolicyを照合します。以下の出力例は説明用の想定例で、実機実測ではありません。
| 観測結果 | 原因を絞るための確認 | 次に取る行動 |
|---|---|---|
Exited (0) | 一時ジョブなら正常終了か、常駐サービスのはずなのか | 一時ジョブなら正常。常駐サービスならENTRYPOINT/CMD・起動設計を確認し、管理元の定義を修正 |
Exited (1)等 | 直前ログの設定ファイル、環境変数、パス、権限エラー | 表示された原因だけを管理元で修正し、Compose設定検証を実施 |
137 ＋ OOMKilled=true | ホストのOOM記録、メモリlimits・使用推移 | 制限不足か異常なメモリ増加かを区別。必要な容量計画やアプリ修正を判断し、無条件に制限を撤廃しない |
137 ＋ OOMKilled=false | SIGKILL、daemon再起動、ホスト操作履歴 | 終了時刻とjournalを照合。OOMと決めつけてメモリ設定を変更しない |
Restarting | 再起動ポリシー、終了ログ、設定変更履歴 | 繰り返し終了する原因を修正。ポリシーを外して症状を隠さない |
Createdで起動不能 | ポート競合、mountエラー、daemonの状態 | ポート競合やdaemon接続へ原因別に分岐 |
9. 設定修正から復旧判定まで
出力例（想定・実測ではありません）：
この場合はアプリの期待パスと、Composeのbind mountやVolume設定を照合します。ファイルを無条件で新規作成したり、コンテナをprivilegedにしたりせず、管理元で正しいパス・権限を修正してください。
docker compose up -dは再作成が起こり得るため、承認後にのみ反映します。切り戻しは元の設定とイメージを管理元から再適用し、データ互換性を別途検証します。| 変更後の結果 | 完了・未解決の判断 |
|---|---|
| runningを維持し、ログとアプリの実接続が正常 | 復旧候補。業務機能・依存先・監視も確認して完了 |
| RestartCountが継続して増加 | 未解決。前回ログと変更差分へ戻り、原因を再調査 |
| runningだが接続できない | アプリlisten・公開ポート・依存先を確認。docker psだけで完了にしない |
| 原因を特定できない | 終了コード・ログ・ホスト時刻・直近変更を記録してアプリ担当へ連携 |