Как проверить, запущен ли Docker daemon

• Быстро проверьте состояние Docker через systemctl, файл PID или просмотр процессов (top/pidof). Если демон недоступен — будет сообщение “can’t connect to Docker daemon” при запуске команды docker.
• Для зависших PID-файлов удалите /var/run/docker.pid при отсутствии процесса и перезапустите сервис. Для детальной диагностики запуск dockerd –debug и просмотр логов systemd.

Быстрая навигация

• Проверка через systemctl
• Просмотр деталей процесса
• Работа с зависшими PID-файлами
• Проверка отдельных контейнеров
• План действий при неисправности

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

Ниже — подробная инструкция, как проверить, работает ли демон Docker, и как диагностировать проблемы с контейнерами и командой

docker

При отсутствии демона вы будете получать ошибку вида “can’t connect to Docker daemon” при попытке выполнить любую docker-команду.

Проверка через systemctl

На дистрибутивах с systemd (Debian, Ubuntu, CentOS, Red Hat и т. п.) самый быстрый способ — посмотреть статус сервиса:

sudo systemctl status docker

Обратите внимание на строку “Active”. Если видно

active (running)

в зелёном — демон Docker запущен и контейнеры должны быть доступны.

Если состояние inactive, значит сервис остановлен — попробуйте запустить его:

sudo systemctl start docker

Если статус failed — демон не смог стартовать. В выводе команды systemctl есть секция логов запуска (journal), она часто указывает на причину. Для детального просмотра используйте:

sudo journalctl -u docker --no-pager --since "1 hour ago"

Когда простые способы не помогают, запустите демон в отладочном режиме, чтобы увидеть подробный вывод при старте:

sudo dockerd --debug

Иногда помогает перезагрузка хоста или полная перезагрузка сервиса:

sudo systemctl restart docker

Важно: если вы используете rootless Docker или альтернативный системный менеджер, команды и пути могут отличаться.

Просмотр деталей процесса

Демон записывает свой PID в файл /var/run/docker.pid при старте. Наличие этого файла обычно означает, что демон запущен и готов к подключению.

cat /var/run/docker.pid

Этот PID можно использовать с инструментами мониторинга, например с top:

cat /var/run/docker.pid

top -p 1000

Альтернативно получите PID через pidof:

pidof dockerd

и затем запустите

top -p `pidof dockerd`

Если в выводе top есть процесс dockerd, демон активен. Это может быть надёжнее, чем проверка PID-файла: при краше демона файл /var/run/docker.pid может остаться, хотя процесса уже нет.

Работа с зависшими PID‑файлами

Если при попытке старта демона вы видите сообщение:

failed to start daemon: pid file found, ensure docker is not running or delete /var/run/docker.pid

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

pidof dockerd

Если команда не возвращает ничего — процесса нет. Удалите файл и запустите демон заново:

sudo rm /var/run/docker.pid
sudo systemctl start docker

Источники проблем с PID-файлами: снапшоты виртуальных машин, восстановление образов, аварийные завершения процесса без очистки файлов.

Проверка отдельных контейнеров

Список запущенных контейнеров показывает команда:

docker ps

Чтобы быстро проверить, запущен ли конкретный контейнер по имени или ID, используйте фильтрацию:

docker ps | grep my-container-name

Если контейнер остановлен, он не появится в обычном docker ps. Для просмотра всех контейнеров (включая остановленные) используйте:

docker ps -a

Запуск остановленного контейнера:

docker start my-container

Остановка:

docker stop my-container

Для подробного JSON-описания состояния контейнера применяйте:

docker inspect my-container | less

Это полезно для проверки сетевых настроек, примонтированных томов и меток.

Мини-поездка по диагностике: шаги при проблеме с соединением CLI

1. Выполните docker version и посмотрите, возникает ли ошибка соединения.
2. Проверте systemctl: sudo systemctl status docker.
3. Если сервис упал — sudo journalctl -u docker -n 200.
4. Если PID-файл присутствует: pidof dockerd — если пусто, удалите /var/run/docker.pid.
5. Запустите sudo dockerd --debug для получения подробного вывода.
6. Проверьте доступность сокета Docker (/var/run/docker.sock) и права доступа.
7. Если проблема только с контейнером — docker ps -a и docker logs .

План действий (SOP) для администратора

• Шаг 1: Быстрая проверка статуса сервиса и проверка PID.
• Шаг 2: Сбор логов через journalctl и вывод dockerd –debug.
• Шаг 3: Удаление орфанного PID и перезапуск сервиса.
• Шаг 4: Проверка файловой системы на свободное место и прав доступа к сокету.
• Шаг 5: Если не помогает — резервирование конфигурации, обновление Docker до последней стабильной и перезагрузка хоста.

Критерии приёмки

• docker клиент возвращает docker ps без ошибок.
• systemctl status docker показывает active (running).

Роль‑ориентированные контрольные списки

• Сисадмин:
  • Проверил systemctl и журнал.
  • Удалил орфанные PID-файлы, если нужно.
  • Проверил диск и права на /var/run/docker.sock.
• Девопс/разработчик:
  • Проверил docker ps -a и docker logs проблемных контейнеров.
  • Попробовал перезапустить контейнеры с docker restart.
• Оператор поддержки:
  • Собрал выводы docker version, docker info, и журнал systemd для передачи дальше.

Факто‑бокс: ключевые файлы и команды

• Демон: dockerd
• Сокет по умолчанию: /var/run/docker.sock
• PID-файл: /var/run/docker.pid
• Важные команды: systemctl status|start|restart docker, journalctl -u docker, dockerd --debug, docker ps, docker inspect

Когда методы не сработают

• Если используется rootless Docker, systemd unit может быть другим — проверьте документацию rootless.
• Если сокет перенаправлен на удалённый daemon (DOCKER_HOST), локальный systemd проверять бессмысленно — нужно убедиться, что DOCKER_HOST доступен.
• В окружениях с контейнерным менеджером (k3s, Containerd) команды и юниты отличаются.

Безопасность и права доступа

• Доступ к /var/run/docker.sock эквивалентен привилегиям root. Не давайте права на сокет ненадёжным пользователям.
• При использовании удалённого демона используйте TLS для шифрования и аутентификации.

Критические проверки перед удалением PID-файла

• Убедитесь, что pidof dockerd не вернул PID.
• Убедитесь, что systemctl показывает, что сервис не активен.
• Резервная копия конфигурации Docker (daemon.json) перед внесением изменений.

Примеры тестов/приёмки

• После перезапуска демона docker ps должен вернуть код 0 и список контейнеров.
• curl --unix-socket /var/run/docker.sock http://v1.24/containers/json должен вернуть JSON без ошибки соединения.

Краткий глоссарий

• Демон: фоновый процесс, предоставляющий сервисы (здесь — dockerd).
• PID-файл: файл с идентификатором процесса.
• Сокет: файл для локального IPC, /var/run/docker.sock.

Резюме

Проверить, работает ли Docker, можно несколькими путями: systemctl, проверка PID, просмотр процессов и проверка состояния конкретных контейнеров через docker ps/inspect. При зависших PID-файлах удаление /var/run/docker.pid (после проверки отсутствия процесса) обычно решает проблему. Для глубокого анализа используйте dockerd --debug и логи systemd.

Важно

• Всегда проверяйте, что вы не удаляете PID-файл при работающем демоне.
• Доступ к сокету Docker должен быть ограничен, потому что даёт привилегии root.

Краткое действие для восстановления (шаги)

1. sudo systemctl status docker
2. sudo journalctl -u docker -n 200
3. pidof dockerd || sudo rm /var/run/docker.pid
4. sudo systemctl start docker
5. docker ps && docker inspect

Окончательное замечание

Если после всех шагов демон не стартует и логи не дают ясной причины, рассмотрите обновление пакета Docker, проверку несовместимых конфигураций (daemon.json) и, при необходимости, обращение в сообщество или поддержку поставщика Docker.