Service is masked что это значит
systemd: маскировка юнитов
Оригинал: systemd: Masking units
Автор: Ashutosh Sudhakar Bhakare
Дата публикации: 18 ноября 2015 г.
Перевод: А.Панин
Дата перевода: 1 декабря 2015 г.
Добро пожаловать в серию статей о системе инициализации systemd. В опубликованной ранее статье мы обсуждали простые команды для управления службами вашей системы Fedora. В данной статье мы обсудим специализированный механизм systemd, делающий данную систему особенно мощной: механизм маскировки юнитов. Перед тем, как перейти к рассмотрению этого механизма, давайте поговорим о других уровнях «ограничения работоспособности» системной службы.
Два первых уровня «ограничения работоспособности» системной службы
Вы должны знать эти часто используемые команды systemctl :
Эти команды позволяют немедленно запустить или остановить веб-сервер (httpd) благодаря информации из соответствующего юнит-файла. Можете считать команду stop командой первого уровня «ограничения работоспособности» системной службы на основе соответствующего юнита systemd.
Также вы наверняка помните эти часто используемые команды:
Эти команды не позволяют добиться немедленного изменения состояния системной службы. Но они гарантируют то, что служба будет запущена (или не будет запущена) в процессе следующей загрузки системы. Можете считать команду disable командой второго уровня «ограничения работоспособности» системной службы на основе соответствующего юнита systemd.
Вы наверняка догадались о том, к чему я веду. Команда маскировки является командой третьего уровня «ограничения работоспособности» системной службы, которая достаточно редко используется, но является достаточно мощной. Но перед подробным рассмотрением механизма маскировки юнитов нам придется понять причину его появления: зависимости между юнитами.
Зависимости между юнитами
По сравнению с механизмами systemd такая схема запуска сценариев выглядит довольно примитивно! Не стоит забывать о том, что systemd обрабатывает зависимости юнитов. Это означает, что systemd может установить, какой юнит должен быть запущен для успешного запуска указанного юнита.
Данный граф отображает юниты, от которых зависит юнит веб-сервера. Обратите внимание на то, что данный граф является рекурсивным и это означает, что он также отображает зависимости зависимостей рассматриваемого юнита.
Давайте рассмотрим эффект, который произведет деактивация необходимого для корректного запуска службы юнита. Предположим, что служба httpd.service активирована в рамках systemd. Теперь деактивируем службу system.slice с помощью следующей команды:
Надеюсь, теперь вы начали понимать причину, по которой существует команда для маскировки юнитов. Она позволяет системному администратору принудить systemd к выполнению всех, даже нелогичных команд.
Маскировка юнитов: третий уровень
Обратите внимание на то, что аналогичного эффекта можно достичь, выполнив следующую команду:
Теперь попытайтесь запустить веб-сервер вручную:
Вы увидите следующее сообщение об ошибке:
Это третий уровень «ограничения работоспособности» системной службы в рамках systemd. Если вы загрузите систему с замаскированным юнитом, он не будет запущен даже для удовлетворения зависимостей. По этой причине механизм маскировки юнитов является достаточно мощным. Но, как и при использовании всех других мощных механизмов, вы должны проявлять осторожность при работе с ним. Если вы замаскируете важный юнит (такой, как упомянутый ранее system.slice ), вы сделаете невозможной корректную загрузку вашей системы. Для демаскировки юнита следует использовать следующую команду:
Надеюсь, теперь вы можете еще лучше оценить всю мощь и гибкость механизмов systemd для работы с юнитами и разрешения зависимостей между ними. Для ознакомления с дополнительной информацией о механизме маскировки юнитов рекомендую обратиться к соответствующей статье из серии «systemd для системных администраторов». До встречи в следующей статье серии!
Как исправить ошибку “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.
Шпаргалка по управлению сервисами CentOS 7 с systemd
Systemd – менеджер системы и сервисов в операционной системе Linux. При разработке eго стремились спроектировать обратно совместимым со скриптами инициализации SysV init и предоставить полезные функции, такие, как параллельный запуск системных сервисов во время загрузки, активацию демонов по требованию, поддержку снепшотов состояния системы и логику управления сервисами, основанную на зависимостях. В CentOS 7 systemd заменяет Upstart как систему инициализации по умолчанию.
В этой статье мы рассмотрим процесс управления сервисами в systemd для пользователя CentOS 7. Эти знания будут полезны и в других дистрибутивах, ведь systemd уже давно используется в Fedora и планируется в Ubuntu 14.10 и Debian 8. Хорошо это или нет — оставим за кадром.
В процессе чтения статьи вы можете попробовать systemd на классических VPS и облачных VPS от Infobox. Мы стремимся своевременно добавлять поддержку современных ОС, чтобы вы могли использовать последние технологии для более эффективной работы. Сама идея написания статьи родилась после очередного вопроса пользователей об использовании сервисов в CentOS 7.
Введение
Основные функции systemd в CentOS 7
Управление сервисами
В предыдущих версиях CentOS использовалась SysV или Upstart. Скрипты инициализации располагались в директории /etc/rc.d/init.d/. Такие скрипты обычно писались на Bash и позволяли администратору управлять состоянием сервисов и демонов. В CentOS 7 скрипты инициализации были заменены сервисными юнитами.
По способу использования сервисные юниты .service напоминают скрипты инициализации. Для просмотра, старта, остановки, перезагрузки, включения или выключения системных сервисов используется команда systemctl. Команды service и chkconfig по-прежнему включены в систему, но только по соображениям совместимости.
При использовании systemctl указывать расширение файла не обязательно.
Работаем с целями (targets) Systemd
Предыдущие версии CentOS с SysV init или Upstart включали предопределенный набор уровней запуска (runlevels), которые представляли специфичные режимы для операций, пронумерованные от 0 до 6. В CentOS 7 концепция уровней запуска была заменена целями systemd.
Файлы целей systemd .target предназначены для группировки вместе других юнитов systemd через цепочку зависимостей. Например юнит graphical.target, использующийся для старта графической сессии, запускает системные сервисы GNOME Display Manager (gdm.service) и Accounts Service (accounts–daemon.service) и активирует multi–user.target. В свою очередь multi–user.target запускает другие системные сервисы, такие как Network Manager (NetworkManager.service) или D-Bus (dbus.service) и активирует другие целевые юниты basic.target.
В CentOS 7 присутствуют предопределенные цели, похожие на стандартный набор уровней запуска. По соображениям совместимости они также имеют алиасы на эти цели, которые напрямую отображаются в уровнях запуска SysV.
Для определения, какой целевой юнит используется по умолчанию, полезна следующая команда: systemctl get–default.
Для изменения цели по умолчанию поможет команда systemctl set-default name.target.
Для изменения текущей цели: systemctl isolate name.target. Команда запустит целевой юнит и все его зависимости и немедленно остановит все остальные.
Выключение и перезагрузка системы
В CentOS 7 systemctl заменяет значительное количество команд управления питанием. Прежние команды сохранены для совместимости, но рекомандуется использовать systemctl:
systemctl halt – останавливает систему
systemctl poweroff – выключает систему
systemctl reboot – перезагружает систему
Управление systemd на удаленной машине
Давайте посмотрим на секцию [Unit]. Она содержит общую информацию о сервисе. Такая секция есть не только в сервис-юнитах, но и в других юнитах (например при управлении устройствами, точками монтирования и т.д.). В нашем примере мы даем описание сервиса и указываем на то, что демон должен быть запущен после Syslog.
В следующей секции [Service] непосредственно содержится информация о нашем сервисе. Используемый параметр ExecStart указывает на исполняемый файл нашего сервиса. В Type мы указываем, как сервис уведомляет systemd об окончании запуска.
Финальная секция [Install] содержит информацию о цели, в которой сервис должен стартовать. В данном случае мы говорим, что сервис должен быть запущен, когда будет активирована цель multi–user.target.
Это минимальный работающий файл сервиса systemd. Написав свой, для тестирования скопируйте его в /etc/systemd/system/имя_сервиса.service. Выполните команды systemctl daemon-reload. Systemd узнает о сервисе и вы сможете его запустить.
Дополнительная информация
Заключение
В этой статье мы научились управлять сервисами CentOS 7. Конечно, это далеко не единственная функция systemd и другие ее стороны будут рассмотрены в будущем. Сама ОС практически со времени релиза доступна на классических VPS и облачных VPS от Infobox. Попробуйте systemd прямо сейчас. Эти знания будут полезны в связи с переходом многих дистрибутивов на systemd.
Если вы обнаружили ошибку в статье, автор ее с удовольствием исправит. Пожалуйста напишите в ЛС или на почту о ней.
В случае, если вы не можете оставлять комментарии на Хабре, можно написать их в блоге Сообщества InfoboxCloud или в нашей группе в Facebook.