Ошибка Failed to start service: Unit is masked в Linux появляется в тот момент, когда systemd получает команду на запуск службы, но обнаруживает, что соответствующий unit находится в состоянии masked. Для пользователя это может выглядеть странно: служба существует, её имя известно системе, но обычная команда systemctl start не позволяет её запустить.
Причина здесь не в том, что служба просто остановлена. Маскировка является отдельным состоянием systemd и представляет собой более жёсткий запрет на запуск. Пока unit замаскирован, systemd блокирует его активацию даже при ручном запуске. Чтобы вернуть службу в обычное состояние, сначала снимают маскировку командой systemctl unmask, а уже затем при необходимости запускают сервис.
Что означает состояние masked у службы systemd
В systemd существует несколько разных состояний, которые на первый взгляд можно принять за одно и то же. Служба может быть запущена, остановлена, отключена от автоматического старта или полностью замаскирована. Эти состояния решают разные задачи, поэтому команда systemctl stop, disable или mask имеет совершенно разный результат.
При обычном отключении служба перестаёт автоматически запускаться через соответствующие зависимости и механизмы включения. Однако сам unit при этом остаётся доступным. Его можно запустить вручную командой systemctl start.
Маскировка работает иначе. Для systemd замаскированный unit фактически исключается из возможности обычной активации. В документации systemd такое состояние описывается как полностью отключённое: попытка запуска должна завершаться ошибкой.
Механизм реализуется через специальную ссылку на /dev/null. Когда unit замаскирован, systemd видит вместо нормального файла конфигурации ссылку с именем соответствующего сервиса, указывающую на /dev/null. Поэтому менеджер служб не загружает обычную конфигурацию такого unit и показывает состояние masked.
Именно поэтому ошибка содержит фразу:
Failed to start service: Unit is masked
Смысл сообщения достаточно буквальный: systemd нашёл указанный unit, но запуск этого unit запрещён его текущим состоянием.
Чем masked отличается от disabled и stopped
Эти три состояния важно не смешивать, особенно при устранении проблем с системными службами.
Остановленная служба существует и может быть запущена снова. Например:
sudo systemctl stop nginx
После этого nginx не работает, но команда
sudo systemctl start nginx
может снова запустить его.
Отключенная служба тоже может быть запущена вручную. Команда:
sudo systemctl disable nginx
меняет механизм автоматического запуска, но сама по себе не устанавливает запрет на ручную активацию. В systemd включение и запуск вообще являются разными операциями: unit может быть включён, но не запущен, либо запущен без включения в автоматическую цепочку загрузки.
Замаскированная служба находится в другой ситуации:
sudo systemctl mask nginx
После этого обычная попытка запуска:
sudo systemctl start nginx
будет отклонена.
Таким образом, простая команда start здесь не решает проблему. Сначала необходимо отменить действие mask.
Удобно запомнить различие так:
-
stopостанавливает работающую службу; -
disableубирает автоматический запуск; -
maskзапрещает активацию unit.
Маскировка является более сильным ограничением, чем отключение. В документации systemd прямо указано, что mask запрещает различные способы активации unit, включая ручной запуск и включение.
Как проверить, действительно ли служба замаскирована
Прежде чем менять состояние службы, полезно проверить, что именно видит systemd. Для этого подходит команда:
systemctl status имя_сервиса
Например:
systemctl status nginx
Если unit замаскирован, в информации о нём можно увидеть состояние masked. В выводе systemd поле Loaded используется в том числе для отображения состояния загрузки unit, и masked является одним из возможных значений.
Есть и более точная команда:
systemctl is-enabled имя_сервиса
Для замаскированного unit она позволяет увидеть соответствующее состояние. Это удобно, когда не требуется длинный вывод status, а нужно быстро проверить состояние конкретной службы.
Ещё один вариант:
systemctl list-unit-files | grep имя_сервиса
Так можно посмотреть состояние установленного unit-файла среди других служб.
Проверка особенно полезна, если пользователь не уверен, что проблема действительно связана с маскировкой. Сообщение Unit is masked обычно уже даёт прямой ответ, но диагностика позволяет заодно понять, какой именно unit используется и существует ли он в системе.
Как "размаскировать" службу через systemctl unmask
Основная команда для снятия маскировки выглядит так:
sudo systemctl unmask имя_сервиса
Например, если замаскирован nginx.service:
sudo systemctl unmask nginx.service
После выполнения unmask systemd отменяет действие предыдущей команды mask. Согласно документации systemctl, unmask предназначена именно для обратного действия относительно mask.
После снятия маскировки службу можно попробовать запустить:
sudo systemctl start nginx.service
Или, если имя сервиса однозначно определяет service unit:
sudo systemctl start nginx
systemctl умеет работать с сокращённым именем service unit и в соответствующих командах может подразумевать суффикс .service. Поэтому эти варианты во многих случаях эквивалентны.
Полная последовательность выглядит так:
sudo systemctl unmask имя_сервиса
sudo systemctl start имя_сервиса
Если служба должна запускаться автоматически при загрузке системы, после успешного запуска можно отдельно включить её:
sudo systemctl enable имя_сервиса
Это уже другая операция. Снятие маскировки не означает автоматически, что служба будет запускаться при каждом старте Linux. unmask возвращает unit из состояния запрета, а enable настраивает его автоматическую активацию.
Почему команда systemctl start не помогает
Типичная ошибка при такой проблеме заключается в том, что пользователь несколько раз повторяет одну и ту же команду:
sudo systemctl start имя_сервиса
Но если unit находится в состоянии masked, повторение команды ничего не меняет. Причина отказа сохраняется до тех пор, пока не будет снята маскировка.
Это принципиально отличается от ситуации, когда служба просто не запущена. В обычном случае start переводит остановленный сервис в активное состояние. При masked systemd сначала проверяет возможность активации unit и обнаруживает запрет.
Поэтому последовательность действий должна соответствовать причине ошибки:
Unit is masked
↓
проверить состояние
↓
systemctl unmask
↓
systemctl start
↓
проверить status
Если после unmask команда start всё равно завершается ошибкой, значит проблема уже не в самой маскировке. Снятие запрета позволяет systemd попытаться запустить сервис, но не гарантирует, что приложение внутри unit действительно запустится.
Что делать, если после unmask служба всё равно не запускается
Снятие маскировки решает только одну конкретную проблему. После этого служба может столкнуться с совершенно другой причиной отказа.
Например, unit может быть повреждён, отсутствовать, содержать некорректные параметры или зависеть от другого сервиса, который не работает. Поэтому после unmask полезно сразу проверить состояние:
sudo systemctl status имя_сервиса
Если запуск завершился ошибкой, стоит посмотреть журнал systemd:
sudo journalctl -u имя_сервиса
Для просмотра последних сообщений:
sudo journalctl -u имя_сервиса -n 50
А для наблюдения за новыми сообщениями:
sudo journalctl -u имя_сервиса -f
Журнал может показать уже конкретную причину отказа. Например, после снятия маскировки systemd может сообщить об отсутствующем файле, неправильной конфигурации, недостаточных правах, занятом порте или проблеме зависимости. Само состояние masked при этом больше не является причиной ошибки.
Если unit был изменён вручную, стоит проверить его конфигурацию:
systemctl cat имя_сервиса
Команда позволяет увидеть содержимое unit и связанные фрагменты конфигурации. Это особенно полезно на системах, где администратор самостоятельно создавал или переопределял службы.
Почему службы вообще маскируют
Маскировка существует не случайно. Она нужна в ситуациях, когда недостаточно просто убрать автоматический запуск службы.
Предположим, определённый сервис не должен запускаться вообще. Простого:
sudo systemctl disable имя_сервиса
может оказаться недостаточно, потому что другой unit или пользователь сможет инициировать его запуск. Маскирование создаёт более жёсткий запрет на активацию. Именно поэтому systemd описывает mask как более сильный вариант отключения.
Маска может быть установлена администратором намеренно. Она также может появиться после определённых действий с пакетами, конфигурацией или системными компонентами. Поэтому обнаружение masked ещё не означает, что систему обязательно нужно исправлять немедленно.
Сначала стоит выяснить, зачем unit был замаскирован.
Это особенно важно для системных служб. Если снять маску с компонента, который специально заблокировали для предотвращения конфликта, после этого можно получить уже другую проблему. Например, два компонента могут пытаться управлять одним и тем же ресурсом.
Поэтому команда:
sudo systemctl unmask имя_сервиса
технически проста, но применять её стоит осознанно.
Как проверить наличие маски вручную
В обычной ситуации достаточно systemctl status и systemctl unmask. Однако иногда полезно понять, что именно происходит на уровне файловой системы.
При постоянной маскировке systemd создаёт символическую ссылку с именем unit в соответствующем каталоге конфигурации, которая указывает на /dev/null. Для обычной системной маски это, в частности, может быть:
/etc/systemd/system/имя_сервиса.service
с назначением:
/dev/null
Документация systemctl описывает именно такой механизм: команда mask связывает unit с /dev/null, из-за чего его запуск становится невозможным.
Проверить ссылку можно, например, командой:
ls -l /etc/systemd/system/имя_сервиса.service
Если там действительно находится ссылка на /dev/null, это наглядно показывает причину состояния masked.
При этом вручную удалять такую ссылку обычно не требуется. Для этого существует штатная команда:
sudo systemctl unmask имя_сервиса
Она является правильным способом отменить действие mask.
Ручное удаление файлов systemd без понимания структуры unit-файлов может привести к путанице с локальными настройками, пакетами и приоритетами каталогов. Штатная команда лучше отражает намерение администратора и позволяет systemd корректно обработать изменение.
Постоянная и временная маскировка службы
У systemd существует не только постоянная маска. Команда mask поддерживает режим --runtime, при котором изменение применяется только до следующей перезагрузки.
Например:
sudo systemctl mask --runtime имя_сервиса
В таком случае маска размещается в runtime-конфигурации, а не создаётся как постоянное изменение в /etc/systemd/system/. Документация systemd указывает, что runtime-маскировка действует только до следующей загрузки системы.
Это имеет значение при диагностике. Пользователь может обнаружить замаскированный сервис, хотя соответствующий постоянный unit-файл выглядит нормально. В таком случае причина может находиться именно в runtime-состоянии текущего запуска системы.
Есть и другие способы временно маскировать unit. Например, systemd поддерживает параметры загрузки, которые могут задавать runtime-маскировку определённых unit. Поэтому состояние masked не всегда означает, что администратор вручную создал постоянную ссылку в /etc/systemd/system/.
В обычной пользовательской ситуации, однако, начинать поиск причины достаточно с:
systemctl status имя_сервиса
systemctl is-enabled имя_сервиса
и только после этого переходить к более глубокому анализу.
Нужно ли выполнять daemon-reload после unmask
В типичном сценарии для снятия маскировки достаточно:
sudo systemctl unmask имя_сервиса
затем:
sudo systemctl start имя_сервиса
systemctl unmask предназначена для отмены эффекта mask, поэтому отдельное ручное удаление ссылки на `/dev/null не требуется.
daemon-reload нужен в других ситуациях, например после изменения содержимого unit-файлов или drop-in конфигурации, когда необходимо заставить systemd перечитать конфигурацию.
Поэтому бессмысленно добавлять daemon-reload в каждую последовательность исправления ошибки Unit is masked. Сначала следует устранить именно маску, а затем проверить результат.
Если после unmask unit всё ещё отображается как masked, это уже повод проверить, какая именно маска действует и не создаётся ли она повторно другим механизмом.
Что означает ошибка в Docker, виртуальной машине или сервере
Сама ошибка Unit is masked не является специфичной для обычного настольного Linux. Она относится к systemd, поэтому может встречаться на серверах, виртуальных машинах и других системах, где systemd используется как менеджер служб.
На сервере сообщение может появиться во время установки или настройки программного обеспечения. Например, установочный сценарий пытается запустить сервис:
systemctl start имя_сервиса
а systemd отвечает:
Failed to start имя_сервиса.service: Unit имя_сервиса.service is masked.
В такой ситуации не стоит сразу считать, что само программное обеспечение сломано. Сначала нужно определить состояние unit:
systemctl status имя_сервиса
Если действительно указано masked, можно проверить, имеет ли смысл снять маску:
sudo systemctl unmask имя_сервиса
После этого повторить запуск:
sudo systemctl start имя_сервиса
Если сервис запускается, первоначальная ошибка была связана именно с маскировкой. Если появляется новое сообщение об ошибке, диагностика продолжается уже по новому сообщению.
Такой подход важнее, чем попытка выполнить несколько случайных команд подряд. Каждая команда должна устранять конкретную причину, а не просто менять состояние системы в надежде на результат.
Почему unmask не всегда означает, что службу нужно включать
После успешного unmask некоторые пользователи сразу выполняют:
sudo systemctl enable имя_сервиса
Но это не всегда необходимо.
Если задача заключается только в разовом запуске службы, достаточно:
sudo systemctl unmask имя_сервиса
sudo systemctl start имя_сервиса
Если сервис должен запускаться автоматически при загрузке, тогда уже имеет смысл:
sudo systemctl enable имя_сервиса
При необходимости запуск и включение можно объединить:
sudo systemctl enable --now имя_сервиса
Ключевой момент заключается в том, что enable и start решают разные задачи. enable настраивает связи, благодаря которым unit будет активироваться в соответствующей цепочке загрузки или активации, а start непосредственно инициирует запуск.
Поэтому после снятия маскировки нужно определить требуемое поведение сервиса, а не автоматически включать всё подряд.
Что делать с ошибкой Failed to start service Unit is masked
Если команда запуска завершилась сообщением:
Failed to start service: Unit is masked
не нужно пытаться лечить проблему через restart, повторный start или случайный enable. Сначала проверяется состояние unit.
Базовая последовательность выглядит так:
systemctl status имя_сервиса
Если подтверждается masked, выполняется:
sudo systemctl unmask имя_сервиса
После этого можно проверить состояние:
systemctl status имя_сервиса
И повторить запуск:
sudo systemctl start имя_сервиса
Если сервис должен запускаться вместе с системой:
sudo systemctl enable имя_сервиса
Если запуск снова завершается ошибкой, следует смотреть журнал:
sudo journalctl -u имя_сервиса -n 50
Эта последовательность позволяет не смешивать разные проблемы. Сначала снимается запрет на активацию, затем проверяется сам запуск, а при необходимости исследуется причина отказа приложения или его конфигурации.
Главное здесь заключается в различии между "служба не запущена" и "службе запрещено запускаться". В первом случае достаточно команды запуска. Во втором сначала необходимо убрать установленный запрет.
Состояние masked является специальным механизмом systemd, при котором unit фактически блокируется для активации. Технически это реализуется через ссылку на /dev/null, а штатной командой для отмены такого состояния является systemctl unmask.
Поэтому при появлении сообщения Unit is masked правильное решение обычно начинается именно с проверки и снятия маскировки:
sudo systemctl unmask имя_сервиса
sudo systemctl start имя_сервиса
Если после этого появляется уже другая ошибка, значит первый барьер устранён и systemd перешёл к следующему этапу запуска. Тогда искать причину нужно уже в конфигурации службы, её зависимостях, правах доступа или журнале systemd.