Docker コンテナが起動直後に終了する？完全トラブルシュート（Exit Code 137/1 対応）

退勤しようとした瞬間、スマートフォンが震えました——本番環境のアラートです。開くと、4 つのコアサービスのコンテナがすべて Exited 状態。ターミナルで docker ps を叩いても、真っ白。何も表示されない。

冷蔵庫を開けて飲み物を取ろうとしたら、中身が空っぽだった——そんな感覚でした。正直、最初に頭をよぎったのは「週末が終わった」という絶望でした。でも落ち着いて考えると、コンテナの起動失敗は初めてではありません。今回は突然で、影響が大きかっただけです。

2 時間以上かけて調べた結果、原因は意外と単純でした。あるサービスの設定ファイルパスが誤っていて、依存 DB に接続できず、起動直後に終了していました。体系的な調査フローがあれば、10 分程度で済んだかもしれません。

この記事は、数え切れないほど踏んだ坑からまとめた、コンテナ起動失敗のトラブルシュートガイドです。Exit Code 1 でも 137 でも、この手順で根本原因にたどり着けます。

コンテナのライフサイクルと終了コードを理解する

調査に入る前に、基本を押さえましょう。コンテナはなぜ終了するのか。

コンテナの本質：プロセスのライフサイクル

Docker コンテナは、隔離されたプロセスと考えると分かりやすいです。プロセスが動いている間、コンテナは Running。プロセスが終われば——正常終了でもクラッシュでも、システムに強制終了されても——コンテナはすぐ Exited になります。

Web サービスコンテナを起動したとします。中のメインプロセスは nginx や Node かもしれません。そのプロセスが動いている限り docker ps に表示されます。何らかの理由でメインプロセスが終了すると、コンテナも即 Exited になります。

だから docker ps だけでは見えず、-a を付けないと終了済みコンテナが出てこないことがあります。

終了コード早見表：数字が示すこと

コンテナが終了するたび、Docker は終了コード（Exit Code）を記録します。数字は何が起きたかの手がかりです。

Exit Code 0：正常終了。タスクが完了した状態です。データインポートスクリプトが走り切って終わる、といったケース。問題ではありません。

Exit Code 1：アプリケーション側のエラー。最もよく見るコードです。設定ミス、依存不足、コードのバグなど、コンテナ内のアプリが自分で落ちたときに出ます。

MySQL コンテナをデプロイしたとき、ずっと Exit Code 1 でした。ログを延々追った末、設定ファイルの = を : と書き間違えていたのが原因でした。MySQL は起動時に構文エラーを検出して即停止していました。

Exit Code 137：メモリ不足、または強制終了。このコードは見るたびに身が引きます。主なパターンは次の 2 つです。

1. コンテナのメモリ使いすぎで、Linux カーネルの OOM Killer（Out Of Memory Killer）にプロセスを殺された
2. docker kill や kill -9 で強制終了された

切り分けは docker inspect の OOMKilled フィールドです。true ならメモリ問題、false なら人為的な強制終了の可能性が高いです。

Exit Code 127：コマンドが見つからない。Dockerfile の CMD や ENTRYPOINT のパス誤り、イメージに実行ファイルがない、といったときに出ます。

Exit Code 139：セグメンテーション違反（Segmentation Fault）。C/C++ などで不正なメモリアクセスが起きたとき。低レイヤーのプログラム以外ではあまり見ません。

終了コードの規則性

ざっくり次のように整理できます。

• 0：正常終了
• 1〜128：アプリ側の問題（設定エラー、依存失敗など）
• 129〜255：外部要因（シグナルによる中断、システムによる強制終了など）

この規則を頭に入れておくと、終了コードを見た時点で調査の方向が決まります。

4 ステップで素早く原因を特定する

終了コードの意味は押さえました。次は、実際に問題を掘り下げる手順です。

私が使っている 4 ステップ調査法は、コンテナ起動失敗のおよそ 9 割をカバーします。この流れに沿えば、謎はかなり解けます。

ステップ 1：コンテナ状態を確認する

いきなりログを見る前に、コンテナが存在し、本当に落ちているか確認します。

docker ps -a

終了済みコンテナも含めて一覧されます。注目するのは次の項目です。

CONTAINER ID：一意の ID。以降のコマンドで使います。先頭数文字だけでも Docker は照合してくれます。

STATUS 列：Running なら Up X minutes、終了なら Exited (終了コード) X minutes ago と表示されます。

例：

CONTAINER ID   IMAGE         STATUS
a1b2c3d4e5f6   mysql:8.0     Exited (1) 2 minutes ago

終了コードが 1 ならアプリ層、137 ならメモリ周りを疑います。

作成時刻と終了時刻も見てください。起動から 1 秒未満で落ちるなら、起動コマンドや設定の可能性が高いです。しばらく動いてから落ちるなら、リソース不足や依存サービスの障害を疑います。

ステップ 2：コンテナログを確認する

最重要ステップです。終了直前のログに、ほとんどの手がかりがあります。

基本：

docker logs <container_id>

標準出力・標準エラーが表示されます。Permission denied、No such file or directory、Connection refused などが直接出ることも多いです。

リアルタイム追跡（起動過程の確認向け）：

docker logs -f <container_id>

tail -f のように新しいログを追います。すでに終了したコンテナでは意味が薄いですが、再起動を試すときに有効です。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

直近だけ見る：

docker logs --tail 100 <container_id>

ログが長いときは末尾 100 行で十分なことが多いです。

タイムスタンプ付き：

docker logs -t <container_id>

-t で各行に時刻が付き、いつ問題が起きたか特定しやすくなります。

エラーだけ抽出：

docker logs <container_id> 2>&1 | grep -i error

ログが膨大なとき、error を含む行だけに絞れます。

ステップ 3：コンテナ設定を確認する

ログだけでは分からないときは、設定と状態を深掘りします。

全体設定：

docker inspect <container_id>

JSON で大量の情報が返ります。環境変数、マウント、ネットワークなど、すべてここにあります。

終了コードだけ：

docker inspect --format '{{.State.ExitCode}}' <container_id>

OOM かどうか：

docker inspect --format '{{.State.OOMKilled}}' <container_id>

true ならメモリ不足が確定です。

環境変数：

docker inspect --format '{{.Config.Env}}' <container_id>

DB 接続文字列や API キーの誤設定がないか確認します。

マウント：

docker inspect --format '{{.Mounts}}' <container_id>

設定ファイルやデータディレクトリのマウントが正しいか見ます。

ログファイルのパス：

docker inspect --format='{{.LogPath}}' <container_id>

docker logs が使えない場合、ホスト上のログファイルを直接開けます。

ステップ 4：対話起動で検証する

ここまででまだ特定できないなら、コンテナの中に入って確認します。

対話起動：

もともと docker run -d my-app なら、-d を -it に変えてフォアグラウンドで起動します。

docker run -it my-app

起動過程の出力がそのまま画面に出ます。

シェルで入る：

起動直後に落ちるコンテナは、シェルで上書きして中に入ります。

docker run -it my-app /bin/bash

または：

docker run -it my-app /bin/sh

入ったら次を試します。

• 設定ファイルの存在：ls /etc/app/config.yaml
• 設定の構文チェック（例：MySQL なら mysqld --verbose --help）
• 起動コマンドを手動実行してエラーを再現
• 依存の疎通：ping database、telnet redis 6379

手順は多く見えますが、実務ではステップ 2 のログで解決することがほとんどです。難症例だけ 3・4 まで進めば十分です。

5 つの典型失敗シナリオと解決策

調査手順のあと、実務でよく当たるパターンを 5 つに整理しました。日常の大半はここに収まります。

シナリオ 1：設定ファイルの誤り・パス不存在

典型症状：

• Exit Code 1
• ログに No such file or directory、config file not found、syntax error など

実例：

Node.js アプリをデプロイしたとき、コンテナが起動しませんでした。ログは次のとおりです。

Error: ENOENT: no such file or directory, open '/app/config/prod.json'

docker run のマウントを -v /home/user/config:/app/conf と書いていましたが、アプリは /app/config を読んでいました。1 文字の違いで設定が見つからず、起動に失敗していました。

調査：

1. docker inspect --format '{{.Mounts}}' でマウントを確認
2. コンテナ内で ls し、ファイルの実在を確認
3. 構文エラーなら、多くのアプリがログで行番号を示します

解決：

マウントパスの誤り：

# 誤り例
docker run -v /host/path:/wrong/path my-app

# 正しい例
docker run -v /host/path:/app/config my-app

設定ファイルの構文エラー：

• YAML：yamllint やオンラインツールで検証
• JSON：jq . config.json で検証
• MySQL：コンテナ内で mysqld --verbose --help で構文チェック

シナリオ 2：メモリ不足（OOM Killed）

典型症状：

• Exit Code 137
• docker inspect --format '{{.State.OOMKilled}}' が true
• ログに Cannot allocate memory、Out of memory など

実例：

Java アプリはローカルでは問題なく、テストサーバーでは再起動を繰り返しました。ログには次のような警告がありました。

OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory failed; error='Cannot allocate memory' (errno=12)

Docker Desktop のメモリ上限が 512MB なのに対し、アプリの起動だけで 600MB 近く使っていました。

調査：

# OOM か確認
docker inspect --format '{{.State.OOMKilled}}' <container_id>

# ホストのメモリ
free -h

# コンテナのメモリ使用
docker stats <container_id>

解決：

メモリ制限の引き上げ：

docker run -m 1g my-app
docker run -m 512m --memory-swap 1g my-app

Docker Desktop の場合：

• macOS：Docker Desktop → Preferences → Resources → Memory
• Windows：Docker Desktop → Settings → Resources → Memory

アプリ側の最適化：

• Java：java -Xmx512m -jar app.jar
• Node.js：node --max-old-space-size=512 app.js
• メモリリークの有無を確認

本番では、実需要に合わせた上限、--memory-reservation によるソフトリミット、使用傾向の監視がおすすめです。

シナリオ 3：ポート競合

典型症状：

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

• Exit Code 1
• ログに port is already allocated、address already in use、bind: address already in use

実例：

月曜の朝、docker-compose up で Nginx が起動しませんでした。

Error starting userland proxy: listen tcp4 0.0.0.0:80: bind: address already in use

金曜にテストしたローカル Nginx を止め忘れ、80 番が占有されていました。

調査：

Linux/macOS：

lsof -i :8080
netstat -tuln | grep 8080

Windows：

netstat -ano | findstr 8080

他コンテナのポート：

docker ps --format "table {{.Names}}\t{{.Ports}}"

解決：

方法 1：マッピングポートを変更

docker run -p 8081:8080 my-app

方法 2：占有プロセスを停止

lsof -i :8080
kill -9 <PID>

方法 3：競合コンテナを停止

docker stop <conflicting_container>

注意：--network=host ではホストのネットワークをそのまま使うため、ポート競合が起きやすくなります。

シナリオ 4：権限不足

典型症状：

• Exit Code 1
• ログに Permission denied、Operation not permitted、chown: changing ownership failed

実例：

MongoDB コンテナにホストのデータディレクトリをマウントしたところ、起動しませんでした。

chown: changing ownership of '/data/db': Permission denied

ホスト側ディレクトリは root 所有で、コンテナ内の mongodb ユーザー（UID 999）には書き込み権限がありませんでした。

調査：

ls -la /host/data/path

コンテナ内ユーザー：

docker run -it my-app /bin/bash
whoami
id

SELinux（CentOS/RHEL）：

getenforce

解決：

方法 1：ホスト側の権限調整

chmod 777 /host/data/path   # 開発環境のみ推奨
chown -R 999:999 /host/data/path

方法 2：特権モード（本番非推奨）

docker run --privileged=true my-app

方法 3：実行ユーザーを指定

docker run --user 1000:1000 my-app

方法 4：SELinux ラベル

docker run -v /host/path:/container/path:Z my-app
docker run -v /host/path:/container/path:z my-app
setenforce 0   # 本番では非推奨

シナリオ 5：依存サービスが未準備

典型症状：

• Exit Code 1
• DB 接続失敗、Redis タイムアウト
• Connection refused、ECONNREFUSED、could not connect to server

実例：

docker-compose でマイクロサービスを立ち上げたところ、アプリコンテナだけ失敗し続けました。

Error: connect ECONNREFUSED 172.18.0.2:3306

MySQL コンテナは起動していましたが、サービス初期化が終わっておらず、接続を受け付けていませんでした。アプリが先に起動して接続に失敗し、終了していました。

調査：

docker ps
docker exec my-app ping database
docker exec my-app telnet database 3306
docker exec my-app nc -zv database 3306
docker network ls
docker network inspect <network_name>

解決：

方法 1：docker-compose の healthcheck と depends_on

version: '3.8'
services:
  database:
    image: mysql:8.0
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

  app:
    image: my-app
    depends_on:
      database:
        condition: service_healthy

方法 2：アプリ側のリトライ

async function connectWithRetry(maxRetries = 5) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      await db.connect();
      console.log('Database connected');
      return;
    } catch (err) {
      console.log(`Connection failed, retrying... (${i+1}/${maxRetries})`);
      await new Promise(resolve => setTimeout(resolve, 5000));
    }
  }
  throw new Error('Failed to connect to database');
}

方法 3：待機スクリプト

COPY wait-for-it.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/wait-for-it.sh
CMD ["wait-for-it.sh", "database:3306", "--", "node", "app.js"]

方法 4：再起動ポリシー

docker run --restart=on-failure:3 my-app

services:
  app:
    restart: on-failure

healthcheck、リトライ、再起動を組み合わせると安定しやすくなります。

予防策とベストプラクティス

起きてから直すだけでなく、最初から仕組みを入れておくと、多くの問題は起きないか、起きても自動復旧します。

ヘルスチェック（HEALTHCHECK）の設定

ヘルスチェックは、プロセスが生きているだけでなく、実際に正常に動いているかを定期的に確認する仕組みです。

Dockerfile の例：

FROM nginx:alpine

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost/ || exit 1

Web サービス：

HEALTHCHECK --interval=30s --timeout=5s --start-period=40s \
  CMD curl -f http://localhost:8080/health || exit 1

データベース：

# MySQL
HEALTHCHECK CMD mysqladmin ping -h localhost || exit 1

# PostgreSQL
HEALTHCHECK CMD pg_isready -U postgres || exit 1

# Redis
HEALTHCHECK CMD redis-cli ping || exit 1

メリット：

• Kubernetes / Swarm などが健全性に応じて再起動・再スケジュールできる
• docker-compose の depends_on で、依存先が本当に healthy になってから起動できる
• 監視と連携してアラートを出しやすい

状態確認：

docker ps
docker inspect --format='{{.State.Health.Status}}' <container_id>

再起動ポリシーの設定

失敗時に自動復旧させるには、再起動ポリシーが有効です。

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

no（デフォルト）：自動再起動なし。一度きりのジョブ向け。

docker run --restart=no my-app

on-failure[:max-retries]：異常終了時のみ再起動。

docker run --restart=on-failure:5 my-app

Exit Code が 0 以外のときだけ再起動します。

always：常に再起動。長期稼働の Web/API 向け。手動 docker stop 後も、Docker デーモン再起動時に立ち上がります。

docker run --restart=always my-app

unless-stopped：手動停止していない限り常に再起動。私が本番でよく使う設定です。docker stop したコンテナは、デーモン再起動後に自動起動しません。

docker run --restart=unless-stopped my-app

注意：

1. 10 秒ルール：初回起動後 10 秒以上動いたコンテナにだけ、再起動ポリシーが効きます。設定ミスによる無限再起動を防ぐためです。
2. 無限再起動の罠：ポート競合などでループ再起動すると、ログが急増します。ログローテーションとセットで運用してください。

稼働中コンテナのポリシー変更：

docker update --restart=unless-stopped <container_id>

docker-compose：

services:
  web:
    image: nginx
    restart: unless-stopped

  worker:
    image: my-worker
    restart: on-failure

ログ管理：ディスク枯渇を防ぐ

Docker はデフォルトで JSON ログをホストに蓄積します。放置すると数十 GB になることもあり、本番ディスクを圧迫した経験があります。

/etc/docker/daemon.json の例：

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

変更後：

sudo systemctl restart docker

コンテナごとに最大約 30MB（10MB × 3）に抑えられます。

単一コンテナ：

docker run --log-opt max-size=10m --log-opt max-file=3 my-app

docker-compose：

services:
  app:
    image: my-app
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

その他のドライバ：syslog、journald、fluentd、none（非推奨）など。

ログの場所とサイズ：

docker inspect --format='{{.LogPath}}' <container_id>
du -h $(docker inspect --format='{{.LogPath}}' <container_id>)

監視とアラート：事前に気づく

落ちてから知るのではなく、異常の兆候を早く掴みましょう。

基本：docker stats

docker stats
docker stats <container_id>

CPU、メモリ、ネットワーク I/O、ディスク I/O をリアルタイム表示します。メモリが右肩上がりなら、リークや上限不足の可能性があります。

本番：Prometheus + Grafana

services:
  prometheus:
    image: prom/prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"

  cadvisor:
    image: google/cadvisor
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
    ports:
      - "8080:8080"

メモリ 80% 超、再起動回数の急増などでアラートを設定できます。

シンプルな定期スクリプト

#!/bin/bash
EXITED=$(docker ps -a -f "status=exited" --format "{{.Names}}")

if [ -n "$EXITED" ]; then
  echo "Warning: The following containers are exited:"
  echo "$EXITED"
fi

crontab で 5 分ごとに実行する例：

*/5 * * * * /path/to/check-containers.sh

本番環境の設定チェックリスト

次の docker-compose 例をベースにすると、安定運用の土台になります。

version: '3.8'
services:
  web:
    image: my-web-app:latest
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: '2'
          memory: 1G
        reservations:
          memory: 512M
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/health"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 40s
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"
    environment:
      - NODE_ENV=production
    ports:
      - "8080:8080"
    depends_on:
      database:
        condition: service_healthy

  database:
    image: postgres:14
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    volumes:
      - db-data:/var/lib/postgresql/data
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

volumes:
  db-data:

再起動、リソース制限、ヘルスチェック、ログローテーションを揃えておけば、夜中の手動復旧はかなり減ります。

まとめ

Docker コンテナの起動失敗は怖くありません。怖いのは、調査の型がないことです。

終了コードを読む：137 ならメモリ、1 なら設定や依存——数字は Docker が残した手がかりです。

4 ステップ調査：

1. 状態確認（docker ps -a）
2. ログ（docker logs）
3. 設定（docker inspect）
4. 対話検証（docker run -it）

9 割以上はステップ 2 で終わります。

5 つの典型シナリオ：設定誤り、メモリ不足、ポート競合、権限、依存未準備。この切り口を覚えておけば十分です。

予防：ヘルスチェック、再起動ポリシー、ログ管理、監視。障害時の自動復旧と早期検知の土台になります。

保存用のクイックチェックリスト：

Docker コンテナ起動失敗チェックリスト

□ ステップ 1: docker ps -a で状態と終了コード
□ ステップ 2: docker logs <container_id> で詳細ログ
□ ステップ 3: docker inspect <container_id> で設定
□ ステップ 4: docker run -it <image> で対話検証

よくある切り分け:
- Exit Code 1 + "No such file" → マウントと設定ファイル
- Exit Code 1 + "port already allocated" → ポート競合
- Exit Code 1 + "Permission denied" → 権限と SELinux
- Exit Code 1 + "Connection refused" → 依存サービスの準備
- Exit Code 137 + OOMKilled=true → メモリ制限の増加
- Exit Code 127 → CMD/ENTRYPOINT のパス

予防:
□ HEALTHCHECK を設定
□ restart ポリシー（本番は unless-stopped 推奨）
□ ログローテーション（max-size + max-file）
□ リソース制限（-m でメモリ）
□ 監視（docker stats または Prometheus）

この記事が役に立ったら、ブックマークしておいてください。次にコンテナが落ちたとき、上から順に確認するだけで大丈夫です。特殊なケースがあれば、コメントで共有してもらえると助かります。

コンテナがずっと Up のまま、金曜の夜に「本番コンテナ落ち」のアラートが来ない週末を——そんな未来を祈っています。