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

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

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

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

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

systemctl start httpd.service
systemctl stop httpd.service

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

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

systemctl enable httpd.service
systemctl disable httpd.service

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

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

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

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

/etc/rc3.d/S40myservice -> /etc/init.d/myservice

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

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

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

httpd.service
•  ├─-.mount
•   ├─system.slice
•   ├─tmp.mount
•   ├─var.mount
•   └─basic.target
•     └─-.mount
•     ├─alsa-restore.service
...

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

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

systemctl disable system.slice

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

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

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

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

$ sudo systemctl mask httpd.service
Created symlink from /etc/systemd/system/httpd.service to /dev/null.

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

$ sudo ln -s /dev/null /etc/systemd/system/httpd.service

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

systemctl start httpd.service

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

Failed to start httpd.service: Unit httpd.service is masked

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

systemctl unmask httpd.service

Надеюсь, теперь вы можете еще лучше оценить всю мощь и гибкость механизмов 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, первую из которых вы можете прочесть сегодня.