Docker Error: Container is not running — Диагностика и запуск
Механика жизненного цикла контейнера и причины остановки PID 1
Ошибка Error response from daemon: container is not running возникает при попытке выполнить команды взаимодействия с активным процессом (например, docker exec, docker attach, docker top) в контейнере, который перешел в статус Exited, Dead или Created. В архитектуре Linux-контейнеров жизненный цикл пространства имен жестко привязан к основному процессу (PID 1). Если процесс завершился (с кодом 0 или ошибкой >0), ядро незамедлительно уничтожает изолированное окружение.
Бизнес-риски:
Недоступность сервиса для клиентов, аварийные перезапуски (CrashLoopBackOff) в системах оркестрации, потеря фоновых задач и зависание очередей сообщений.
Таблица типовых кодов завершения процесса PID 1
| Exit Code | Событие ядра / Сигнал | Причина падения |
|---|---|---|
0 | Success | Скрипт Entrypoint завершил выполнение всех инструкций и завершился. |
1 / 2 | Application Error | Синтаксическая ошибка в коде, неверный конфиг или отсутствующий файл. |
137 | SIGKILL (OOM Killer) | Принудительное уничтожение процесса ядром Linux из-за нехватки RAM. |
139 | SIGSEGV | Ошибка сегментации памяти (Segmentation Fault) в бинарном файле. |
Пошаговое восстановление и анализ причин остановки
Сценарий 1: Чтение логов аварийно завершенного контейнера
Получите последние сообщения stdout/stderr перед падением процесса:
# Просмотр последних 100 строк логов контейнера
docker logs --tail 100 <container_id_or_name>
# Получение точного кода завершения и времени падения
docker inspect <container_id_or_name> --format='{{.State.ExitCode}} | Error: {{.State.Error}} | FinishedAt: {{.State.FinishedAt}}'Сценарий 2: Отладка в интерактивном режиме с переопределением Entrypoint
Если процесс немедленно падает при старте, переопределите точку входа на командный шелл:
# Запуск контейнера в режиме отладки с доступом к консоли sh
docker run -it --rm --entrypoint /bin/sh <image_name>
# Запуск контейнера с доступом к bash:
docker run -it --rm --entrypoint /bin/bash <image_name>Сценарий 3: Запуск фонового контейнера без завершения PID 1
Если контейнер создается для задач администрирования, удерживайте PID 1 активным:
# Пример правильного запуска контейнера в фоне
docker run -d --name debug-container <image_name> tail -f /dev/null
# Теперь exec выполнится без ошибок
docker exec -it debug-container shТиповые ошибки администраторов
- Попытка использовать exec для запуска сервиса: Команда
docker execпредназначена только для добавления процесса в УЖЕ работающий контейнер. Для старта используйтеdocker start. - Игнорирование OOM-событий в dmesg: Если exit code равен 137, администраторы часто ищут ошибку в коде приложения, вместо настройки лимитов памяти.
Эксперты ITSTM настроят централизованный сбор метрик и логов (EFK/Loki), оптимизируют потребление памяти и ликвидируют падения PID 1.
Частые вопросы (FAQ)
Почему команда docker exec выдает эту ошибку сразу после docker start?
Контейнер упал за доли секунды между выполнением start и exec. Проверьте docker logs и статус docker ps -a.
Что делать, если в логах контейнера пусто?
Приложение перенаправляет логи в локальный файл внутри контейнера или падает до инициализации логгера. Переопределите entrypoint на shell.
Как автоматически перезапускать упавший контейнер?
Используйте политику перезапуска --restart unless-stopped или --restart on-failure:5 при создании контейнера.
Может ли конфликт портов вызывать немедленную остановку контейнера?
Да, если bind-порт уже занят другим процессом на хосте, dockerd не сможет запустить сетевой стек и остановит процесс.