Docker daemon не запускается: systemctl, journalctl и context

Автор: Казачкин Даниил Михайлович · Обновлено 29 сентября 2026 г.

Сообщение Job for docker.service failed because the control process exited with error code означает, что systemd не смог успешно запустить службу. Это сводка менеджера служб, а не диагноз. В этом уроке вы соберёте данные о конкретной попытке запуска и отличите неисправный daemon от клиента, который смотрит не на тот endpoint.

Сначала выяснить, где находится Engine

В Linux с системным rootful Engine служба обычно называется docker.service. Docker Desktop управляет своим окружением иначе, а rootless Engine может работать как пользовательская служба. Нельзя применять одни и те же systemctl-команды к любому Docker Desktop/Windows стенду.

Начальные наблюдения не меняют состояние:

docker context show
docker context ls
docker version
systemctl status docker.service --no-pager -l
journalctl -u docker.service -b --since '15 minutes ago' --no-pager

Для чтения системного журнала могут потребоваться разрешения администратора. journalctl -xeu docker.service — удобный интерактивный вариант из самой ошибки, но для отчёта лучше сохранить ограниченный интервал. Не публикуйте журнал без проверки: proxy URLs и параметры конфигурации могут содержать чувствительные сведения.

Читать предыдущую причину

Ищите сообщения непосредственно перед завершением процесса: некорректный JSON, конфликт опций, отсутствующий каталог, недостаток места, ошибка storage driver или отказ доступа к socket. Если status говорит лишь start request repeated too quickly, найдите более раннюю первую попытку. Увеличение лимита повторов не исправляет первичную неисправность.

Сравните systemctl cat docker.service и конфигурацию daemon. Параметр, заданный одновременно флагом и в daemon.json, может вызвать отказ, даже если каждое значение по отдельности корректно. Распространённый пример — hosts и -H в ExecStart. Официальный разбор конфликтов.

Проверка файла до перезапуска

Скопируйте предполагаемый файл конфигурации в отдельное место и проверьте его:

dockerd --validate --config-file ./daemon.candidate.json

Это проверка конфигурации, не запуск второго daemon. Успешная валидация не доказывает доступность диска или корректность всех параметров systemd. Перед заменой рабочего файла сохраните его предыдущую версию, сравните diff и согласуйте окно перезапуска с приложениями, которые используют Engine. Валидация dockerd.

Не заменяйте целый daemon.json коротким примером из статьи, потеряв registry mirrors, runtime, logging и параметры сети. Исправление должно отвечать наблюдаемой причине и сохранять остальные настройки.

Daemon жив, но клиент не подключается

Если systemctl показывает active, а CLI — отказ соединения, проверьте context, DOCKER_HOST и права пользователя на выбранный Unix socket. Не удаляйте все переменные без разбора: они могут намеренно задавать удалённый endpoint. Для rootless сравните пользовательский socket и systemctl --user status docker в той же учётной записи.

Группа docker даёт широкие привилегии над Engine и фактически значительные возможности на Linux-хосте. Не исправляйте доступ через chmod 666 /var/run/docker.sock. Пользователь должен получить именно предусмотренный доступ либо пользоваться rootless-сценарием. Права Linux Engine.

Рабочий отчёт об ошибке

Сохраните ОС, режим Engine/Desktop/rootless, версии клиента и сервера, endpoint без секретов и первую конкретную строку отказа. Для ошибки proxy отличайте настройки shell, daemon и сборщика: удачный curl в терминале не доказывает корректность окружения службы. После одного обоснованного изменения проверьте запуск, docker info и маленький контейнер, затем завершайте диагностику. Бесконечные перезагрузки и удаление /var/lib/docker не заменяют такой проверки и могут уничтожить нужные данные.