SystemdDoctor
служба не работает частое конфигурация автозапуск

Unit is masked: служба запрещена к запуску

Маскировка — это самый жёсткий способ запретить службу: её unit-файл подменяется ссылкой на /dev/null, и запустить её нельзя ни вручную, ни по зависимости. Сообщение Unit is masked означает именно это состояние, а не обычное отключение.

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

Отличие от отключения важно. Отключённая служба (disable) не запускается сама, но её можно запустить руками и она поднимется по зависимости. Замаскированная (mask) не запустится ни при каких условиях, и попытки дают ошибку.

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

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

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

  1. Службу замаскировали вручную и забыли

    Команду systemctl mask применяют, чтобы точно исключить запуск на время работ. Через месяц причина забывается, а запрет остаётся.

  2. Маскировку поставил пакет или средство управления конфигурацией

    Некоторые пакеты маскируют конкурирующие службы (например apache при установке nginx). Ansible и подобные средства делают это по описанию состояния.

  3. Замаскирована зависимость, а не сама служба

    Тогда сообщение относится к другому unit, и ваша служба не запускается по цепочке. В журнале это видно как неудача зависимости.

Диагностика

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

Полный список замаскированных unit на машине — обычно в нём и находится ответ.

systemctl list-unit-files --state=masked --no-pager

Печатает «masked» одним словом, без разбора вывода status.

systemctl is-enabled myapp.service

Показывает ссылку на /dev/null — это и есть маскировка.

ls -l /etc/systemd/system/myapp.service

Решение

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

1. Службу замаскировали вручную и забыли
Почему происходит
Команду systemctl mask применяют, чтобы точно исключить запуск на время работ. Через месяц причина забывается, а запрет остаётся.
Как проверить
Посмотрите состояние unit-файла. 
systemctl is-enabled myapp.service
systemctl list-unit-files | grep myapp
Как исправить
Снимите маскировку и включите службу заново. 
sudo systemctl unmask myapp.service && sudo systemctl enable --now myapp.service
2. Маскировку поставил пакет или средство управления конфигурацией
Почему происходит
Некоторые пакеты маскируют конкурирующие службы (например apache при установке nginx). Ansible и подобные средства делают это по описанию состояния.
Как проверить
Найдите ссылку маскировки и посмотрите её время создания. 
ls -l /etc/systemd/system/myapp.service /run/systemd/system/myapp.service 2>/dev/null
Как исправить
Если маскировка не нужна — снимите её. Если её ставит средство управления конфигурацией, правьте описание состояния, иначе она вернётся при следующем прогоне.
3. Замаскирована зависимость, а не сама служба
Почему происходит
Тогда сообщение относится к другому unit, и ваша служба не запускается по цепочке. В журнале это видно как неудача зависимости.
Как проверить
Посмотрите состояния всех зависимостей. 
systemctl list-dependencies myapp.service --no-pager | head -20
systemctl list-unit-files --state=masked --no-pager
Как исправить
Снимите маскировку с нужной зависимости. Список всех замаскированных unit показывает вторая команда.

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

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

$ sudo systemctl start apache2.service
Failed to start apache2.service: Unit apache2.service is masked.

$ ls -l /etc/systemd/system/apache2.service
lrwxrwxrwx 1 root root 9 Sep 10 11:20 /etc/systemd/system/apache2.service -> /dev/null

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

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

Источники

  • systemctl(1)
    Команды mask, unmask и отличие от disable.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Проверено на службе apache2, замаскированной вручную.     собственная проверка, systemd 255
    сверено 15 сентября 2026