В чем разница между «systemctl mask» и «systemctl disable»?
Я хочу улучшить время загрузки моего Ubuntu GNOME 16.04, отключив службы plymouth при загрузке. Я нашел два ответа о том, как это сделать на разных сайтах, а именно:
Я не могу выполнить ни одного из вышеперечисленных, если я не знаю, что они делают.
Если служба есть enabled , то где-то есть символическая ссылка
в файл модуля, чаще всего где-то в
Полезно, что когда вы enable работаете с сервисом, полные пути созданной ссылки и цели будут напечатаны на стандартный вывод.
Отключение службы удаляет символическую ссылку, поэтому на файл модуля это не влияет, но служба не загружается при следующей загрузке при чтении systemd /etc/systemd/system .
Однако отключенная служба может быть загружена и будет запущена, если запущена зависящая от нее служба ; enable и disable только настраивать поведение автозапуска для блоков, и состояние легко переопределяется.
Маскируется обслуживание один блок которого файл является символической ссылкой /dev/null . Это делает «невозможным» загрузку службы, даже если это требуется другой, включенной службой.
Когда вы mask работаете с сервисом, создается символическая ссылка из /etc/systemd/system в /dev/null , оставляя исходный файл модуля в другом месте без изменений. Когда вы unmask сервис, символическая ссылка удаляется.
Однако я заметил, что эти команды не всегда соблюдаются.
Когда я пытаюсь замаскировать большинство служб, происходит сбой:
Конечно, я остановил службу первым. @Anwar предполагает, что маскирование возможно только для некритических сервисов.
Разоблачение маскированной службы, если только я не маскировал ее, также не выполняется (молча). Я полагаю, что это потому, что нигде нет файла модуля для службы, кроме как в виде символической ссылки /dev/null , на этот раз в /lib/systemd/system :
Чтобы фактически снять маску с службы x11-common, мне пришлось удалить символическую ссылку на /dev/null и sudo apt-get install —reinstall x11-common && sudo systemctl daemon-reload . Теперь, когда я запрашиваю его, systemctl status x11-common я вижу, что сервис имеет красивый зеленый кружок и загружен и активен (выход), хотя у него нет файла модуля.
Для дальнейшей ссылки эта статья о том, как использовать Systemctl, может оказаться полезной .
Источник
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) и новое состояние НЕ подходит . Одним из простых примеров для понимания является следующий сценарий:
Следовательно, замаскированное состояние может происходить из неправильных определений услуг. Следовательно, пользователь может вызвать состояние без маски, неправильно отредактировав сервис.
Замечание: я не уверен, что это происходит нарочно или это простая ошибка (опция по умолчанию), но это может быть интересная информация, чтобы поделиться
Источник
