Dependency failed for … и результат 'dependency' — причины и решение

Что это значит

Отношения задаются параметрами Requires=, BindsTo= и Requisite=: неудача любого из них отменяет запуск. Wants= так не работает — при нём служба запустится даже при упавшей зависимости.

Частая цепочка на серверах: не смонтировался раздел, из-за этого не поднялась база, из-за неё — приложение. В журнале три сообщения, а причина одна, самая первая.

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

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

Упала служба, указанная в Requires=

Жёсткая зависимость отменяет запуск. Сообщение про зависимость появляется у всех, кто на неё ссылается, и настоящая ошибка тонет среди них.
Не смонтировался нужный раздел

Точки монтирования — тоже unit. Неудача монтирования тянет за собой всё, что от него зависит, включая зависимости, созданные автоматически по RequiresMountsFor=.
Зависимость не найдена вовсе

Опечатка в имени или отсутствующий unit тоже приводят к неудаче: systemd не может выполнить требование к тому, чего нет.
Циклическая зависимость разорвана systemd

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

Диагностика

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

Первым делом: показывает все упавшие unit, включая настоящего виновника.

systemctl --failed --no-pager

Дерево зависимостей с состояниями: видно, какая ветка не поднялась.

systemctl list-dependencies myapp.service --no-pager

Все сообщения о зависимостях за текущую загрузку в одном списке — по ним легко найти первое.

journalctl -b --no-pager | grep -iE "dependency failed|failed to mount" | head -20

Решение

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

1. Упала служба, указанная в Requires=

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

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

Найдите, что упало первым.

systemctl list-dependencies myapp.service --no-pager
systemctl --failed --no-pager

Как исправить: Разбирайтесь с упавшей зависимостью. Если её неудача не должна мешать вашей службе, замените Requires= на Wants=.

2. Не смонтировался нужный раздел

Почему происходит: Точки монтирования — тоже unit. Неудача монтирования тянет за собой всё, что от него зависит, включая зависимости, созданные автоматически по RequiresMountsFor=.

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

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

systemctl list-units --type=mount --state=failed --no-pager
journalctl -u data.mount -n 20 --no-pager

Как исправить: Исправьте монтирование: проверьте запись в /etc/fstab, существование устройства и файловую систему.

3. Зависимость не найдена вовсе

Почему происходит: Опечатка в имени или отсутствующий unit тоже приводят к неудаче: systemd не может выполнить требование к тому, чего нет.

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

Проверьте имена зависимостей.

systemctl show myapp.service -p Requires -p Wants -p After
systemctl status имя-зависимости.service

Как исправить: Исправьте имя с полным расширением (.service, .target, .mount) или уберите ссылку на несуществующий unit.

4. Циклическая зависимость разорвана systemd

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

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

Поищите сообщения про цикл в журнале загрузки.

journalctl -b --no-pager | grep -i "cycle\|breaking ordering"

Как исправить: Уберите лишнюю связь. Порядок задаётся After=, а необходимость — Requires=: их смешивание и создаёт циклы.

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

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

× backup.service - Nightly backup
     Loaded: loaded (/etc/systemd/system/backup.service; enabled; preset: enabled)
     Active: inactive (dead)

systemd[1]: mnt-backup.mount: Mount process exited, code=exited, status=32/n/a
systemd[1]: mnt-backup.mount: Failed with result 'exit-code'.
systemd[1]: Dependency failed for backup.service - Nightly backup.
systemd[1]: backup.service: Job backup.service/start failed with result 'dependency'.

Полезная строка здесь первая: код 32 от команды mount. Две последние — только следствие.

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

Failed with result 'exit-code' Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
Failed with result 'exec-condition' и condition failed Состояния exec-condition и condition failed: запуск не состоялся, потому что условие не выполнено. Это не сбой, а задуманное поведение.
Mount process exited, code=exited, status=32: не найдено устройство Монтирование не проходит: устройство или UUID не найдены, неверная файловая система, недоступен сетевой ресурс. Код 32 от команды mount.
You are in emergency mode: система не загрузилась Загрузка остановилась в аварийном режиме. Что проверять: fstab, файловые системы, цель по умолчанию. Как войти и починить.
A start job is running: загрузка висит на одной службе Загрузка останавливается с обратным отсчётом: служба не укладывается в таймаут. Как найти виновника и не ждать.
Cannot assign requested address при привязке Ошибка 99 при привязке: адрес не принадлежит машине или ещё не поднят. Разбор с network-online.target и ip_nonlocal_bind.
Connection refused в журнале службы Соединение отклонено: служба не может подключиться к базе, кешу или другому сервису. Порядок запуска, адрес, брандмауэр.
Found ordering cycle: циклическая зависимость при загрузке systemd нашёл цикл в порядке запуска и разорвал его, отбросив одну зависимость. Как найти цикл и правильно расставить After и Requires.

Источники

systemd.unit(5)
Requires=, Wants=, BindsTo=, Requisite= и последствия неудачи зависимости. официальная документация, systemd 255
сверено 15 сентября 2026
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено связкой mount-unit с неверным UUID и службы с RequiresMountsFor. собственная проверка, systemd 255
сверено 15 сентября 2026