Linux what is masked service

systemd: маскировка юнитов

Оригинал: systemd: Masking units
Автор: Ashutosh Sudhakar Bhakare
Дата публикации: 18 ноября 2015 г.
Перевод: А.Панин
Дата перевода: 1 декабря 2015 г.

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

Два первых уровня «ограничения работоспособности» системной службы

Вы должны знать эти часто используемые команды systemctl :

Эти команды позволяют немедленно запустить или остановить веб-сервер (httpd) благодаря информации из соответствующего юнит-файла. Можете считать команду stop командой первого уровня «ограничения работоспособности» системной службы на основе соответствующего юнита systemd.

Также вы наверняка помните эти часто используемые команды:

Эти команды не позволяют добиться немедленного изменения состояния системной службы. Но они гарантируют то, что служба будет запущена (или не будет запущена) в процессе следующей загрузки системы. Можете считать команду disable командой второго уровня «ограничения работоспособности» системной службы на основе соответствующего юнита systemd.

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

Зависимости между юнитами

Важно помнить о том, что systemd является гораздо более сложной системой инициализации, нежели классическая система init . В системе инициализации init порядок запуска и остановки служб обуславливался именами соответствующих файлов. Этими файлами обычно являлись символьные ссылки на сценарии инициализации, размещаемые в директории с именем, соответствующим уровню исполнения , на котором они должны быть использованы. (Если вам необходимо освежить в памяти концепцию уровней исполнения, обратитесь к данной ранее опубликованной статье о системе инициализации systemd.) Например, рассмотрим следующую ссылку на сценарий инициализации:

Эта ссылка размещена в директории /etc/rc3.d/ . Ссылка описывает действие, которое будет выполнено при переходе системы на уровень исполнения 3 или в многопользовательский режим. Буква S в имени ссылки означает то, что сценарий будет использоваться для запуска службы. Буква K , напротив, указывает на то, что сценарий будет использоваться для остановки (прекращения работы) службы. Число 40 указывает на порядок запуска сценария. Сценарии, в именах ссылок на которые содержатся меньшие числа, будут исполняться до рассматриваемого сценария, а а большие числа — после. Сам сценарий расположен в директории /etc/init.d/ .

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

Более того, systemd использует данную информацию в процессе разрешения зависимостей юнитов для запуска необходимых служб даже в том случае, если эти службы деактивированы . В качестве примера рассмотрим некоторые зависимости службы httpd.service :

Данный граф отображает юниты, от которых зависит юнит веб-сервера. Обратите внимание на то, что данный граф является рекурсивным и это означает, что он также отображает зависимости зависимостей рассматриваемого юнита.

Давайте рассмотрим эффект, который произведет деактивация необходимого для корректного запуска службы юнита. Предположим, что служба httpd.service активирована в рамках systemd. Теперь деактивируем службу system.slice с помощью следующей команды:

Между прочим, деактивация данного юнита не является блестящей идеей. Теоретически она может привести к нарушению работы каждой запущенной средствами systemd службы! Хотя в нашем случае можно не обращать на это никакого внимания. Хотя юнит httpd.service и зависит от юнита system.slice , деактивация последнего не приведет к какому-либо эффекту. Ведь systemd отслеживает зависимости юнита httpd.service и запустит юнит system.slice в любом случае.

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

Маскировка юнитов: третий уровень

Вы можете вспомнить о том, что systemd использует несколько различных директорий для хранения файлов с информацией о юнитах. Если вы не помните подробностей о расположении этих директорий, обратитесь к предыдущей статье серии о юнит-файлах для того, чтобы освежить память. Для записи информации о маскировке юнитов systemd использует локальные файлы конфигурации системы в директории /etc/systemd . Для этого создается файл, который является символьной ссылкой, указывающей на файл устройства /dev/null , хорошо известный в мире UNIX и Linux и используемый для передачи данных «вникуда». Таким образом, к примеру, при маскировке юнита httpd.service , будет создана следующая символьная ссылка:

Обратите внимание на то, что аналогичного эффекта можно достичь, выполнив следующую команду:

Теперь попытайтесь запустить веб-сервер вручную:

Вы увидите следующее сообщение об ошибке:

Это третий уровень «ограничения работоспособности» системной службы в рамках systemd. Если вы загрузите систему с замаскированным юнитом, он не будет запущен даже для удовлетворения зависимостей. По этой причине механизм маскировки юнитов является достаточно мощным. Но, как и при использовании всех других мощных механизмов, вы должны проявлять осторожность при работе с ним. Если вы замаскируете важный юнит (такой, как упомянутый ранее system.slice ), вы сделаете невозможной корректную загрузку вашей системы. Для демаскировки юнита следует использовать следующую команду:

Надеюсь, теперь вы можете еще лучше оценить всю мощь и гибкость механизмов systemd для работы с юнитами и разрешения зависимостей между ними. Для ознакомления с дополнительной информацией о механизме маскировки юнитов рекомендую обратиться к соответствующей статье из серии «systemd для системных администраторов». До встречи в следующей статье серии!

На нашем сайте вы можете прочитать большую серию переводов, посвященных системе инициализации systemd:

• Paul W. Frields, перевод: А.Панин, «systemd: работа с системным журналом» В комплекте поставки systemd содержится большое количество программных компонентов, которые выполняют различные функции помимо запуска системы и управления системными службами. Одним из таких программных компонентов является демон journald, который осуществляет запись информации о состоянии вашей системы, а также запущенных в ней служб в системный журнал. Навыки работы с утилитой для просмотра системного журнала облегчат процесс поиска информации о системе и ее отладки в случае необходимости.
• Jon Stanley, перевод: А.Панин, «systemd: преобразование сценариев sysvinit для работы с systemd» В данной статье рассматривается методика преобразования устаревших сценариев инициализации, которые вы могли модифицировать в соответствии со своими потребностями, для работы с systemd.
• Bryan Sutherland, перевод: А.Панин, «systemd: основные приемы работы с юнит-файлами» Система инициализации systemd разделена на множество программных компонентов, что значительно упрощает процедуру управления компонентами вашей системы. systemd использует юнит-файлы для конфигурации и управления системными ресурсами, такими, как процессы и ваша файловая система. Благодаря этим файлам вы можете использовать systemd для конфигурации вашей системы в соответствии с вашими пожеланиями.
• Ryan Lerch, перевод: А.Панин, «systemd: что такое система инициализации?» systemd является набором инструментов для выполнения широкого спектра системных задач, включая инициализацию системы, а также для управления и отслеживания состояния системных служб и демонов как в процессе загрузки системы, так и в процессе ее работы.
• Carla Schroder, перевод: Н.Ромоданов, «Управление сервисами в Linux с systemd» Вы уже читали все о systemd, новом демоне Linux init. Вы знаете, что он делает, и почему. Теперь пришло время окунуться глубже и узнать, как он себя ведет — или, по крайней мере, как запускает, останавливает и выдает информацию о сервисах.
• Carla Schroder, перевод: Н.Ромоданов, «Знакомимся с уровнями запуска Systemd и командами управления сервисами» В прошлом у нас были статические уровни запуска. Вместо уровней запуска, systemd позволяет создавать различные состояния, предоставляя вам гибкий механизм создания различных конфигураций загрузки.
• Carla Schroder, перевод: Н.Ромоданов, «Изучаем и используем Systemd» Ценность systemd является спорной по нескольким причинам: он заменяет то, что, как думают многие пользователи Linux, заменять не требуется, и все гримасы разработчиков systemd не завоевывают сердца и умы.
• Carla Schroder, перевод: Н.Ромоданов, «Проходим еще раз, еще один Linux Init: введение в systemd» В течение очень многих лет в системе Linux для управления запуском системы хватало механизма sysvinit. Затем появились две новых системы инициализации Linux: Ubuntu’s Upstart, впервые выпущенная в 2006 году, и systemd, появившаяся в 2009 году. Что же это за штуковина systemd, и какие преимущества она даст нам, простым пользователям Linux? Н.Ромоданов перевел 4 статьи о systemd, первую из которых вы можете прочесть сегодня.

Источник

Почему некоторые системные сервисы находятся в «маскированном» состоянии?

Когда я запускаю команду sudo systemctl list-unit-files (я думаю, что sudo является необязательным), я получаю вывод, который показывает все службы и их состояние.

Вот фрагмент из моей машины:

Интересно, почему некоторые сервисы находятся в «замаскированном» состоянии. Я думаю, что это означает, что «это лучше, чем« отключение », потому что служба не может быть запущена ни вручную, ни systemd».

Как я могу получить больше информации о состоянии единицы обслуживания?

Кто поместил подразделения в их соответствующее состояние?

Я пытался, например, sudo systemctl help dsmcad — это только вызывает documentation = . строку из файла модуля. /etc/systemd/system/dsmcad.service

Примечание: здесь я точно знаю , что такое сервис dsmcad и что он делает, я сам его установил. Меня больше интересует общее решение.

mask это более сильная версия disable . При использовании disable всех символических ссылок указанный файл модуля удаляется. При использовании mask единиц будет связано с /dev/null . Это будет отображаться, если вы проверите, например, с помощью systemctl status halt.service . Преимущество mask состоит в том, чтобы предотвратить любой вид активации, даже ручной.

Внимание: systemctl list-unit-files перечисляет состояние файлов модуля (статическое, включено, отключено, замаскировано, косвенно) и не имеет никакого отношения к состоянию службы. Чтобы посмотреть на услуги использования systemctl list-units .

hostname.service маскируется как избыточный, потому что systemd устанавливает имя хоста (из / etc / hostname) очень рано при запуске.

Этот параметр предоставляется пакетом Debian systemd.

Точно так же Debian теперь может работать без сценария оболочки для halt системы, вместо этого он обрабатывается systemd-shutdown (исходный код здесь ).

Если служба была замаскирована вручную, маска будет установлена /etc/systemd/system вместо нее .

Поскольку вы запрашиваете информацию о замаскированном состоянии, важно упомянуть, что в службе можно наблюдать, что после ее запуска изменения в ее определениях перезагружаются (systemctl daemon-reload) и новое состояние НЕ подходит . Одним из простых примеров для понимания является следующий сценарий:

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

Замечание: я не уверен, что это происходит нарочно или это простая ошибка (опция по умолчанию), но это может быть интересная информация, чтобы поделиться

Источник

Service Masking in Linux!

Oct 8, 2019 · 1 min read

What is masked service?

mask is a stronger version of disable . Using disable all symlinks of the specified unit file are removed.
If using mask the units will be linked to /dev/null. The advantage of mask is to prevent any kind of activation, even manual.
This will be displayed if you check e.g. by systemctl status service_name.

systemctl list-unit-files is listing the state of the unit files (static, enabled, disabled, masked, indirect) , you can list all services which are masked, enabled or disabled.

If you want to list all masked service use below commands:

systemctl list-unit-files | grep masked

Why I should mask a service ?

We sh o uld mask a service, if we want to prevent any kind of activation, even manual. e.g. If we don’t want to apply firewall rules at all then we can mask the firewalld service.

That’s nice.. how to unmask

We can manage masking and unmasking using systemctl command in linux. We can use below command to unmask and start a service.

“systemctl start service_name”

Basically Masking is good way to prevent to accidental start of a service, we can unmask it, when required. This will help us in securing and optimising OS resources.

Источник

Как исправить ошибку “failed to start hostname.service unit hostname.service is masked” в Linux

Главное меню » Linux » Как исправить ошибку “failed to start hostname.service unit hostname.service is masked” в Linux

Причины ошибки

Системное имя хоста хранится в двух основных файлах в Linux. Первый файл – это файл «/etc/hostname», а второй файл – это файл «/etc/hosts». Первый состоит только из имени хоста вашей системы, тогда как последний содержит отображение имени хоста на определенный IP-адрес. Ошибка «failed to start hostname.service unit hostname.service is masked» возникает, когда содержимое этих двух файлов не соответствует, т. e. Имя хоста, упомянутое в одном из этих файлов, отличается от имени хоста в другом файле. Из-за этого несоответствия между содержимым файлов «/etc/hostname» и «/etc/hosts» ваша система не сможет запустить hostname.service, и возникнет ошибка.

Как исправить ошибку

Самый простой способ устранить эту ошибку в Linux – убедиться, что имя хоста, указанное в обоих файлах, одинаково. Для этого вам нужно будет проверить содержимое обоих этих файлов. Вы можете получить доступ к файлу «/etc/hostname», выполнив следующую команду в терминале Linux:

Доступ к файлу «/etc/hosts» можно получить с помощью следующей команды:

Убедившись, что имя хоста в ваших соответствующих файлах точно такое же, вы можете попробовать перезапустить hostname.service еще раз. На этот раз он не должен отображать ошибку.

Вывод

В этой статье рассказывается о причинах ошибки “failed to start hostname.service unit hostname.service is masked”. Более того, он также поделился с вами простейшим методом, с помощью которого вы можете избавиться от этой ошибки в Linux.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник