Замаскированная зависимость мешает загрузке
Замаскированный unit не запускается ни при каких условиях. Если он объявлен жёсткой зависимостью, зависимая служба тоже не поднимется — а причина будет видна только в строке про зависимость.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Замаскирована жёсткая зависимость
Маскировку поставили, чтобы отключить службу, не заметив, что от неё зависят другие.
-
Маскировку поставило средство управления конфигурацией
Тогда она вернётся при следующем прогоне, даже если вы её снимете вручную.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Полный список замаскированных unit.
systemctl list-unit-files --state=masked --no-pagerДерево зависимостей с состояниями.
systemctl list-dependencies myapp.service --no-pagerСообщения о маскировке за текущую загрузку.
journalctl -b --no-pager | grep -i masked | headРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Маскировку поставили, чтобы отключить службу, не заметив, что от неё зависят другие.
- Как проверить
-
Посмотрите все замаскированные unit и зависимости службы.
systemctl list-unit-files --state=masked --no-pager systemctl list-dependencies myapp.service --no-pager | head -20
- Как исправить
-
Снимите маскировку или замените жёсткую зависимость мягкой, если служба может работать без неё.
sudo systemctl unmask имя.service
- Почему происходит
- Тогда она вернётся при следующем прогоне, даже если вы её снимете вручную.
- Как проверить
-
Посмотрите время создания ссылки маскировки.
ls -l /etc/systemd/system/*.service | grep "/dev/null"
- Как исправить
- Правьте описание состояния в средстве управления конфигурацией, а не только систему.
Пример вывода
Зависимость замаскирована, служба не поднимается. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
systemd[1]: Dependency failed for myapp.service - My application.
systemd[1]: myapp.service: Job myapp.service/start failed with result 'dependency'.
systemd[1]: redis-server.service: Unit is masked.Связанные ошибки
- Unit is masked: служба запрещена к запуску Сообщение Unit is masked: unit заблокирован ссылкой на /dev/null. Как найти и снять маскировку.
- Dependency failed for … и результат 'dependency' Сообщение Dependency failed for: служба не запускалась, потому что упала её зависимость. Как найти настоящего виновника.
- You are in emergency mode: система не загрузилась Загрузка остановилась в аварийном режиме. Что проверять: fstab, файловые системы, цель по умолчанию. Как войти и починить.
- Found ordering cycle: циклическая зависимость при загрузке systemd нашёл цикл в порядке запуска и разорвал его, отбросив одну зависимость. Как найти цикл и правильно расставить After и Requires.
- Контейнеры не поднимаются при загрузке сервера Контейнеры с политикой перезапуска не стартуют после перезагрузки: docker не включён, тома на неподмонтированном разделе, своя служба без зависимостей.
- Служба стартует раньше своего сокета При сокет-активации порядок обратный обычному: сокет должен подниматься первым. Как это объявить.
- Цель не достигнута: служба ждёт target, который не наступает Служба не запускается, потому что не достигнута цель из After= или Requires=. Разбор целей multi-user, network-online, graphical.
- A start job is running: загрузка висит на одной службе Загрузка останавливается с обратным отсчётом: служба не укладывается в таймаут. Как найти виновника и не ждать.
Источники
-
systemctl(1)
Команды mask и unmask. -
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено маскировкой службы, объявленной в Requires другой службы.