Service is masked что это значит

What is a masked service?

Think of masked service as a disabled one, but. Disabled services are disabled in the sense that they won’t be started at boot time but another service can request them to be started. Masked services can not be sated even if other services require them to start.

Nov 3, 2021 at 13:02

I had an issue with mysql/mariadb services stopping suddenly then becoming masked. Running

journalctl -xe 

Will generally show you ~why~ a service gets disabled/masked/won’t start/etc. Generally it’s for a very good reason.

In my case it was installing a new repository (for an unrelated service) that just happened to have a downgraded version of mariadb-server.
When I ran the apt upgrade, mariadb got downgraded and the service «masked»

In my case upgrading mariadb to the correct version fixed the issue and unmasked the service itself, just unmasking the service could have caused data corruption in the mysql dbs. so basically, don’t just blindly unmask something — figure out why.

Управление сервисами и юнитами systemd с помощью systemctl

Systemd – это система инициализации и системный менеджер, который становится новым стандартом для Linux-машин. Споры о продуктивности systemd по сравнению с традиционными системами инициализации SysV ведутся до сих пор, тем не менее, эту систему планируют внедрить большинство дистрибутивов, а многие уже сделали это.

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

Данный мануал научит вас работать с командой systemctl, главным инструментом управления системы инициализации systemd. Вы узнаете, как управлять сервисами, проверять состояние и работать с конфигурационными файлами.

Управление сервисами

Основная цель init-системы – инициализировать компоненты, которые должны запускаться после загрузки ядра Linux (традиционно они называются «пользовательскими» компонентами). Система инициализации также используется для управления сервисами и демонами сервера. Имея это в виду, начнем знакомство с systemd с простых операций управления сервисами.

В systemd целью большинства действий являются юниты – ресурсы, которыми systemd может управлять. Юниты делятся на категории по типам ресурсов, которые они представляют. Юниты определяются в так называемых юнит-файлах. Тип каждого юнита можно определить по суффиксу в конце файла.

Для задач управления сервисами предназначены юнит-файлы с суффиксом .service. Однако в большинстве случаев суффикс .service можно опустить, так как система systemd достаточно умна, чтобы без суффикса определить, что нужно делать при использовании команд управления сервисом.

Запуск и остановка сервиса

Чтобы запустить сервис systemd, используйте команду start. Если вы работаете не в сессии пользователя root, вам нужно использовать sudo, поскольку эта команда повлияет на состояние операционной системы:

sudo systemctl start application.service

Как уже говорилось ранее, systemd знает, что для команд управления сервисами нужно искать файлы *.service, поэтому эту команду можно ввести так:

sudo systemctl start application

Вышеуказанный формат можно использовать в повседневной работе, но в мануале для ясности мы будем использовать суффикс .service.

Чтобы остановить сервис, достаточно ввести команду stop:

sudo systemctl stop application.service

Перезапуск и перезагрузка

Чтобы перезапустить сервис, используйте restart:

sudo systemctl restart application.service

Если указанное приложение может перезагрузить свои конфигурационные файлы (без перезапуска), можно использовать reload:

sudo systemctl reload application.service

Если вы не знаете, может ли сервис перезагрузить свои файлы, используйте команду reload-or-restart. Она перезагрузит сервис, а если это невозможно – перезапустит его.

sudo systemctl reload-or-restart application.service

Включение и отключение сервисов

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

Для этого существует команда enable:

sudo systemctl enable application.service

Это создаст символическую ссылку на копию файла сервиса (обычно в /lib/systemd/system или /etc/systemd/system) в точке на диске, где systemd ищет файлы для автозапуска (обычно /etc/systemd/system/some_target.target.want, подробнее об этом – дальше в руководстве).

Чтобы убрать сервис из автозагрузки, нужно ввести:

sudo systemctl disable application.service

Это удалит символическую ссылку, после этого сервис перестанет запускаться автоматически.

Имейте в виду, что включение сервиса не запускает его в текущей сессии. Если вы хотите запустить сервис и включить его в автозагрузку, вам нужно запустить команды start и enable.

Проверка состояния сервиса

Чтобы проверить состояние сервиса, введите:

systemctl status application.service

Эта команда выведет состояниесервиса, иерархию групп и первые несколько строк лога.

Например, при проверке состояния сервера Nginx вы можете увидеть такой вывод:

nginx.service — A high performance web server and a reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
Main PID: 495 (nginx)
CGroup: /system.slice/nginx.service
├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
└─496 nginx: worker process
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server.
Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.

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

Существуют также методы проверки конкретных состояний. Например, чтобы проверить, активен ли данный юнит (запущен ли он), вы можете использовать команду is-active:

systemctl is-active application.service

Это отобразит текущее состояние юнита, обычно это active или inactive. Код завершения будет «0», если юнит активен, что упрощает процесс анализа.

Чтобы узнать, включен ли юнит, вы можете использовать команду is-enabled:

systemctl is-enabled application.service

Эта команда сообщит, включен ли сервис, и снова определит код завершения как «0» или «1» в зависимости от результата.

Третья команда позволяет определить, находится ли юнит в состоянии сбоя. Это указывает на то, что возникла проблема с запуском рассматриваемого юнита:

systemctl is-failed application.service

Команда вернет active, если юнит работает правильно, и failed, если случилась ошибка. Если юнит был остановлен намеренно, команда может вернуть unknown или inactive. Код завершения «0» означает, что произошел сбой, а «1» указывает на любое другое состояние.

Обзор состояния системы

Ранее мы рассмотрели команды, необходимые для управления отдельными сервисами, но они не очень полезны для изучения текущего состояния системы. Существует несколько команд systemctl, которые предоставляют эту информацию.

Просмотр списка текущих юнитов

Чтобы запросить список текущих юнитов systemd, используйте команду list-units:

Эта команда покажет список всех юнитов, которые в настоящее время существуют в системе systemd. Результат будет выглядеть примерно так:

UNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running ATD daemon
avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack
dbus.service loaded active running D-Bus System Message Bus
dcron.service loaded active running Periodic Command Scheduler
dkms.service loaded active exited Dynamic Kernel Modules System
getty@tty1.service loaded active running Getty on tty1
. . .

В выводе есть такие столбцы:

• UNIT – название юнита systemd.
• LOAD – сообщает, была ли конфигурация юнита обработана systemd. Конфигурация загруженных юнитов хранится в памяти.
• ACTIVE – сводное состояние юнита. Обычно это позволяет быстро определить, успешно ли запущен текущий юнит.
• SUB: состояние более низкого уровня, которое сообщает подробную информацию об устройстве. Это часто зависит от типа юнита, состояния и фактического метода, в котором запущен юнит.
• DESCRIPTION – краткое описание функций юнита.

Поскольку команда list-units показывает по умолчанию только активные юниты, все вышеперечисленные записи будут показывать loaded в столбце LOAD и active в столбце ACTIVE. Такой формат является поведением systemctl по умолчанию при вызове без дополнительных команд, поэтому вы увидите то же самое, если вы вызываете systemctl без аргументов:

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

systemctl list-units —all

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

Вы можете использовать другие флаги для фильтрации результатов. Например, флаг –state= можно использовать для определения состояний LOAD, ACTIVE или SUB. Флаг –all нужно оставить, чтобы система отображала неактивные юниты:

systemctl list-units —all —state=inactive

Еще один популярный фильтр – это –type=. Он позволяет отфильтровать юниты по типу. К примеру, чтобы запросить только активные юниты, можно ввести:

systemctl list-units —type=service

Список юнит-файлов

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

Юниты являются представлениями ресурсов, о которых знает systemd. Поскольку systemd не обязательно читает все определения юнитов, она представляет только информацию о самих файлах. Вывод состоит из двух столбцов: UNIT FILE и STATE.

UNIT FILE STATE
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount static
var-lib-nfs-rpc_pipefs.mount static
org.cups.cupsd.path enabled
. . .

Обычно столбец STATE содержит значения enabled, disabled, static или masked. В этом контексте static означает, что в юнит-файле нет раздела install, который используется для включения юнита. Таким образом, эти юниты невозможно включить. Обычно это означает, что юнит выполняет одноразовое действие или используется только как зависимость другого юнита и не должен запускаться сам по себе.

Подробнее о значении masked вы узнаете далее.

Управление юнитами

Теперь вы знаете, как работать с сервисами и отображать информацию о юнитах и юнит-файлах, о которых знает systemd. Получить более конкретную информацию о юнитах можно с помощью некоторых дополнительных команд.

Отображение юнит-файла

Чтобы отобразить юнит-файл, который загрузила systemd, вы можете использовать команду cat (была добавлена в версии systemd 209). Например, чтобы увидеть юнит-файл демона планирования atd, можно ввести:

systemctl cat atd.service
[Unit] Description=ATD daemon
[Service] Type=forking
ExecStart=/usr/bin/atd
[Install] WantedBy=multi-user.target

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

Отображение зависимостей

Чтобы просмотреть дерево зависимостей юнита, используйте команду:

systemctl list-dependencies sshd.service

Она отобразит иерархию зависимостей, с которыми системе необходимо иметь дело, чтобы запустить этот юнит. Зависимости в этом контексте – это те юниты, которые требуются для работы других юнитов, которые находятся выше в иерархии.

sshd.service
├─system.slice
└─basic.target
├─microcode.service
├─rhel-autorelabel-mark.service
├─rhel-autorelabel.service
├─rhel-configure.service
├─rhel-dmesg.service
├─rhel-loadmodules.service
├─paths.target
├─slices.target
. . .

Рекурсивные зависимости отображаются только для юнитов .target, которые указывают состояния системы. Чтобы рекурсивно перечислить все зависимости, добавьте флаг –all.

Чтобы показать обратные зависимости (юниты, зависящие от указанного элемента), вы можете добавить в команду флаг –reverse. Также полезными являются флаги –before и –after, они отображают юниты, которые зависят от указанного юнита и запускаются до или после него.

Проверка свойств юнита

Чтобы увидеть низкоуровневые свойства юнита, вы можете использовать команду show. Это отобразит список свойств указанного юнита в формате ключ=значение.

systemctl show sshd.service
Id=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=OpenSSH server daemon
. . .

Чтобы отобразить одно из свойтсв, передайте флаг –р и укажите имя свойства. К примеру, чтобы увидеть конфликты юнита sshd.service, нужно ввести:

systemctl show sshd.service -p Conflicts
Conflicts=shutdown.target

Маскировка юнитов

Systemd может блокировать юнит (автоматически или вручную), создавая симлинк на /dev/null. Это называется маскировкой юнитов и выполняется командой mask:

sudo systemctl mask nginx.service

Теперь сервис Nginx не будет запускаться автоматически или вручную до тех пор, пока включена маскировка.

Если вы проверите list-unit-files, вы увидите, что сервис отмечен как masked:

systemctl list-unit-files
. . .
kmod-static-nodes.service static
ldconfig.service static
mandb.service static
messagebus.service static
nginx.service masked
quotaon.service static
rc-local.service static
rdisc.service disabled
rescue.service static
. . .

Если вы попробуете запустить сервис, вы получите такое сообщение:

sudo systemctl start nginx.service
Failed to start nginx.service: Unit nginx.service is masked.

Чтобы раскрыть (разблокировать) юнит и сделать его доступным, используйте unmask:

sudo systemctl unmask nginx.service

Это вернет сервис в его прежнее состояние.

Редактирование юнит-файлов

Хотя конкретный формат юнит-файлов не рассматривается в данном руководстве, systemctl предоставляет встроенные механизмы для редактирования и изменения юнит-файлов. Эта функциональность была добавлена в systemd версии 218.

Команда edit по умолчанию открывает сниппет юнит-файла:

sudo systemctl edit nginx.service

Это будет пустой файл, который можно использовать для переопределения или добавления директив в определение юнита. В каталоге /etc/systemd/system будет создан каталог, который содержит имя устройства с суффиксом .d. Например, для nginx.service будет создан каталог nginx.service.d.

Внутри этого каталога будет создан сниппет с именем override.conf. Когда юнит загружается, systemd объединит в памяти сниппет для переопределения с остальным юнит-файлом. Директивы сниппета будут иметь приоритет над теми, что указаны в исходном юнит-файле.

Если вы хотите отредактировать весь юнит-файл вместо создания сниппета, вы можете передать флаг –full:

sudo systemctl edit —full nginx.service

Это загрузит текущий юнит-файл в редактор, где его можно будет изменить. Когда редактор закроется, измененный файл будет записан в /etc/systemd/system и будет иметь приоритет над определением юнита системы (обычно он находится где-то в /lib/systemd/system).

Чтобы удалить все сделанные вами дополнения, удалите каталог конфигурации .d или измененный файл сервиса из /etc/systemd/system. Например, чтобы удалить сниппет, можно ввести:

sudo rm -r /etc/systemd/system/nginx.service.d

Чтобы удалить полный отредактированный файл, введите:

sudo rm /etc/systemd/system/nginx.service

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

sudo systemctl daemon-reload

Изменение уровней запуска

Цели – это специальные юнит-файлы, которые описывают уровни системы или точки синхронизации. Как и другие юниты, файлы целей можно определить по суффиксу. В данном случае используется суффикс .target. Сами по себе цели ничего не делают, вместо этого они используются для группировки других юнитов.

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

Например, есть цель swap.target, которая используется для того, что чтобы сообщить, что swap готов к использованию. Юниты, которые являются частью этого процесса, могут синхронизироваться с этой целью при помощи директив WantedBy= или RequiredBy=. Юниты, которым нужен своп, могут указывать это условие через спецификации Wants=, Requires= или After=.

Проверка и настройка целей по умолчанию

Процесс systemd имеет цель по умолчанию, которую он использует при загрузке системы. Обеспечение ряда зависимостей этой единственной цели приводит систему в желаемое состояние. Чтобы найти цель по умолчанию, введите:

systemctl get-default
multi-user.target

Если вы хотите установить другую цель по умолчанию, вы можете использовать set-default. Например, если у вас установлен графический рабочий стол и вы хотите, чтобы система загружала его по умолчанию, вы можете соответствующим образом изменить цель:

sudo systemctl set-default graphical.target

Список доступных целей

Просмотреть список доступных целей можно с помощью команды:

systemctl list-unit-files —type=target

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

systemctl list-units —type=target

Изоляция целей

Можно запустить все юниты, связанные с целью, и остановить все юниты, которые не являются частью дерева зависимостей. Для этого используется команда isolate. Она похожа на изменение уровня запуска в других системах инициализации.

Например, если вы работаете в графической среде, где активна цель graphical.target, вы можете отключить графическую систему и перевести систему в состояние многопользовательской командной строки, изолировав multi-user.target. Поскольку graphical.target зависит от multi-user.target, но не наоборот, все графические юниты будут остановлены.

Вы можете взглянуть на зависимости изолируемой цели, прежде чем выполнять эту процедуру, чтобы убедиться, что вы не останавливаете жизненно важные сервисы:

systemctl list-dependencies multi-user.target

Если вас все устраивает, можете изолировать цель:

sudo systemctl isolate multi-user.target

Сокращения

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

К примеру, чтобы перевести систему в режим отладки, можно ввести просто rescue вместо isolate rescue.target:

sudo systemctl rescue

Это обеспечит дополнительную функциональность – оповестит всех пользователей системы о событии.

Чтобы остановить систему, вы можете использовать команду halt:

sudo systemctl halt

Чтобы начать полное завершение работы, вы можете использовать команду poweroff:

sudo systemctl poweroff

Перезапуск можно начать с помощью команды reboot:

sudo systemctl reboot

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

Например, чтобы перезагрузить систему, вы можете ввести просто:

Заключение

Теперь вы знакомы с основными механизмами systemctl и знаете, как управлять системой инициализации с помощью этого инструмента.

Хотя systemctl работает в основном с процессом systemd, в системе systemd есть другие компоненты, которые контролируются другими утилитами. К примеру, для управления логированием и пользовательскими сеансами используются отдельные демоны и утилиты (journald/journalctl и logind/loginctl соответственно).

Это нормально что systemctl unmask не сообщат результат выполнения?

И что systemctl unmask может замаскировать несуществующий сервис?

$ sudo systemctl unmask param-pam-pam $ sudo systemctl unmask param-pam-pam $ sudo systemctl unmask param-pam-pam $ sudo systemctl mask param-pam-pam Created symlink from /etc/systemd/system/param-pam-pam.service to /dev/null. $ sudo systemctl start param-pam-pam Failed to start param-pam-pam.service: Unit param-pam-pam.service is masked. 

ya-betmen ★★★★★
19.04.17 23:21:24 MSK

А что echo $? после unmask несуществующего сервиса?

leave ★★★★★
( 19.04.17 23:29:32 MSK )
Ответ на: комментарий от leave 19.04.17 23:29:32 MSK

Похоже ему плевать

ya-betmen ★★★★★
( 19.04.17 23:32:13 MSK ) автор топика
Последнее исправление: ya-betmen 19.04.17 23:32:45 MSK (всего исправлений: 1)

Ответ на: комментарий от ya-betmen 19.04.17 23:32:13 MSK

Кастуй проповедников (интелэфыкс, альфа), они объяснят. Но предварительно хоть версию скажи, может это древний баг.

leave ★★★★★
( 19.04.17 23:36:06 MSK )

Ты что-то не так делаешь.

$ sudo systemctl mask yandex-disk@radjah.service Created symlink from /etc/systemd/system/yandex-disk@radjah.service to /dev/null. $ sudo systemctl unmask yandex-disk@radjah.service Removed symlink /etc/systemd/system/yandex-disk@radjah.service. 

Ну и вполне логично, что unmask 0 выдаёт. Размаскировать незамаскированный сервис, а ошибки уже start/stop/enable/disable рисовать должны. Они же юнит прочитать не смогут.

Radjah ★★★★★
( 19.04.17 23:37:09 MSK )
Последнее исправление: Radjah 19.04.17 23:46:02 MSK (всего исправлений: 1)

Ответ на: комментарий от leave 19.04.17 23:36:06 MSK

Та хз я тут сканер настраивал, воткнулся в замаскированный saned. Сходу не нагуглил.

Нашел про mask https://bugzilla.redhat.com/show_bug.cgi?id=842060. Правда фикс там только для того же самого mask. Про unmask ничего не нашел.

ya-betmen ★★★★★
( 19.04.17 23:41:17 MSK ) автор топика
Последнее исправление: ya-betmen 19.04.17 23:47:35 MSK (всего исправлений: 1)

Ответ на: комментарий от ya-betmen 19.04.17 23:41:17 MSK

cast intelfx

Куда багу заводить, на гитхаб? Или уже есть такая просто я не нагуглил?

ya-betmen ★★★★★
( 20.04.17 08:34:48 MSK ) автор топика
Ответ на: комментарий от Radjah 19.04.17 23:37:09 MSK

Но когда я маскирую несуществующий сервис, то старт выдает ошибку что сервис замаскирован а не то что он не существует.

ya-betmen ★★★★★
( 20.04.17 08:37:23 MSK ) автор топика
Ответ на: комментарий от ya-betmen 20.04.17 08:37:23 MSK

Скорее всего сначала в /etc/systemd/system лезет и натыкается на симлинк в /dev/null . Юнит же может где угодно лежать, а в /etc/systemd/system на него может быть симлинк.

По крайней мере, когда делаю systemctl enable /полный/путь/до/юнита.service , то сначала делается симлинк в /etc/systemd/system , потом уже раскидываются по /etc/systemd/system/*.wants .

Radjah ★★★★★
( 20.04.17 08:57:23 MSK )

Это нормально что systemctl unmask не сообщат результат выполнения?

$ sudo systemctl mask wtf.service Unit wtf.service does not exist, proceeding anyway. Created symlink /etc/systemd/system/wtf.service → /dev/null. $ sudo systemctl unmask wtf.service Removed /etc/systemd/system/wtf.service. $ sudo systemctl mask systemd-networkd.service Created symlink /etc/systemd/system/systemd-networkd.service → /dev/null. $ sudo systemctl unmask systemd-networkd.service Removed /etc/systemd/system/systemd-networkd.service. 

Да вроде сообщает. Что не так?

intelfx ★★★★★
( 20.04.17 09:15:15 MSK )
Последнее исправление: intelfx 20.04.17 09:16:10 MSK (всего исправлений: 1)

Ответ на: комментарий от ya-betmen 20.04.17 08:37:23 MSK

Но когда я маскирую несуществующий сервис, то старт выдает ошибку что сервис замаскирован а не то что он не существует.

Потому что, внезапно, после маскировки он начинает существовать.

intelfx ★★★★★
( 20.04.17 09:15:48 MSK )
Ответ на: комментарий от intelfx 20.04.17 09:15:15 MSK

Unit wtf.service does not exist, proceeding anyway. Created symlink /etc/systemd/system/wtf.service → /dev/null.

Какая версия? У меня 229 и молчит.

Но с mask понятно, это фиксили. Что у тебя отвечает unmask на несуществующием сервисе?

ya-betmen ★★★★★
( 20.04.17 09:20:46 MSK ) автор топика
Последнее исправление: ya-betmen 20.04.17 09:22:34 MSK (всего исправлений: 1)

Ответ на: комментарий от ya-betmen 20.04.17 09:20:46 MSK

Что значит «молчит», когда у тебя в заголовке треда свидетельство обратного?

Что у тебя отвечает unmask на несуществующием сервисе?

Я всё написал выше. Что он, по-твоему, должен отвечать?

intelfx ★★★★★
( 20.04.17 09:22:54 MSK )
Последнее исправление: intelfx 20.04.17 09:23:38 MSK (всего исправлений: 1)

Поклёп хейтеров

[root@work ~]# systemctl unmask param-pam-pam; echo $?; systemctl --version Failed to execute operation: Access denied 1 systemd 219 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN 

d_a ★★★★★
( 20.04.17 09:26:10 MSK )
Ответ на: Поклёп хейтеров от d_a 20.04.17 09:26:10 MSK

selinux отключи и повтори.

Deleted
( 20.04.17 09:27:24 MSK )
Ответ на: комментарий от Deleted 20.04.17 09:27:24 MSK

[root@work ~]# setenforce 0; systemctl unmask param-pam-pam; echo $? 0 

Ладно, не знаю отчего так, я вам должен манёвр 1 шт.

d_a ★★★★★
( 20.04.17 09:31:47 MSK )
Ответ на: комментарий от intelfx 20.04.17 09:22:54 MSK

Что значит «молчит», когда у тебя в заголовке треда свидетельство обратного?

Я всё написал выше. Что он, по-твоему, должен отвечать?

Выше ты сначала создал сервис а потом его размаскировал ибо как ты сам сказал Потому что, внезапно, после маскировки он начинает существовать. . Я же говорил о размаскировании несуществующего сервиса. У меня никаких варнингов нету.

Я вот и спрашиваю есть ли такая про unmask т.к. в коммите проверки я не нашел.

ya-betmen ★★★★★
( 20.04.17 09:49:16 MSK ) автор топика
Последнее исправление: ya-betmen 20.04.17 09:55:08 MSK (всего исправлений: 2)

Ответ на: комментарий от ya-betmen 20.04.17 09:49:16 MSK

Я же говорил о размаскировании несуществующего сервиса.

$ sudo systemctl unmask nonexisting-and-nonmasked.service Unit nonexisting-and-nonmasked.service does not exist, proceeding anyway. 

Варнинг добавили, но rc=0, как и во всех остальных случаях. У тебя, как я понимаю, именно к этому претензия?

intelfx ★★★★★
( 20.04.17 10:06:20 MSK )
Ответ на: комментарий от intelfx 20.04.17 10:06:20 MSK

К отсутствию варнинга претензия. Версию скажи свою, походу unmask тоже пофиксили и отдельная бага не нужна.

ya-betmen ★★★★★
( 20.04.17 10:14:23 MSK ) автор топика
Последнее исправление: ya-betmen 20.04.17 10:15:10 MSK (всего исправлений: 1)

Как использовать Systemctl для управления службами Systemd

Systemd — это менеджер управления службами в Linux. При загрузке системы он запускает другие демоны, при этом делает это параллельно, что значительно ускоряет загрузку системы. Но зона ответственности менеджера systemd не ограничивается только запуском: каждый сервис запускается с собственным идентификатором, поэтому вы сможете вручную отслеживать статусы всех запущенных процессов, а при остановке одного из них systemd также остановит и дочерние.

Кроме быстродействия и возможности взаимодействовать с процессами напрямую, systemd также предоставляет информацию о сервисах, которую собирает из разных источников. Это достигается благодаря встроенной системе журналирования journald. Всю диагностическую информацию о работе сервиса вы можете увидеть благодаря journald — сообщения ядра, системные сообщения syslog, STDOUT и STDERR агрегируются в одном месте для того, чтобы пользователь мог быстро просмотреть информацию.

В этой статье мы рассмотрим управление системой инициализации systemd c помощью команды systemctl . Разберемся в том, как запускать и останавливать службы, проверять статус и работать с конфигурационными файлами.

Установка

Менеджер systemd заменил традиционную подсистему init в 2010-х годах и с тех пор стал системой инициализации по умолчанию во многих дистрибутивах Linux. Во всех linux-дистрибутивах, которые вы закажете на timeweb.cloud , systemd предустановлен.

Но в некоторых ОС при использовании команды systemctl вы всё ещё можете встретить ошибку systemctl is not installed . Это значит, что на вашей машине установлена другая система инициализации. Но сменить её на systemd несложно. Первое, что нужно сделать — установить пакет systemd :

sudo apt-get install systemd

Затем в настройках ядра Linux нужно прописать использование systemd. Для этого откроем файл с настройками загрузчика GRUB:

sudo nano /etc/default/grub

и добавим в настройку GRUB_CMDLINE_LINUX_DEFAULT опцию init=/lib/systemd/systemd .

Чтобы применить изменения нужно сгенерировать новый файл конфигурации grub и перезапустить систему:

sudo update-grub
sudo shutdown -r now

Модули systemd

При управлении процессами менеджер systemd оперирует так называемыми модулями или юнитами. По сути, юнит — текстовое описание сервиса, в котором перечислены операции для выполнения до и после запуска службы.

Все модули можно найти в трёх каталогах:

• /usr/lib/systemd/system — юниты сервисов, установленных с помощью менеджера пакетов. Самый простой пример — веб-серверы: Apache или Nginx.
• /run/systemd/system — юниты, которые создаются в процессе работы системы.
• /etc/systemd/system — юниты, которые создаёт администратор системы.

Список всех запущенных модулей можно посмотреть, использовуя команду systemctl . В терминале вы увидите таблицу со статусом каждой службы. Разберём, что означает каждый из столбцов:

1. UNIT . Название модуля
2. LOAD . Статус загрузки конфигурации, если успешно — loaded.
3. ACTIVE . Статус службы. Один из следующих: active, inactive, running, exited, dead, loaded, not-found, plugged, mounted, waiting, listening.
4. SUB . Детальная информация о юните.
5. DESCRIPTION . Краткое описание модуля — за что он отвечает.

Чтобы увидеть все модули, независимо от того, запущены они или нет, воспользуйтесь командой systemctl list-units —all . Вы увидите все модули, которые когда-либо загружал или пытался загрузить диспетчер systemd . Для отображения конкретных записей используйте флаг —state . Так, например, для того, чтобы увидеть все неактивные юниты, нужно использовать:

sudo systemctl list-units --all --state=inactive

Типы юнитов

Модули делятся на категории по типу. Тип каждого модуля можно узнать из названия файла — он указан через точку. Все типы модулей:

1. .service — описывает, как управлять службой и приложением
2. .socket — описывает сетевой буфер, который используется для активации сокета
3. .device — описывает устройство как необходимое для управления systemd
4. .mount — определяет точку монтирования в системе
5. .automount — настраивает автоматическую установку точки монтирования
6. .swap — описывает пространство подкачки в системе
7. .target — обеспечивает синхронизацию устройств при загрузке системы
8. .path — определяет путь, который используется для активации
9. .timer — определяет задержку или активацию по плану
10. .snapshot — делает снимок системы для последующего восстановления
11. .slice — ограничивает узлы группы управления
12. .scope — systemd создаёт эти модули автоматически, пользуясь информацией из интерфейса шины

Структура юнита

Каждый модуль представляет собой текстовый файл, который разделён на обязательные секции и переменные. Разберём на примере модуля sshd:

[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.target
Wants=sshd-keygen.target

[Service]
Type=notify
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

Unit

Это первая обязательная секция. В ней описаны правила взаимодействия с другими службами и указаны метаданные — описание и документация. Подробнее:

• Description — описание модуля.
• Documentation — страница руководства man.
• After — после каких демонов и событий нужно запускать модуль. Например, модули веб-серверов запускаются только после сетевых интерфейсов.
• Requires — сервисы, необходимые для работы юнита
• Wants — сервисы, которые желательно запустить перед стартом модуля

Service

В этой секции необходимо указать, какими командами запускать службу:

• Type — как запускается демон? По умолчанию — simple, то есть служба просто запускается. Notify это примерно то же самое, но в таком случае процесс сообщит диспетчеру, что он готов к работе. Есть также типы forking (после запуска демона родительский процесс завершается) и one-shot (выполняется один раз).
• PIDFile — ссылка на основной процесс
• WorkingDirectory — текущая рабочая директория для запуска команд
• User — пользователь для запуска сервиса
• Group — группа для запуска сервиса
• ExecStart — команда для запуска сервиса
• ExecStop — команда для остановки сервиса
• TimeoutSec — время, которое служба ожидает остановки или старта
• Restart — настройки перезапуска

Install

В этой секции нужно указать, на каком уровне загрузки системы нужно запускать сервис. Переменная WantedBy сообщает, как включится устройство, в качестве параметра указываются специальные файлы целей. Они служат для того, чтобы привести систему в разные состояния.

Список доступных целей вы можете получить, выполнив команду

sudo systemctl list-unit-files --type=target

Редактирование модулей

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

Если нужно отредактировать файл модуля целиком, а не добавлять новые директивы, нужно использовать флаг —full :

sudo systemctl edit --full apache2.service

Перед вами откроется редактор, в котором вы можете править настройки юнита.

По умолчанию файлы переопределения хранятся в /etc/systemd/system/ , в каталоге который называется так же, как модуль, но с суффиксом .d . Например, в случае apache2 это будет директория /etc/systemd/system/apache2.service.d/ .

Если вы редактируете конфигурацию напрямую с использованием флага —full , нужный файл находится в каталоге /etc/systemd/system/ и называется так же, как модуль.

Для того, чтобы удалить переопределения, которые вы добавили, просто удалите каталог с суффиксом .d . Если нужно восстановить настройки по умолчанию, удалите весь файл модуля. В случае с apache2 это:

sudo rm -r /etc/systemd/system/apache2.service.d

sudo rm /etc/systemd/system/apache2.service

После этого нужно перезагрузить процесс systemd:

sudo systemctl daemon-reload

Создание модуля

Вы также можете создать собственный модуль systemd. Это нужно когда вы, например, написали какой-то скрипт и хотите работать с ним с помощью системного менеджера и добавить в автозагрузку.

Разберёмся на примере нашего вымышленного нового модуля, который проверяет состояние виртуальных серверов, заказанных на timeweb.cloud , — tmwb.service.

Сначала создадим юнит:

sudo nano /etc/systemd/system/tmwb.service

В описании укажем следующие строки:

[Unit] 
Description=Timeweb uptime checker
[Service] 
Type=simple
ExecStart=/bin/bash /var/sc/check-uptime.sh 
RemainAfterExit=yes 
[Install] 
WantedBy=multi-user.target

Теперь нужно применить изменения и запустить службу

sudo systemctl daemon-reload
sudo systemctl start tmwb.service

Проверим статус и убедимся, что всё работает корректно:

sudo systemctl status tmwb.service

Управление службами

В этой статье нас интересуют только модули, которые имеют суффикс .service, то есть службы.

Благодаря утилите systemctl список сервисов легко получить:

systemctl list-units --type=service

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

Запуск и остановка служб

Чтобы запустить службу используйте команду start . Например, для запуска apache2 выполним:

sudo systemctl start apache2.sevice

sudo systemctl start apache2

Для установки службы нужно использовать команду stop . На примере apache2:

sudo systemctl stop apache2.service

Перезапуск и перезагрузка

Для того, чтобы перезапустить службу, используйте команду restart . Например, мы внесли изменения в конфигурацию веб-сервера и теперь нам нужно перезапустить apache2, нужно выполнить:

sudo systemctl restart apache2.service

Некоторые приложения поддерживают перезагрузку файлов конфигурации без перезапуска всей службы. В таком случае вы можете использовать команду reload. Например, если вы работаете c nginx в качестве веб-сервера, после изменения конфигурационных файлов можно выполнить reload :

sudo systemctl reload nginx.service

Но если вы не уверены, умеет ли служба перезагружать конфигурацию, воспользуйтесь командой reload-or-restart . В таком случае systemd перезагрузит конфигурацию или всю службу:

sudo systemctl reload-or-restart apache2.service

Включение и отключение

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

Чтобы включить автозагрузку приложения, воспользуйтесь командой enable . После этого systemd создаст символическую ссылку из служебного файла — /etc/systemd/system — в место, где диспетчер ищет приложения для автозапуска.

sudo systemctl enable apache2.service 

Чтобы отключить автозапуск, используйте disable . При этом символическая ссылка будет удалена.

sudo systemctl disable apache2.service

Обратите внимание, что ни включение, ни отключение автозагрузки приложения не повлияют на работу службы в текущем сеансе.

Проверка статуса

Чтобы проверить статус службы в системе, нужно использовать команду status .

Например, команда sudo systemctl status apache2.service отобразит статус, процессы в иерархии контрольных групп и фрагмент журнала.

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

Помимо развёрнутого отчёта о статусе службы диспетчер systemd также предоставляет методы для проверки конкретных статусов. Это позволяет обернуть множество проверок в скрипты и проще работать с результатом.

• is-active. Проверяет, активен ли модуль. Возвращает active или inactive.
• is-enabled. Проверяет, включена ли автозагрузка службы. Возвращает enabled или disabled.
• is-failed. Проверяет, находится ли юнит в работе. Возвращает active, если всё работает корректно, failed — если ошибка. При этом вы можете получить также unknown или inactive, если служба была остановлена вручную.

Управление модулями

С помощью команды systemctl мы также можем получить более конкретную информацию о юнитах systemd. Чтобы прочитать файл модуля, нужно использовать команду cat . Проверим, на примере службы sshd:

sudo systemctl cat sshd.service

В результате увидим файл модуля, с которым работает systemd.

Зависимости

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

Вы также можете проверить все модули, которые зависят от указанного юнита, с помощью флага —reverse .

Свойства

Для того, чтобы просмотреть свойства на более низком уровне, чем это предоставляет cat , нужно выполнить команду show . Список свойств юнита будет выведен в формате ключ — значение.

sudo systemctl show apache2.service

Если нужно показать только одно свойство, передайте его название с флагом -p . Команда sudo systemctl show apache2.service -p Description отобразит сообщение Description=The Apache HTTP Server .

Маскировка модулей

Помимо простого отключения автозагрузки приложения systemd позволяет полностью удалить возможность включать модуль — это называется маскировкой юнита. Её можно выполнить с помощью команды:

sudo systemctl mask apache2.service

После этого при попытке запустить службу вы увидите сообщение об ошибке: Failed to start apache2.service: Unit apache2.service is masked .

Чтобы снять маскировку и снова сделать модуль доступным для включения, воспользуйтесь командой unmask :

sudo systemctl unmask apache2.service

Настройка системы с помощью целей

Цели — специальные файлы модулей, которые описывают состояние системы. Они определяются по суффиксу .target . В основном эти файлы используются для группировки других юнитов. Например, в системе существует цель swap.target , которая указывает, что файл подкачки готов к использованию. Модули, которым нужен этот файл могут указывать его в своей спецификации.

Диспетчер systemd позволяет изолировать цели — то есть запустить все юниты, связанные с этой целью, и остановить все остальные. Чтобы случайно не остановить важные для системы процессы, сначала посмотрите на зависимости цели, которую изолируете, с помощью команды list-dependencies :

sudo systemctl list-dependencies multi-user.target

Если все перечисленные модули можно завершить, цель можно изолировать:

sudo systemctl isolate multi-user.target

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

1. systemctl rescue вводит систему в режим восстановления;
2. systemctl halt осуществляет изоляцию цели halt.target
3. systemctl poweroff готовит систему к завершению работы (то же самое, что команда poweroff)
4. systemctl reboot перезапускает систему (в точности то же самое, что команда reboot)

Заключение

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

Знание основ работы с диспетчером systemd значительно упрощает взаимодействие с системой Linux и позволяет гибко конфигурировать службы.