LinuxFAQ.ru

systemd dependency failed — как исправить и диагностировать в Linux

Ошибка “Dependency failed for <service_name>” (зависимость не выполнена) часто встречается при загрузке или перезагрузке Linux-систем. Она особенно актуальна для пользователей, работающих с systemd. Эта статья полезна администраторам и пользователям, впервые столкнувшимся с такой ошибкой при запуске сервисов или служб в Linux.

Почему появляется ошибка “systemd dependency failed”

  • Одна или несколько обязательных зависимостей сервиса не запущены или завершились с ошибкой.
  • Ошибки в конфигурационных файлах unit-ов systemd (опечатки, неверные параметры).
  • Отсутствие или повреждение необходимых файлов и путей, указанных в unitах.
  • Задержки при загрузке аппаратных или сетевых устройств, которые не успели инициализироваться к нужному моменту.

Пошаговое решение

  1. Посмотреть точную ошибку через логи systemd

    journalctl -xe | grep "dependency failed"

    Эта команда выводит подробную информацию о сбоях сервисов и указывает, какой unit не запустился первым. Обратите внимание на строки с точными названиями зависимостей.

  2. Определить цепочку зависимостей

    systemctl list-dependencies <имя_сервиса>

    Замените <имя_сервиса> на нужный сервис, например network.service. Команда покажет все связанные службы и зависимости. Красным выделяются те, что неактивны — это хорошие кандидаты для дальнейшей проверки.

  3. Проверить статус ключевых зависимостей

    systemctl status <имя_зависимого_сервиса>

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

  4. Уточнить причину сбоя

    journalctl -u <имя_зависимого_сервиса> --since today

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

  5. Проверить наличие файлов и конфигураций

    ls -l /etc/systemd/system/<имя_сервиса>.service

    Проверьте наличие и права нужных unit-файлов. Если файл отсутствует или повреждён, его нужно пересоздать или восстановить стандартный вариант из пакета.

  6. Выявить ошибки в конфиге unit-файла

    systemd-analyze verify /etc/systemd/system/<имя_сервиса>.service

    Команда проверяет синтаксис unit-файла и сообщает о найденных ошибках или предупреждениях.

  7. Перезапустить или откатить проблемный сервис

    sudo systemctl daemon-reload
    sudo systemctl restart <имя_сервиса>

    Если причина устранена, попробуйте перезапустить сервис или всю зависимую цепочку с помощью команд выше.

Альтернативные методы

  • Временно отключить проблемный unit, если он не критичен, командой
    sudo systemctl mask <имя_сервиса>

    . Для отмены используйте unmask. Это полезно, если оборудование или функция сейчас не нужны.

  • Попробовать запуск вручную через systemctl start <имя_зависимого_сервиса> — полезно для теста, если автоматический запуск блокируется ошибкой.

Проверка результата

  • Убедитесь, что сервис и его зависимости теперь работают:
  • systemctl status <имя_сервиса>
  • Проверьте загрузку системы на наличие ошибок:
  • journalctl -p 3 -xb

    Если ошибка “Dependency failed for …” больше не появляется — проблема решена.

Как избежать ошибки в будущем

  • При изменении unit-файлов всегда проверяйте их командой systemd-analyze verify перед перезагрузкой.
  • Сохраняйте резервные копии оригинальных unit-файлов и важных конфигураций.
  • Следите за обновлениями пакетов и своевременно устраняйте проблемы с оборудованием (например, диски, сетевые интерфейсы).

FAQ

Вопрос:
Можно ли безопасно удалить зависимость, вызывающую ошибку?

Обычно нет: многие unit-ы необходимы для корректной работы сервиса. Лучше выяснить и устранить причину сбоя.

Вопрос:
Ошибка возникает только после обновления. Что делать?

Возможно, обновился unit-файл или изменились зависимости. Проверьте свежие логи, проанализируйте внесённые изменения и, если нужно, откатитесь к рабочей версии конфигураций. Подробнее о откате пакетов можно узнать в статье Как откатить пакет до предыдущей версии.

Вопрос:
Можно ли просто замаскировать временно нерабочий сервис?

Да, если он не критичен для системы. Но обязательно проверьте, нет ли у него важных зависимостей, которые повлияют на другие сервисы.

Резюмируя: системный подход к анализу зависимостей и внимательное чтение логов — самые надёжные способы решения ошибки «Dependency failed for…». Для более подробного разбора ошибок запуска служб systemd рекомендуем статью Ошибка “Failed to start service” — как исправить.

Смотрите также

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Свежие материалы