Systemd#

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

  • параллельный запуск системных служб во время загрузки;

  • активацию демонов по требованию;

  • логику управления сервисом на основе зависимостей.

Типы юнитов systemd#

В качестве представления системных ресурсов и сервисов systemd вводится понятие systemd units (юнит). Юнит systemd выполняет или управляет определенной задачей, и является основным объектом для управления systemd. Ниже приведены следующие примеры различных типов юнитов systemd:

  • обслуживание;

  • цель;

  • устройство;

  • монтирование;

  • таймер;

  • другие типы, которые имеют отношение к системе инициализации.

Примечание

Для доступных типов юнитов используйте:

systemctl -t help

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

Таблица. Расположение юнит-файлов systemd

Каталог

Описание

/usr/lib/systemd/system/

Юнит-файлы systemd, распространяемые вместе с установленными пакетами RPM

/run/systemd/system/

Юнит-файлы systemd, созданные во время выполнения. Этот каталог имеет приоритет над каталогом с установленными файлами юнит-файла

/etc/systemd/system/

Юнит-файл systemd, созданные systemctl enable, а также юнит-файлы, добавленные для расширения службы. Этот каталог имеет приоритет над каталогом с юнит-файлами среды выполнения

Systemd - основные функции#

Конфигурация systemd по умолчанию определяется во время компиляции, конфигурация расположена в файле /etc/systemd/system.conf. Используйте этот файл для переопределения выбранных значений юнитов systemd по умолчанию. Например, чтобы переопределить значение ограничения времени ожидания по умолчанию, которое установлено равным 90 секундам, используйте параметр DefaultTimeoutStartSec для ввода требуемого значения в секундах.

DefaultTimeoutStartSec=required value

Управление системными службами с помощью systemctl#

Управление юнит-файлом с помощью systemctl#

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

  1. Чтобы отобразить подробную информацию о юнит-файле, соответствующем системной службе, введите:

    systemctl status <name>.service

    Замените <name> на имя юнит-файла, который нужно проверить.

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

Таблица. Доступная информация о юните service

Поле

Описание

Loaded

Информация о том, был ли загружен юнит, абсолютный путь к юнит-файлу и примечание о том, включен ли юнит

Active

Информация о том, работает ли юнит, за которой следует отметка времени

Main PID

PID соответствующей системной службы, за которым следует ее имя

Status

Дополнительная информация о соответствующей системной службе

Process

Дополнительная информация о связанных процессах

CGroup

Дополнительная информация о связанных контрольных группах (cgroups)

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

    systemctl is-active <name>.service

  2. Чтобы определить, включен ли конкретный юнит, введите:

    systemctl is-enabled <name>.service

    Примечание

    Оба юнита systemctl is-active и systemctl is-enabled возвращают статус выхода 0, если указанный юнит-файл запущен или включен.

  3. Чтобы определить, какие службы заказываются для запуска до указанного юнит-файла, введите:

    systemctl list-dependencies --after <name>.service

    Замените <name> на имя службы в команде.

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

    systemctl list-dependencies --before <name>.service

    Замените <name> на имя службы в команде.

Сравнение утилиты service с systemctl#

systemctl - команда управления менеджером системы Systemd.

service - команда управления Upstart.

В таблице ниже представлено сравнение утилиты service с systemd.

Таблица. Сравнение утилиты service с systemd.

service

systemctl

Описание

service name start

systemctl start name.service

Запуск сервиса

service name stop

systemctl stop name.service

Остановка сервиса

service name restart

systemctl restart name.service

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

service name condrestart

systemctl try-restart name.service

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

service name reload

systemctl reload name.service

Перезагрузка конфигурации

service name status

systemctl status name.servicesystemctl is-active name.service

Проверяет, запущен ли сервис

service –status-all

systemctl list-units –type service –all

Отображает статус всех сервисов

Список системных сервисов#

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

  • Чтобы вывести список всех загруженных в данный момент юнит-файлов, выполните следующую команду:

    UNIT LOAD ACTIVE SUB DESCRIPTION

abrt-ccpp.service loaded active exited Install ABRT coredump hook

abrt-oops.service loaded active running ABRT kernel log watcher

abrtd.service loaded active running ABRT Automated Bug Reporting Tool

----

systemd-vconsole-setup.service loaded active exited Setup Virtual Console

tog-pegasus.service loaded active running OpenPegasus CIM Server

LOAD = Reflects whether the unit definition was properly loaded.

ACTIVE = The high-level unit activation state, i.e. generalization of SUB.

SUB = The low-level unit activation state, values depend on unit type.

46 loaded units listed. Pass --all to see loaded but inactive units, too.

To show all installed unit files use 'systemctl list-unit-files'

    По умолчанию команда systemctl list-units отображает только активные объекты. Для каждого файла юнит-файла отображается команда, где:

    • UNIT: его полное название.

    • LOAD: информация о том, был ли загружен юнит-файл.

    • ACTIVE или SUB: состояние активации его высокоуровневого и низкоуровневого firewalld-filesystem.

    • DESCRIPTION: краткое описание.

  • Чтобы вывести список всех загруженных объектов независимо от их состояния, введите следующую команду с параметром --all из командной строки:

    systemctl list-units --type service --all

  • Чтобы перечислить состояние (включено или отключено) всех доступных сервисных устройств, введите:

    systemctl list-unit-files --type service

UNIT FILE STATE

abrt-ccpp.service enabled

abrt-oops.service enabled

abrtd.service enabled

...

wpa_supplicant.service disabled

ypbind.service disabled

208 unit files listed.

    Для каждого сервисного подразделения эта команда отображает:

    • UNIT FILE: его полное название.

    • STATE: информация о том, включен или отключен юнит-файл.

Отображение статуса системной службы#

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

systemctl cat atd.service

Пример вывода команды:

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

Положительные и отрицательные сервисные зависимости#

Чтобы увидеть дерево зависимостей модуля, можно использовать команду list-dependencies:

systemctl list-dependencies sshd.service

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

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

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

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

Кроме systemd, существуют положительные и отрицательные зависимости между службами. Запуск конкретной службы может потребовать запуска одной или нескольких других служб (положительная зависимость) или остановки одной, или нескольких служб (отрицательная зависимость).

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

Например, если запускается служба postfix и служба sendmail, systemd автоматически останавливает postfix, поскольку эти две службы конфликтуют и не могут запускаться на одном и том же порту.

Запуск системной службы#

Запустите системную службу в текущем сеансе с помощью команды start.

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

    systemctl start <name>.service

  2. Замените <name> на имя юнит-файла, который запускаете.

Остановка системной службы#

Остановите системную службу в текущем сеансе, используйте команду stop.

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

    systemctl stop <name>.service --stop-reason="<text_of_the_reason>"

    <text_of_the_reason> - произвольный текст причины остановки для внесения ее в журнал аудита.

  2. Замените <name> на имя юнит-файла, который нужно остановить.

Перезапуск системной службы#

Можно перезапустить системную службу в текущем сеансе с помощью команды restart:

  • Остановите выбранный юнит-файл в текущем сеансе и немедленно запустите его снова.

  • Перезапускайте юнит-файл только в том случае, если соответствующая служба уже запущена.

  • Перезагрузите конфигурацию системной службы, не прерывая ее выполнение.

  1. Перезапустите юнит-файл, соответствующий системной службе:

    systemctl restart <name>.service

    Замените <name> на имя юнит-файла, который нужно перезапустить.

    Примечание

    Если выбранный юнит-файл не запущен, эта команда также запускает его.

  2. Перезапустите юнит-файл, если соответствующая служба уже запущена:

    systemctl try-restart <name>.service

  3. В качестве альтернативы перезагрузите конфигурацию, не прерывая выполнение службы:

    systemctl reload <name>.service

    Примечание

    Системные службы, которые не поддерживают эту функцию, игнорируют эту команду. Чтобы перезапустить такие службы, используйте команды reload-or-restart или reload-or-try.

Включение системной службы#

Можно настроить службу на автоматический запуск во время загрузки системы. Команда enable считывает раздел [Install] выбранного юнит-файла и создает соответствующие символические ссылки на файл /usr/lib/systemd/system/name.service в каталоге /etc/systemd/system/ и его подкаталогах. Однако он не перезаписывает ссылки, которые уже существуют.

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

    systemctl enable <name>.service

    Замените <name> на имя юнит-файла, который нужно включить.

  2. При необходимости повторно включите системную службу:

    systemctl reenable <name>.service

    Эта команда отключает выбранный юнит-файл и немедленно включает его снова.

Отключение системной службы#

Можно запретить автоматический запуск юнит-файла во время загрузки. Команда disable считывает раздел [Install] выбранного юнит-файла и удаляет соответствующие символические ссылки на файл /usr/lib/systemd/system/name.service из каталога /etc/systemd/system/ и его подкаталогов.

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

    systemctl disable <name>.service

    Замените <name> на имя юнит-файла, который нужно отключить.

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

    systemctl mask <name>.service

    Эта команда заменяет файл /etc/systemd/system/name.service символической ссылкой на /dev/null, делая фактический юнит-файл недоступным systemd.

  3. Чтобы отменить это действие и снять маску с юнит-файла, введите:

    systemctl unmask <name>.service

Работа с целями systemd#

Цели systemd действуют как точки синхронизации во время запуска системы. Файлы целевых модулей, которые заканчиваются расширением файла .target, представляют цели systemd. Назначение целевых модулей - группировка различных systemd-модулей через цепочку зависимостей.

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

Можно отобразить цель по умолчанию с помощью команды systemctl или просмотреть файл /etc/systemd/system/default.target, представляющий целевую единицу по умолчанию.

  • Определите, какая целевая единица используется по умолчанию:

    systemctl get-default

    Пример вывода команды:

    graphical.target

  • Определите цель по умолчанию, используя символическую ссылку:

    ls -l /usr/lib/systemd/system/default.target

Просмотр целевых модулей#

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

  • Выведите список всех загруженных модулей независимо от их состояния:

    systemctl list-units --type target --all

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

systemctl list-units --type target

Пример вывода команды:

UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
basic.target          loaded active active Basic System
cryptsetup.target     loaded active active Encrypted Volumes
getty.target          loaded active active Login Prompts
graphical.target      loaded active active Graphical Interface
local-fs-pre.target   loaded active active Local File Systems (Pre)
local-fs.target       loaded active active Local File Systems
multi-user.target     loaded active active Multi-User System
network.target        loaded active active Network
paths.target          loaded active active Paths
remote-fs.target      loaded active active Remote File Systems
sockets.target        loaded active active Sockets
sound.target          loaded active active Sound Card
spice-vdagentd.target loaded active active Agent daemon for Spice guests
swap.target           loaded active active Swap
sysinit.target        loaded active active System Initialization
time-sync.target      loaded active active System Time Synchronized
timers.target         loaded active active Timers

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

17 loaded units listed.

Изменение цели по умолчанию#

Целевая единица по умолчанию представлена файлом /etc/systemd/system/default.target. Следующая процедура описывает, как изменить цель по умолчанию с помощью команды systemctl:

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

    systemctl get-default

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

    systemctl set-default multi-user.target

    Далее:

    rm /etc/systemd/system/default.target

    Затем:

    ln -s /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

    Команда заменяет файл /etc/systemd/system/default.target символической ссылкой на /usr/lib/systemd/system/name.target, где name — это имя целевого устройства, которое нужно использовать. Замените multi-user на имя целевого устройства, которое нужно использовать по умолчанию.

Общие цели для команды set-default представлены в таблице ниже:

Наименование цели

Описание

rescue

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

multi-user

Целевой модуль для настройки многопользовательской системы

graphical

Целевой модуль для настройки графического экрана входа в систему

emergency

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

sysinit

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

  1. Перезапустите ОС с помощью команды:

    reboot

Изменение цели по умолчанию с помощью символической ссылки#

Можно изменить цель по умолчанию, создав символическую ссылку на нужную цель.

  1. Определите целевой модуль по умолчанию:

    ls -l /etc/systemd/system/default.target

    Обратите внимание, что в некоторых случаях ссылка /etc/systemd/system/default.target может не существовать, и systemd ищет целевой модуль по умолчанию в файлах /usr. В таких случаях определите целевой модуль по умолчанию с помощью следующей команды:

    ls -l /usr/lib/systemd/system/default.target

  2. Удалите ссылку /etc/systemd/system/default.target:

    rm /etc/systemd/system/default.target

  3. Создайте символическую ссылку:

    ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target

  4. Перезагрузите систему.

Изменение текущей цели#

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

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

    systemctl isolate multi-user.target

Эта команда запускает целевой модуль с именем multi-user и все зависимые модули, и немедленно останавливает все остальные.

Замените multi-user на имя целевого устройства, которое нужно использовать по умолчанию.

Завершение и перезапуск работы системы#

Выключение системы#

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

Преимущество использования команды shutdown:

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

  • Возможность отменить выключение.

Выключение системы с помощью команды shutdown#

Используйте команду shutdown для выполнения различных операций. Выключите систему и выключите машину в определенное время, или выключите и остановите систему, не выключая машину, или отмените отложенное выключение.

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

    shutdown --poweroff hh:mm

    Где hh:mm (чч:мм) — время в 24-часовом формате. Файл /run/nologin создается за 5 минут до выключения системы, чтобы предотвратить новые входы в систему.

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

    shutdown --halt +m

    Где +m — время задержки в минутах. Ключевое слово now - псевдоним для +0.

  • Чтобы отменить отложенное завершение работы, используйте:

    shutdown -c

Выключение системы с помощью команды systemctl#

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

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

    systemctl poweroff

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

    systemctl halt

Примечание

По умолчанию запуск любой из этих команд приводит к тому, что systemd отправляет информационное сообщение всем пользователям, которые в данный момент вошли в систему. Чтобы systemd не отправил это сообщение, запустите выбранную команду с опцией --no-wall.

Перезапуск системы#

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

systemctl reboot

Примечание

По умолчанию эта команда заставляет systemd отправлять информационное сообщение всем пользователям, которые в данный момент вошли в систему. Чтобы systemd не отправил это сообщение, запустите эту команду с опцией --no-wall.

Работа с юнит-файлами systemd#

Эта глава включает описание юнитов systemd. В следующих разделах показано:

  • Создание пользовательских юнит-файлов.

  • Изменение существующих юнит-файлов.

  • Работа с юнитами systemd.

Юнит-файлы#

Юнит-файл содержит директивы конфигурации, которые описывают сам юнит и определяют его поведение. Несколько команд systemctl работают с юнитами в фоновом режиме. Для более точной настройки юнитов пользователь с административными полномочиями должен отредактировать или создать юнит-файлы вручную. Юниты systemd, созданные или настроенные администратором, хранятся в зарезервированном каталоге /etc/systemd/system/.

Формат имен юнит-файлов:

<unit_name>.<type_extension>

Здесь <unit_name> обозначает имя юнит-файла, а <type_extension> определяет тип.

Юнит-файлы могут быть дополнены каталогом дополнительных файлов конфигурации. Например, чтобы добавить пользовательские параметры конфигурации в sshd.service, создайте файл sshd.service.d/custom.conf и вставьте в него дополнительные директивы.

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

Файловая структура юнит-файлов#

Юнит-файлы обычно состоят из трех разделов:

  • Раздел [Unit]— общие опции, не зависящие от типа объекта. Эти параметры предоставляют описание юнита, определяют поведение и устанавливают зависимости для других юнит-файлов.

  • Раздел [Unit type]— директивы для конкретного типа, сгруппированные в соответствующих подразделах. Например, служебные юнит-файлы содержат подраздел [Service].

  • Раздел [Install] — информация об установке юнитов, используемых командами systemctl enable и systemctl disable.

Важные параметры раздела [Unit]#

В следующей таблице перечислены важные параметры раздела [Unit].

Параметр

Описание

Description

Содержит описание устройства. Этот текст отображается, например, в выводе команды systemctl status

Documentation

Предоставляет список URI, ссылающихся на документацию по устройству

After

Определяет порядок запуска юнитов. Юнит запускается только после того, как блоки в After становятся активны. В отличие от Requires, After напрямую не активирует указанные юниты. Опция Before по своему действию аналогична, но имеет противоположную функциональность

Requires

Настраивает зависимости от других юнитов. Юниты, перечисленные в Requires, активируются вместе. Если какой-либо из требуемых юнитов не запускается, другие также не запустятся

Wants

Настраивает более слабые зависимости, чем Requires. Если какое-либо из перечисленных юнитов не запускаются успешно, это не влияет на активацию других. Это рекомендуемый способ установки зависимостей

Conflicts

Настраивает отрицательные зависимости, противоположные Requires

Важные параметры раздела [Service]#

В следующей таблице перечислены важные параметры раздела [Service].

Параметр

Описание

Type

Настраивает тип запуска процесса, который влияет на функциональность ExecStart и связанные параметры. Один из:
- simple — значение по умолчанию. Процесс, с которого начинается ExecStart, основной процесс службы;
- forking — процесс, запущенный с помощью ExecStart, порождает дочерний, который становится основным. Родительский процесс завершается после запуска;
- oneshot — тип похож на simple, но процесс завершается перед запуском последующих юнитов;
- dbus – тип похож на simple, но последующие юниты запускаются только после того, как основной процесс получит имя D-Bus.
- notify — тип похож на simple, но последующие юниты запускаются только после отправки уведомления через функцию sd_notify()
- idle — аналогично simple, фактическое выполнение бинарного файла службы откладывается до тех пор, пока не будут завершены все задания, что позволяет избежать смешивания вывода состояния с выводом оболочки служб

ExecStart

Определяет команды или сценарии, которые должны выполняться при запуске юнита. ExecStartPre и ExecStartPost указывают пользовательские команды, которые будут выполняться до и после ExecStart. Type=oneshot позволяет указать несколько пользовательских команд, которые затем выполняются последовательно

ExecStop

Указывает команды или сценарии, которые должны выполняться при остановке юнита

ExecReload

Указывает команды или сценарии, которые должны выполняться при перезагрузке юнита

Restart

Если эта опция включена, юнит перезапускается после выхода из процесса, за исключением чистой остановки командой systemctl

RemainAfterExit

Если установлено значение True, юнит считается активным, даже если все его процессы завершились. Значение по умолчанию — False. Эта опция особенно полезна, если Type=oneshot настроен

Важные параметры раздела [Install]#

В следующей таблице перечислены важные параметры раздела [Install].

Вариант

Описание

Alias

Предоставляет разделенный пробелами список дополнительных имен для устройства. Большинство systemctl команд, за исключением systemctl enable, могут использовать псевдонимы вместо фактического имени устройства

RequiredBy

Список юнитов, которые зависят от включения. Когда этот юнит включен, юниты, перечисленные в RequiredBy, становятся Require

WantedBy

Список юнитов, слабо зависящих от включения. Когда этот юнит включен, юниты, перечисленные в WantedBy, становятся Want

Also

Задает список юнитов, которые необходимо установить или удалить вместе с юнитом

DefaultInstance

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

Описание службы systemd#

Можно найти описательную информацию о скрипте в строке, начинающейся с #description. Используйте это описание вместе с именем службы Description в опции раздела [Unit] юнит-файла. Заголовок может содержать аналогичные данные в строках #Short-Description и #Description.

Зависимости службы systemd#

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

Параметр заголовка

Описание

Эквивалент юнит-файла

Provides

Указывает имя загрузочного средства службы, на которое можно ссылаться в других сценариях инициализации (с префиксом $). Это больше не требуется, так как юнит-файлы относятся к другим юнитам по их именам

–

Required-Start

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

After, Before

Should-Start

Представляет собой более слабые зависимости, чем Required-Start. Неудачные зависимости Should-Start не влияют на запуск службы

After, Before

Required-Stop, Should-Stop

Формирует отрицательные зависимости

Conflicts

Поиск целей службы по умолчанию#

Строка, начинающаяся с #chkconfig, содержит три числовых значения. Наиболее важное - первое число, представляющее уровни выполнения по умолчанию, на которых запускается служба. Сопоставьте эти уровни запуска с эквивалентными целями systemd. Затем перечислите эти цели в опции WantedBy в разделе [Install] юнит-файла. Например, postfix ранее запускался на уровнях запуска 2, 3, 4 и 5, что соответствует - multi-user.target и graphical.target. Обратите внимание, что graphical.target зависит от multiuser.target, поэтому нет необходимости указывать оба. Также можно найти информацию об уровнях запуска (по умолчанию и запрещенных) в строках #Default-Start и #Default-Stop в заголовке.

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

Поиск файлов, используемых сервисом#

Сценарии инициализации требуют загрузки библиотеки функций из специального каталога и позволяют импортировать файлы конфигурации, среды и PID. Переменные среды указываются в строке, начинающейся с #config в заголовке скрипта инициализации, что соответствует параметру EnvironmentFile юнит-файла. Файл PID, указанный в строке сценария инициализации #pidfile, импортируется в юнит-файл с параметром.

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

conf_check() {
    [ -x /usr/sbin/postfix ] || exit 5
    [ -d /etc/postfix ] || exit 6
    [ -d /var/spool/postfix ] || exit 5
}

make_aliasesdb() {
    if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ]
    then
        # /etc/aliases.db might be used by other MTA, make sure nothing
        # has touched it since our last newaliases call
        [ /etc/aliases -nt /etc/aliases.db ] ||
            [ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
            [ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
        /usr/bin/newaliases
        touch -r /etc/aliases.db "$ALIASESDB_STAMP"
    else
        /usr/bin/newaliases
    fi
}

start() {
    [ "$EUID" != "0" ] && exit 4
    # Check that networking is up.
    [ ${NETWORKING} = "no" ] && exit 1
    conf_check
    # Start daemons.
    echo -n $"Starting postfix: "
    make_aliasesdb >/dev/null 2>&1
    [ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
    /usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
    RETVAL=$?
    [ $RETVAL -eq 0 ] && touch $lockfile
        echo
    return $RETVAL
}

Расширяемость сценария инициализации позволила указать две пользовательские функции conf_check() и make_aliasesdb(), которые вызываются из функционального блока start(). При ближайшем рассмотрении в приведенном выше коде упоминаются несколько внешних файлов и каталогов: основной исполняемый файл службы /usr/sbin/postfix, каталоги /etc/postfix/ и /var/spool/postfix/, а также /usr/sbin/postconf/.

systemd поддерживает только предопределенные действия, но позволяет выполнять пользовательские исполняемые файлы с ExecStart, ExecStartPre, ExecStartPost, ExecStop и ExecReload. Вместе с вспомогательными скриптами /usr/sbin/postfix пользовательские исполняемые файлы выполняются при запуске службы. Преобразование сложных сценариев инициализации требует понимания назначения каждого оператора в сценарии.

Изменение существующих юнит-файлов#

Службы, установленные в системе, поставляются с юнит-файлами по умолчанию, которые хранятся в каталоге /usr/lib/systemd/system/. Пользователи с административными полномочиями не должны изменять их напрямую, поэтому любая настройка должна ограничиваться файлами конфигурации в каталоге /etc/systemd/system/.

  1. В зависимости от степени требуемых изменений выберите один из следующих подходов:

    • Создайте каталог для дополнительных файлов конфигурации в /etc/systemd/system/. Этот метод рекомендуется для большинства случаев. Это позволяет расширить конфигурацию по умолчанию дополнительными функциями, при этом ссылаясь на исходный юнит-файл. Таким образом, изменения, введенные при обновлении пакета, применяются автоматически.

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

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

  3. Чтобы применить изменения к юнитам без перезагрузки системы, выполните:

    systemctl daemon-reload

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

    init q

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

    systemctl restart name.service

Например, чтобы расширить конфигурацию службы network, не изменяйте initscript-файл /etc/rc.d/init.d/network. Вместо этого создайте новый каталог /etc/systemd/system/network.service.d/ и файл systemd. Затем поместите измененные значения в файл systemd. Поэтому созданный каталог должен называться: /etc/systemd/system/network.service.d/my_config.confsystemdnetworknetwork.servicenetwork.service.d.

Расширение юнит-конфигурации по умолчанию#

В этом разделе описывается, как расширить юнит-файл по умолчанию дополнительными параметрами конфигурации.

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

    mkdir /etc/systemd/system/name.service.d/

    Замените name именем службы, которую нужно расширить. Приведенный выше синтаксис применим ко всем типам юнит-файлов.

  2. Создайте файл конфигурации в каталоге, созданном на предыдущем шаге. Обратите внимание, что имя файла должно заканчиваться суффиксом .conf:

    touch /etc/systemd/system/name.service.d/config_name.conf

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

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

    [Unit]
Requires=new_dependency
After=new_dependency

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

    [Service]
Restart=always
RestartSec=30

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

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

    systemctl daemon-reload

    Затем:

    systemctl restart name.service

Пример расширения конфигурации httpd.service#

Чтобы изменить юнит httpd.service таким образом, чтобы пользовательский сценарий оболочки автоматически выполнялся при запуске службы Apache, выполните следующие действия.

  1. Создайте каталог и пользовательский файл конфигурации:

    mkdir /etc/systemd/system/httpd.service.d/

  2. При условии, что скрипт, который нужно запустить автоматически с Apache, находится по адресу /usr/local/bin/custom.sh, вставьте в файл custom_script.conf следующий текст:

    [Service]
ExecStartPost=/usr/local/bin/custom.sh

  3. Чтобы применить изменения юнита, выполните:

    systemctl daemon-reload

    Затем:

    systemctl restart httpd.service

Важно

Файлы конфигурации из каталогов /etc/systemd/system/ имеют приоритет над файлами в каталоге /usr/lib/systemd/system/. Поэтому, если файлы конфигурации содержат параметр, который можно указать только один раз, например Description или ExecStart, значение по умолчанию для этого параметра переопределяется. Обратите внимание, что в выводе systemd-delta команды, такие единицы всегда помечаются как [EXTENDED], хотя в целом некоторые параметры фактически переопределяются.

Переопределение юнит-конфигурации по умолчанию#

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

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

    cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service

    Где name означает название юнит-файла, который нужно изменить. Приведенный выше синтаксис применим ко всем типам юнит-файлов.

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

    systemctl daemon-reload systemctl restart name.service

Изменение лимита времени ожидания#

Например, чтобы увеличить лимит тайм-аута для сервиса httpd:

  1. Скопируйте юнит-файл httpd в каталог /etc/systemd/system/:

    cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd.service

  2. Откройте файл /etc/systemd/system/httpd.service и укажите значение TimeoutStartUSec в разделе [Service]:

    ...
[Service]
...
PrivateTmp=true
TimeoutStartSec=10

[Install]
WantedBy=multi-user.target
...

  3. Перезагрузите systemd:

    systemctl daemon-reload

  4. При необходимости проверьте новое значение тайм-аута:

    systemctl show httpd -p TimeoutStartUSec

Примечание

Чтобы глобально изменить лимит тайм-аута, введите DefaultTimeoutStartSec в файле /etc/systemd/system.conf.

Мониторинг переопределенных юнит-файлов#

В этом разделе описывается, как отобразить перечень переопределенных или измененных юнит-файлов. Используйте следующую команду:

systemd-delta

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

[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target
[OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service

--- /usr/lib/systemd/system/autofs.service      2014-10-16 21:30:39.000000000 -0400
+ /etc/systemd/system/autofs.service  2014-11-21 10:00:58.513568275 -0500
@@ -8,7 +8,8 @@
 EnvironmentFile=-/etc/sysconfig/autofs
 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid
 ExecReload=/usr/bin/kill -HUP $MAINPID
-TimeoutSec=180
+TimeoutSec=240
+Restart=Always

 [Install]
 WantedBy=multi-user.target

[MASKED]     /etc/systemd/system/<service-name>.service → /usr/lib/systemd/system/<service-name>.service
[EXTENDED]   /usr/lib/systemd/system/<service-name-1>.service → /etc/systemd/system/<service-name-1>.service.d/journal.conf

4 overridden configuration files found.

Работа с юнитами systemd#

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

template_name@instance_name.service

Где template_name обозначает имя файла конфигурации шаблона. Замените instance_name именем экземпляра юнит-файла. Несколько экземпляров могут указывать на один и тот же файл шаблона с параметрами конфигурации, общими для всех экземпляров юнит-файлов. Имя юнит-шаблона имеет вид:

unit_name@.service

Например, следующий параметр Wants в юнит-файле:

Wants=getty@ttyA.service getty@ttyB.service

Этот параметр заставляет systemd искать заданные юнит-файлы. Если такие юниты не найдены, часть между @ и суффиксом типа игнорируется, и systemd ищет файл getty@.service, считывает из него конфигурацию и запускает службы.

Например, шаблон getty@.service содержит следующие директивы:

[Unit]
Description=Getty on %I
...
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
...

Когда экземпляры getty@ttyA.service и getty@ttyB.service создаются из приведенного выше шаблона, Description = разрешается как Getty на ttyA и Getty на ttyB.

Важные спецификаторы юнитов systemd#

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

Таблица. Важные спецификаторы systemd юнитов

Спецификатор юнитов

Значение

Описание

%n

Полное наименование юнита

Обозначает имя юнита с удаленным тип-суффиксом. Для созданных юнитов %p означает часть имени юнита перед символом @

%i

Имя экземпляра

Является частью имени созданного объекта между символом @ и тип-суффиксом. Имеет то же значение, но также заменяет запрещенные символы для кодов ASCII

%H

Имя хоста

Обозначает имя хоста работающей системы на момент загрузки конфигурации устройства

%t

Каталог рабочей среды

Представляет каталог рабочей среды, который предназначен /run для пользователя с административными полномочиями или представляет значение переменной XDG_RUNTIME_DIR для пользователей без административных полномочий

Оптимизация systemd для сокращения времени загрузки#

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

Проверка производительности загрузки системы#

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

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

    systemctl list-unit-files --state=enabled

  • Для получения общей информации о времени, затраченном на последнюю успешную загрузку, используйте:

    systemd-analyze

  • Для получения информации о времени инициализации каждого юнита systemd используйте:

    systemd-analyze blame

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

  • Чтобы определить юнит-файлы, инициализация которых заняла больше всего времени при последней успешной загрузке, используйте:

    systemd-analyze critical-chain

    На выходе красным цветом выделяются юнит-файлы, которые критически замедляют загрузку.

Настройка политик CPU Affinity и NUMA с помощью systemd#

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

Настройка привязки ЦП с помощью systemd#

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

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

Чтобы настроить маску соответствия ЦП для конкретной службы systemd, systemd предоставляет CPUAffinity= как параметр файла модуля, так и параметр конфигурации менеджера в файле /etc/systemd/system.conf.

Параметр файла модуля CPUAffinity= задает список ЦП или диапазонов ЦП, которые объединяются и используются в качестве маски сходства. Параметр CPUAffinity в файле /etc/systemd/system.conf определяет маску сходства для процесса с идентификационным номером (PID) 1 и всех процессов, ответвленных от PID1. Затем нужно переопределить CPUAffinity для каждой службы.

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

Чтобы установить маску привязки ЦП для конкретной службы systemd, используя параметр файла модуля CPUAffinity:

  1. Проверьте значения параметра файла модуля CPUAffinity в выбранном сервисе:

    systemctl show --property <CPU affinity configuration option> <service name>

  2. В качестве пользователя с административными полномочиями установите требуемое значение параметра файла модуля CPUAffinity для диапазонов ЦП, используемых в качестве маски сходства:

    systemctl set-property <service name> CPUAffinity=<value>

  3. Перезапустите службу, чтобы применить изменения:

    systemctl restart <service name>

  4. Чтобы установить маску соответствия ЦП для конкретной службы systemd, используя параметр конфигурации менеджера.

  5. Отредактируйте файл /etc/systemd/system.conf:

    vi /etc/systemd/system.conf

  6. Найдите параметр CPUAffinity= и установите номера процессоров.

  7. Сохраните отредактированный файл и перезапустите сервер, чтобы изменения вступили в силу.

Настройка политик NUMA с помощью systemd#

Non-uniform memory access (NUMA) — это конструкция подсистемы памяти компьютера, в которой время доступа к памяти зависит от расположения физической памяти относительно процессора.

Память, близкая к ЦП, имеет меньшую задержку (локальная память), чем память, локальная для другого ЦП (внешняя память) или совместно используемая набором ЦП.

Что касается ядра Linux, политика NUMA определяет, где (например, на каких узлах NUMA) ядро выделяет страницы физической памяти для процесса.

systemd предоставляет параметры файла модуля NUMAPolicy и NUMAMask для управления политиками выделения памяти для служб.

Чтобы установить политику памяти NUMA с помощью параметра файла модуля NUMAPolicy:

  1. Проверьте значения параметра файла модуля NUMAPolicy в выбранном сервисе:

    systemctl show --property <NUMA policy configuration option> <service name>

  2. В качестве пользователя с административными полномочиями установите требуемый тип политики в параметре модуля NUMAPolicy:

    systemctl set-property <service name> NUMAPolicy=<value>

  3. Перезапустите службу, чтобы применить изменения.

    systemctl restart <service name>

Чтобы установить глобальный параметр NUMAPolicy с помощью параметра конфигурации менеджера:

  1. Найдите в файле /etc/systemd/system.conf параметр NUMAPolicy.

  2. Измените тип политики, сохраните файл.

  3. Перезагрузите конфигурацию systemd службы:

    systemd daemon-reload

  4. Перезагрузите сервер.

*При настройке строгой политики NUMA, убедитесь, что также правильно установлен параметр файла модуля CPUAffinity=.

Параметры конфигурации политики NUMA для systemd#

Systemd предоставляет следующие параметры для настройки политики NUMA:

  • NUMAPolicy. Управляет политикой памяти NUMA исполняемых процессов. Возможны следующие типы политик:

    • default;

    • preferred;

    • bind;

    • interleave;

    • local.

  • NUMAMask. Управляет списком узлов NUMA, связанным с выбранной политикой NUMA. Обратите внимание, что параметр NUMAMask не требуется указывать для следующих политик:

    • default;

    • local.

    Для предпочтительной политики в списке указан только один узел NUMA.