Логи и код завершения

3. Пустой журнал тоже наблюдение

Распространённая ошибка диагностики — попытка сделать вывод о причине аварии исключительно по ненулевому коду возврата или предположение, что при пустом журнале ошибки не произошло.

Запросим журнал контейнера cf_docker_course_l06_silent:

docker logs cf_docker_course_l06_silent

Команда не выводит ничего. Однако статус контейнера подтверждает сбой:

docker inspect --format '{{.State.ExitCode}}' cf_docker_course_l06_silent

3

Сравним три созданных процесса по трём наблюдаемым признакам:

Контейнер	Состояние (State.Status)	Код (State.ExitCode)	Вывод docker logs	Фактический результат
cf_docker_course_l06_ok	exited	0	job done	Процесс успешно выполнил задачу и завершился без ошибок
cf_docker_course_l06_err	exited	7	missing CONFIG	Сбой подтверждён ненулевым кодом и текстом ошибки в stderr
cf_docker_course_l06_silent	exited	3	(пусто)	Сбой зафиксирован кодом, но причина в стандартные потоки не записана

Ненулевой код State.ExitCode фиксирует сам факт сбоя, но не объясняет его механизм: код 1, 3 или 7 может быть следствием неверного аргумента, отсутствующего файла конфигурации или внутренней ошибки приложения. Пустой вывод docker logs также не означает исправность: программа могла записать ошибку во внутренний файл на диске, который не направлен в stdout/stderr, либо аварийно завершиться ещё до инициализации логгера.

Корректная диагностика всегда опирается на сопоставление трёх источников: статуса и кода завершения в docker inspect, записей в docker logs и ожидаемого поведения самой программы.

После завершения диагностики освободим созданные учебные ресурсы, удалив сохранённые экземпляры:

docker rm cf_docker_course_l06_ok cf_docker_course_l06_err cf_docker_course_l06_silent cf_docker_course_l06_tail

Удаление остановленных контейнеров очищает их метаданные и перехваченные журналы, поэтому диагностические сведения считывают до вызова docker rm.