мешает работе docker загрузка зависимости

Контейнеры не поднимаются при загрузке сервера

После перезагрузки контейнеры могут не подняться по трём причинам: сама служба Docker не включена в автозапуск, тома лежат на ещё не смонтированном разделе, или ваша служба-обёртка запускается раньше демона.

Вероятные причины

По порядку: сверху то, что встречается чаще.

Служба Docker не включена в автозапуск

Политика перезапуска контейнеров работает только когда демон запущен. Если он не в автозапуске, поднимать контейнеры некому.
Тома на разделе, который монтируется позже

Контейнер стартует раньше монтирования и либо падает, либо работает с пустым каталогом — второе хуже, потому что незаметно.
Своя служба запуска контейнеров без зависимости от Docker

Обёртка, вызывающая docker compose, стартует раньше демона и получает отказ подключения к сокету.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Включён ли Docker в автозапуск.

systemctl is-enabled docker docker.socket

Состояние контейнеров и их политика перезапуска.

docker ps -a --format "{{.Names}} {{.Status}} {{.Labels}}" | head

Что происходило с демоном при загрузке.

journalctl -b -u docker --no-pager | head -30

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Служба Docker не включена в автозапуск

Почему происходит: Политика перезапуска контейнеров работает только когда демон запущен. Если он не в автозапуске, поднимать контейнеры некому.

Как проверить

Посмотрите состояние включения.

systemctl is-enabled docker docker.socket

Как исправить

Включите и службу, и сокет: без автозапуска демона политика перезапуска контейнеров не работает.

sudo systemctl enable --now docker.socket docker.service

2. Тома на разделе, который монтируется позже

Почему происходит: Контейнер стартует раньше монтирования и либо падает, либо работает с пустым каталогом — второе хуже, потому что незаметно.

Как проверить

Посмотрите, где лежат тома и когда монтируется раздел.

docker volume ls
findmnt -T /srv/docker-data

Как исправить

Добавьте зависимость от монтирования в переопределении unit-файла Docker.

sudo systemctl edit docker   # [Unit]\nRequiresMountsFor=/srv/docker-data

3. Своя служба запуска контейнеров без зависимости от Docker

Почему происходит: Обёртка, вызывающая docker compose, стартует раньше демона и получает отказ подключения к сокету.

Как проверить

Посмотрите зависимости своей службы.

systemctl cat myapp-compose.service | grep -E "After|Requires"

Как исправить

Добавьте After=docker.service и Requires=docker.service в свою службу.

[Unit]
Requires=docker.service
After=docker.service

Пример вывода

Обёртка стартовала раньше демона. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

myapp-compose[1100]: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
systemd[1]: myapp-compose.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Started docker.service - Docker Application Container Engine.

Связанные ошибки

Dependency failed for … и результат 'dependency' Сообщение Dependency failed for: служба не запускалась, потому что упала её зависимость. Как найти настоящего виновника.
Connection refused в журнале службы Соединение отклонено: служба не может подключиться к базе, кешу или другому сервису. Порядок запуска, адрес, брандмауэр.
Цель не достигнута: служба ждёт target, который не наступает Служба не запускается, потому что не достигнута цель из After= или Requires=. Разбор целей multi-user, network-online, graphical.
Docker: демон не запускается без containerd docker.service падает, потому что не работает containerd.service. Разбор зависимости и сокета containerd.
Found ordering cycle: циклическая зависимость при загрузке systemd нашёл цикл в порядке запуска и разорвал его, отбросив одну зависимость. Как найти цикл и правильно расставить After и Requires.
Замаскированная зависимость мешает загрузке Служба не запускается, потому что замаскирован unit, который она требует. Как найти все замаскированные unit.
Служба стартует раньше своего сокета При сокет-активации порядок обратный обычному: сокет должен подниматься первым. Как это объявить.
A start job is running: загрузка висит на одной службе Загрузка останавливается с обратным отсчётом: служба не укладывается в таймаут. Как найти виновника и не ждать.

Где встречается чаще всего

docker.service 7

Источники

Документация Docker: политика перезапуска контейнеров документация программы
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено службой-обёрткой без зависимости от docker.service. собственная проверка, systemd 255
сверено 15 сентября 2026