Container-Exited-Crash Linux / DevOps

Как посмотреть логи упавшего Docker-контейнера: диагностика через docker logs

Обновлено: 27.08.2026 · Официальная документация ↗

Почему контейнер Docker выключается сразу после запуска (Exited)

Типичная проблема: вы запускаете контейнер командой docker run ... или docker compose up -d, но при проверке docker ps контейнера нет в списке работающих. При выполнении docker ps -a вы видите грустный статус: Exited (1) 5 seconds ago или Exited (137). В Docker контейнер живет ровно столько, сколько живет его главный процесс (PID 1). Если в конфигурации допущена ошибка, процесс завершается сбоем, и контейнер мгновенно гаснет.

Расшифровка кодов завершения (Exit Codes)

Код выхода	Что означает	Причина
`Exited (0)`	Успешное штатное завершение	Контейнер выполнил разовый скрипт и корректно закрылся.
`Exited (1)`	Ошибка приложения	Синтаксическая ошибка в коде, неверный конфиг Nginx/PHP.
`Exited (137)`	Убит ядром (SIGKILL / OOM)	Out of Memory: серверу не хватило оперативной памяти.
`Exited (127)`	Command not found	В директиве CMD/Entrypoint указан несуществующий исполняемый файл.

Пошаговая диагностика причин падения контейнера

Шаг 1: Поиск ID и имени упавшего контейнера

Посмотрим список всех контейнеров, включая остановленные:

docker ps -a

Скопируйте имя или CONTAINER ID проблемного контейнера.

Шаг 2: Просмотр логов ошибки (docker logs)

Запросите журнал вывода контейнера:

docker logs имя_контейнера

Если лог огромный, выведите последние 50 строк с временными метками (timestamps):

docker logs --tail 50 -t имя_контейнера

(В 95% случаев в последних строках лога будет четко написано: «Configuration syntax error», «Connection refused to database» или «Permission denied»).

Шаг 3: Детальный анализ причины завершения (docker inspect)

Если лог пуст, запросим внутреннюю сводку состояния контейнера:

docker inspect имя_контейнера --format='{{json .State}}'

Обратите внимание на поля ExitCode, Error и OOMKilled (если OOMKilled: true — контейнер был уничтожен из-за нехватки RAM).

Шаг 4: Запуск контейнера в интерактивном режиме для отладки

Если контейнер падает при старте, переопределите точку входа (entrypoint), чтобы зайти внутрь и исследовать файлы вручную через оболочку bash/sh:

docker run -it --rm --entrypoint sh имя_образа

Типовые ошибки администраторов

Попытка запустить фоновый демон без foreground-режима: Если внутри контейнера запустить Nginx командой service nginx start, демон уйдет в фон, главный процесс завершится, и Docker мгновенно остановит контейнер. В Docker процессы должны работать на переднем плане: nginx -g 'daemon off;'.
Недоступность зависимых сервисов: Контейнер бэкенда падает при старте, потому что контейнер базы данных MySQL еще не успел инициализировать таблицы. Используйте проверку готовности healthcheck в docker-compose.

Контейнеры падают с непонятными ошибками или циклически перезагружаются (CrashLoopBackOff)?
Инженеры ITSTM настроят профессиональный стек observability (Prometheus, Grafana, Jaeger), найдут узкие места в микросервисах и обеспечат их стабильный запуск.

💡 Практика специалистов: При написании Dockerfile всегда проверяйте, чтобы ваше приложение перенаправляло свои логи в '/dev/stdout' и '/dev/stderr' (например: 'ln -sf /dev/stdout /var/log/nginx/access.log'). Это гарантирует, что любые сбои будут мгновенно видны через стандартную команду 'docker logs' и внешние сборщики логов.

Частые вопросы (FAQ)

Как смотреть логи Docker контейнера в реальном времени?

Используйте флаг слежения -f: docker logs -f имя_контейнера.

Почему команда docker logs ничего не выводит?

Это происходит, если приложение внутри контейнера пишет логи не в стандартные потоки STDOUT/STDERR, а напрямую в текстовый файл внутри контейнера (например, /var/log/app.log).

Как перезапустить упавший контейнер?

Используйте команду: docker start имя_контейнера или docker restart имя_контейнера.

Как посмотреть потребление оперативной памяти контейнерами в реальном времени?

Используйте встроенную команду мониторинга: docker stats.