Глава 11. Управление компонентами systemd RHEL9

RHEL9 может быть настроен на запуск в одном из ряда состояния (носящих название целей), причём каждое проектируется для предоставления конкретного уровня функциональных возможностей операционной системы. Настраивает ту цель, к которой будет запускаться система по умолчанию на основании той цели, которая подлежит исполнению сам системный администратор. Система рабочего стола, к примеру, скорее всего, будет настроена на запуск с применением цели графического интерфейса пользователя.

Процесс с названием systemd в процессе последовательности запуска просматривает папку /etc/systemd/system на предмет поиска настроек целей по умолчанию. Выявив такую цель по умолчанию, от продолжит запуск ассоциируемых с данной целью компонентов (units) systemd с тем, чтобы данная система запускалась со всеми необходимыми процессами в рабочем состоянии.

Для тех, кто знаком с более ранними версиями RHEL, цели systemd заменили более ранние уровни исполнения (runlevels) системы.

Служба это некий процесс, как правило, исполняемый в фоновом режиме, который предоставляет определённую функциональную возможность. К примеру, служба sshd это тот фоновый процесс (также имеющий название демона), который предоставляет доступ безопасной оболочки (ssh) к данной системе. Различные цели systemd настраиваются на автоматический запуск различных коллекций служб в зависимости от той функциональности, которая будет предоставлена такой целью.

Цели и службы это типы компонентов (units) systemd, которые будут далее рассматриваться в этой главе.

Как мы уже обозначали ранее, RHEL9 может запускаться на один из нескольких уровней целей. Те цели по умолчанию, до которых будет сконфигурирован запуск данной системы, в свою очередь, диктует какие именно компоненты (units) systemd стартуют. Вот просуммированные основные цели, которые относятся конкретно к запуску и останову системы:

Дополнительно к перечисленным выше целям обычная система содержит порядка 70 прочих целей, причём многие из них выступают подчинёнными целями применяемыми упомянутыми выше целями. За сценой, к примеру, multi-user.target также запустит цель с названием basic.target, которая, в свою очередь, стартует компонент sockets.target, требующийся для взаимодействия между различными процессами. Это гарантирует, что все все службы, от которых зависит цель множества пользователей, также стартуют в процессе данного запуска.

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

# systemctl list-dependencies <target>
		

Рисунок 11-1, к примеру, отображает частичный перечень зависимостей компонентов systemd для цели графики (полный перечень содержит более 140 целей и служб, требующихся для полной функциональности системы со множеством пользователей):

Перечень предоставляется в качестве иерархического дерева, иллюстрирующего как определённые зависимости обладают своими собственными подчинёнными зависимостями. Прокручивая данный список донизу, например, вы выведаете что данная графическая цель зависит от двух целей, относящихся к сетевым файловым системам (а именно, namely nfs-client.target и remote-fs.target), причём каждая из них со своими собственными подчинёнными зависимостями служб и целей:

Обозначенные цветом точки с левой стороны каждой из записей в данном перечне указывают текущее состояния такой службы или цели следующим образом:

Чтобы найти дополнительные подробности относительно состояния компонента systemd, воспользуйтесь командой systemctl status со следующем за ней названием этого компонента таким образом:

# systemctl status systemd-machine-id-commit.service
○ systemd-machine-id-commit.service - Commit a transient machine-id on disk
     Loaded: loaded (/usr/lib/systemd/system/systemd-machine-id-commit.service; static)
     Active: inactive (dead)
  Condition: start condition failed at Thu 2023-03-30 08:41:05 EDT; 16min ago
             └─ ConditionPathIsMountPoint=/etc/machine-id was not met
       Docs: man:systemd-machine-id-commit.service(8)
		

Установленную текущей цель для системы RHEL9 можно выявить при помощи команды systemctl так:

# systemctl get-default
multi-user.target
		

В приведённом выше случае система настроена на запуск с применением по умолчанию цели со множеством пользователей. Такую настройку по умолчанию можно изменить когда угодно воспользовавшись командой systemctl с параметром set-default. Приводимый ниже образец изменяет установленную по умолчанию цели чтобы стартовать при перезапуске системы в следующий раз с графическим интерфейсом:

# systemctl set-default graphical.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/graphical.target.
		

Приводимый вывод операции изменения значения по умолчанию раскрывает те шаги, которые осуществляются командой systemctl в фоновом режиме. Текущее значение по умолчанию настраивается путём установления символической ссылки из расположенного в /etc/systemd/system файла default.target на соответствующий целевой файл, расположенный в папке /usr/lib/systemd/system (в данном случае это файл graphical.target).

Как уже упоминалось ранее, и цели и службы являются типами компонентов (units) systemd. Все имеющиеся внутри папки /usr/lib/systemd/system файлы относятся к файлам конфигурации компонентов systemd, причём каждый из них представляет собой компонент systemd. Всякий компонент, в свою очередь, относится к категории определённого типа компонентов. RHEL9 поддерживает 12 различных типов компонентов, включая те типы целей и служб, которые уже рассматривались в данной главе.

Значения типа файла компонента (unit) представляется расширением имени файла, как это обозначено в приводимой ниже Таблице 11.1:

Таблица 11-1. Типы компонентов

Тип компонента	Расширение имени файла	Описание типа
Служба	.service	Системная служба
Цель	.target	Группа компонентов systemd
Автоматическое монтирование	.automount	Точка автоматического монтирования файловой системы
Устройство	.device	Распознаваемый загружаемым ядром файл устройства
Монтирование	.mount	Точка монтирования файловой системы
Путь	.path	Файл или каталог в файловой системе
Область действия	.scope	Созданный внешним образом процесс
Срез	.slice	Группа иерархически организованных компонентов, которые управляют процессами системы
Моментальный снимок	.snapshot	Сохранённое состояние диспетчера systemd
Сокет	.socket	Сокет взаимодействия между процессами
Подкачка	.swap	Устройство подкачки или файл подкачки
Таймер	.timer	Таймер systemd

Обратите внимание, что тип компонента цели отличается от прочих типов тем, что он составляется группой компонентов systemd, таких как службы или прочие цели.

Приведённая выше команда systemctl set-default определяет значение цели, которое будет применено когда данная система стартует в следующий раз, однако не изменяет значение текущего состояния системы. Чтобы производить изменение на другу цель динамически снова воспользуйтесь командой systemctl, применяя параметр isolate, за которым следует цель назначения. Чтобы переключить свою текущую систему на её графическую цель без выполнения перезапуска, к примеру, следует воспользоваться такой командой:

# systemctl isolate graphical.target
		

После её исполнения ваша система запустит среду с графическим рабочим столом.

Вновь установленная система RHEL9 будет содержать базовые компоненты (units) службы systemd, однако вряд ли это содержит все те службы данной системы, которые в конечном счёте требуются когда дело доходит до промышленной среды. Базовая установка RHEL9, к примеру, обычно не содержит те пакеты, которые требуются для запуска веб сервера Apache, ключевым элементом которого выступает его компонент httpd.service.

Системный администратор разрешит данную задачу устанавливая все необходимые пакеты при помощи такой команды:

# dnf install httpd
		

Обладая настроенным таким веб сервером, наша следующая задача будет заключаться в проверке значения состояния соответствующего компонента службы httpd чтобы определить была ли она активирована в качестве части процесса установки:

# systemctl status httpd.service
 httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:httpd.service(8)
		

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

# systemctl start httpd.service
		

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

# systemctl status httpd.service
 httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-02-15 11:13:26 EST; 8s ago
     Docs: man:httpd.service(8)
 Main PID: 10721 (httpd)
   Status: "Started, listening on: port 80"
    Tasks: 213 (limit: 13923)
   Memory: 24.1M
.
.
.
		

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

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

# systemctl enable httpd.service
		

После того как данная служба была разрешена, раздел Loaded значение вывода состояния будет считываться так:

Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
# systemctl status httpd.service
● httpd.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
     Active: active (running) since Thu 2023-03-30 09:04:21 EDT; 2min 17s ago
       Docs: man:httpd.service(8)
   Main PID: 4500 (httpd)
     Status: "Total requests: 0; Idle/Busy workers 100/0;Requests/sec: 0; Bytes served/sec: 0 B/sec"
      Tasks: 213 (limit: 22087)
     Memory: 35.4M
.
.
		

Запущенная в настоящий момент служба может быть остановлена когда угодно таким манером:

# systemctl stop httpd.service
		

Теперь, когда она была разрешена, при следующем перезапуске данной системы в эту текущую цель, наша служба httpd будет стартовать автоматически. Предположим, к примеру, что данная служба была разрешена когда её система работала как цель со множеством пользователей, данная служба httpd будет добавлена как иная зависимость в компонент systemd multi-user.target.

За сценой, systemctl добавляет зависимости к целям создавая символические ссылки в своей папке .wants для выбранной цели внутри папки /etc/systemd/system. Например, компонента multi-user.target обладает папкой с названием multi-user.target.wants в /etc/systemd/system, содержащей символические ссылки на все те расположенные в /usr/lib/systemd/system компоненты systemd, от которых она зависит. Просмотр данной папки отобразит некую корреляцию с теми зависимостями, которые перечислялись командой systemctl list-dependencies, обозначенной ранее в этой главе.

Чтобы настроить некую службу так, чтобы она больше не стартовала автоматически в качестве зависимости некой цели, отключите её следующим образом:

# systemctl disable httpd.service
		

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

Папка .wants содержит зависимости, которые, когда они не доступны, не будут препятствовать старту и работе своего компонента (unit). Обязательные зависимости (иначе говоря, зависимости, которые повлекут отказ данного компонента когда они не доступны) должны быть помещены в соответствующую папку .requires (к примеру, multi-user.target.requires).

Помимо разрешения и запрета, также имеется возможность маскирования некого компонента systemd следующим образом:

# systemctl mask httpd.service
		

Маскироавнный компонент systemd не может быть разрешён, запрещён или подвергаться старту ни при каких обстоятельствах, даже когда он перечисляется в качестве некой зависимости для иного компонента. Что касается данной системы, это означает именно то, что маскированного компонента systemd более не существует. Это может оказыываться полезным для гарантии того, чтобы такой компонент никогда не запускался, причём вне зависимости от условий данной системы. Единственный способ восстановления доступа к такой службе состоит в её демаскировании:

# systemctl unmask httpd.service
		

Помимо отображённых в данной главе методик командной строки, также имеется возможность просмотра и управления компонентами systemd внутри установленного веб интерфейса Cockpit. Например, в предположении, что Cockpit был установлен и запущен, как это было представлено в Главе 7, Обзор веб интерфейса Cockpit, доступ к общему перечню компонентов systemd в данной системе может быть осуществлён через регистрацию в Cockpi и выбор варианта Services в расположенной слева панели навигации, помеченной A на Рисунке 11-3:

Помеченная B строка вариантов отображает компоненты конкретного типа в своей главной области, помеченной C, где перечисляется значение состояния каждого компонента (unit) в соответствующем столбце State.

Выбор компонента из данного перечня отобразит подробные сведения. Рисунок 11-4, к примеру, показывает экран подробностей для экземпляра httpd, включая регистрации службы (A) и переключатель, а также меню (B) для выполнения таких задач, как запуск, останов, разрешение/ запрет и маскирование/ демаскирование соответствующего компонента:

Вновь установленная система RHEL9 содержит базовый набор компонентов systemd, причём многие из них исполняются в фоновом режиме, чтобы предоставлять бо́льшую часть функциональных возможностей системы. Эти компоненты разбиты по типам на категории а наиболее распространёнными выступают цели и службы. Компонент цели это группа прочих компонентов, подлежащих коллективному старту. Система обладает установленным по умолчанию компонентом цели, который определяет все прочие компоненты, подлежащие старту при каждом запуске этой системы. Наиболее распространённые цели это те, которые запускают данную систему либо в режиме со множеством пользователей, либо в графическом режиме. Кроме того, средство командной строки systemctl предоставляет некий диапазон параметров для осуществления задач настройки компонентов systemd, причём многие из них также доступны через веб интерфейс Cockpit.