Systemd#

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

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

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

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

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

В качестве представления системных ресурсов и сервисов systemd вводится понятие systemd unit (юнит). Юнит 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 (подробнее в разделе «База знаний» → «Утилита systemctl»).

service - команда управления Upstart (подробнее в разделе «База знаний» → «Утилита service»).

В таблице ниже представлено сравнение утилиты 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 rescue
Broadcast message from root@localhost on pts/0 (Fri 2013-10-25 18:23:15 CEST):
The system is going down to rescue mode NOW!

Примечание

Эта команда похожа на systemctl isolate rescue.target, но она также отправляет информационное сообщение всем пользователям, которые в данный момент вошли в систему. Чтобы systemd не отправлял это сообщение, выполните следующую команду с параметром --no-wall: systemctl --no-wall rescue

Загрузка в аварийном режиме#

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

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

systemctl emergency

Важно

Эта команда похожа на systemctl isolate emergency.target, но она также отправляет информационное сообщение всем пользователям, которые в данный момент вошли в систему. Чтобы systemd не отправлял это сообщение, выполните следующую команду с параметром --no-wall: systemctl --no-wall emergency

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

Для выключения системы можно либо воспользоваться утилитой 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.

Приостановка системы#

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

systemctl suspend

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

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

Спящий режим системы#

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

systemctl hibernate

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

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

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

systemctl hybrid-sleep

Обзор команд управления питанием с помощью systemctl#

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

Обзор команд управления питанием systemctl#

Команда systemctl

Описание

systemctl halt

Останавливает систему

systemctl poweroff

Выключает систему

systemctl reboot

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

systemctl suspend

Приостанавливает работу системы

systemctl hibernate

Гибернирует систему

systemctl hybrid-sleep

Гибернирует и приостанавливает работу системы

Работа с юнит-файлами 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].

Параметры раздела [Unit]#

Параметр

Описание

Description

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

Documentation

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

After

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

Requires

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

Wants

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

Conflicts

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

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

В следующей таблице перечислены важные параметры раздела [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].

Параметры раздела [Install]#

Параметр

Описание

Alias

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

RequiredBy

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

WantedBy

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

Also

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

DefaultInstance

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

Создание пользовательских юнитов#

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

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

  1. Подготовьте исполняемый файл с пользовательской службой. Это может быть специально созданный сценарий или исполняемый файл, предоставленный поставщиком программного обеспечения. При необходимости подготовьте файл PID для хранения постоянного PID для основного процесса пользовательской службы. Также можно включить файлы среды для хранения переменных оболочки для службы. Убедитесь, что исходный сценарий является исполняемым (выполнив команду chmod a+x) и не интерактивным.

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

    touch /etc/systemd/system/name.service
chmod 664 /etc/systemd/system/name.service

    Замените name именем создаваемой службы. Обратите внимание, что файл должен быть исполняемым.

  3. Откройте файл name.service, созданный на предыдущем шаге, и добавьте параметры конфигурации службы. Существует множество параметров, которые можно использовать в зависимости от типа службы.

    Ниже приведен пример конфигурации устройства для сетевой службы:

    [Unit]
Description=service_description
After=network.target

[Service]
ExecStart=path_to_executable
Type=forking
PIDFile=path_to_pidfile

[Install]
WantedBy=default.target

    Где:

    • service_description — это информативное описание, которое отображается в файлах журнала и в выходных данных systemctl status команды;

    • Настройка After гарантирует, что служба запускается только после запуска сети. Добавьте через пробел список других соответствующих служб или целей;

    • path_to_executable обозначает путь к фактическому исполняемому файлу службы;

    • Type=forking используется для демонов, которые выполняют системный вызов fork. Основной процесс службы создается с PID, указанным в path_to_pidfile;

    • WantedBy указывает цель или цели, под которыми должна быть запущена служба. Думайте об этих целях как о замене старой концепции уровней выполнения.

  4. Сообщите systemd о существовании нового name.service файла, выполнив следующую команду от имени пользователя с административными полномочиями:

    systemctl daemon-reload
systemctl start name.service

    Внимание

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

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

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

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

  1. Создайте копию файла sshd_config, который будет использоваться вторым демоном:

    cp /etc/ssh/sshd{,-second}_config

  2. Отредактируйте файл sshd-second_config, созданный на предыдущем шаге, чтобы назначить другой номер порта и файл PID второму демону:

    Port 22220
PidFile /var/run/sshd-second.pid

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

  3. Создайте копию юнит-файла systemd для службы sshd:

    cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service

  4. Измените sshd-second.service, созданный на предыдущем шаге, следующим образом:

    • Измените Description=<option>:

      Description=OpenSSH server second instance daemon

    • Добавьте sshd.service к службам, указанным в опции, чтобы второй экземпляр запускался только после того, как первый уже запущен:

      After=syslog.target network.target auditd.service sshd.service

      • Первый экземпляр sshd включает генерацию ключей, поэтому удалите строку ExecStartPre=/usr/sbin/sshd-keygen.

      • Добавьте в команду -f /etc/ssh/sshd-second_config параметр sshd, чтобы использовался альтернативный файл конфигурации:

        ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS

      • После вышеуказанных изменений sshd-second.service должен выглядеть следующим образом:

        [Unit]
Description=OpenSSH server second instance daemon
After=syslog.target network.target auditd.service sshd.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

    • При использовании SELinux добавьте порт для второго экземпляра sshd в порты SSH, иначе второй экземпляр sshd будет отклонен для привязки к порту:

      semanage port -a -t ssh_port_t -p tcp 22220

    • Включите sshd-second.service, чтобы он запускался автоматически при загрузке:

      systemctl enable sshd-second.service

    • Убедитесь, что служба sshd-second.service запущена с помощью systemctl status команды.

    • Убедитесь, что порт включен правильно, подключившись к службе:

      ssh -p 22220 user@server

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

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

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

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

Заголовок может содержать несколько директив, формирующих зависимости между службами. Большинство из них можно перевести в параметры юнита 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

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

Выходные данные команды systemd-analyze critical-chain

Рисунок. Выходные данные команды systemd-analyze critical-chain

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

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

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

systemctl list-unit-files --state=enabled

Чтобы отключить службу, выполните:

systemctl disable service_name

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

Можно использовать приведенную ниже таблицу в качестве руководства по выбору служб, которые можно безопасно отключить. В таблице перечислены все службы, включенные по умолчанию при минимальной установке SberLinux OS Server, и для каждой службы указано, можно ли безопасно отключить эту службу. В таблице также содержится дополнительная информация об обстоятельствах отключения службы или о причине, по которой не нужно отключать службу.

Службы, включенные по умолчанию при минимальной установке SberLinux OS Server#

Название службы

Возможность отключения

Дополнительная информация

auditd.service

ДА

Отключите auditd.service только в том случае, если не нужны сообщения аудита от ядра. Если отключится auditd.service, файл /var/log/audit/audit.log не создается. Следовательно, не получится ретроактивно просмотреть некоторые часто просматриваемые действия или события, такие как вход пользователя в систему, запуск службы или смена пароля. Также обратите внимание, что auditd состоит из двух частей: части ядра и самой службы. Используя команду systemctl disable auditd, отключите только службу, но не часть ядра. Чтобы полностью отключить системный аудит, установите audit=0 в командной строке ядра. Чтобы отобразить параметры командной строки ядра, заданные для текущей загруженной системы, используйте любую из следующих команд: `sysctl -a sysctl -a

autovt@.service

НЕТ

Конфигурация по умолчанию устанавливается во время компиляции и настраивается только тогда, когда необходимо отклониться от этих значений по умолчанию, поэтому ее отключать не нужно. По умолчанию, autovt@.service связан с getty@.service. Запросы на вход запускаются динамически, когда пользователь переключается на неиспользуемые виртуальные терминалы, и этот параметр определяет, сколько учетных записей gettys доступно VTS

crond.service

ДА

Имейте в виду, что никакие элементы из crontab не будут запускаться, если crond.service будет отключена

dbus-org.fedoraproject.FirewallD1.service

ДА

Символическая ссылка на firewalld.service

dbus-org.freedesktop.NetworkManager.service

ДА

Символическая ссылка на NetworkManager.service

dbus-org.freedesktop.nm-dispatcher.service

ДА

Символическая ссылка на NetworkManager-dispatcher.service

firewalld.service

ДА

Отключите firewalld.service только в том случае, если не нужен межсетевой экран

getty@.service

НЕТ

Отключать небезопасно, поскольку доступ к консоли - это то, к чему обращается пользователь, когда другие средства доступа к серверу не работают

import-state.service

ДА

Отключите import-state.service только в том случае, если не нужно загружаться из сетевого хранилища

irqbalance.service

ДА

Отключите irqbalance.service только если задействован один процессор. Не отключайте irqbalance.service в системах с несколькими процессорами

kdump.servicedmodules.service

ДА

Эта служба не запускается до тех пор, пока каталог /etc/rc.modules/etc/sysconfig/modules существует, а значит он не запускается при минимальной установке SberLinux OS Server

lvm2-monitor.service

ДА

Отключите lvm2-monitor.service только в том случае, если не используете диспетчер логических томов (LVM)

microcode.service

НЕТ

Не отключайте службу, поскольку она предоставляет обновления программного обеспечения микрокода в CPU

NetworkManager-dispatcher.service

ДА

Отключите NetworkManager-dispatcher.service только в том случае, если не нужны уведомления об изменениях конфигурации сети (например, в статических сетях)

NetworkManager-wait-online.service

ДА

Отключите NetworkManager-wait-online.service только в том случае, если не нужно рабочее сетевое подключение, доступное сразу после загрузки. Если служба включена, система не завершит загрузку до того, как сетевое подключение заработает. Это может значительно увеличить время загрузки

NetworkManager.service

ДА

Отключите NetworkManager.service только в том случае, если не нужно подключение к сети

nis-domainname.service

ДА

Отключите nis-domainname.service только в том случае, если не используете службу сетевой информации (NIS)

rhsmcertd.service

НЕТ

-

rngd.service

ДА

Отключите rngd.service только в том случае, если не нужно много энтропии в системе или нет какого-либо аппаратного генератора. Обратите внимание, что служба необходима в средах, требующих высокой энтропии, таких как системы, используемые для генерации сертификатов X.509 (например, сервер FreeIPA)

rsyslog.service

ДА

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

selinux-autorelabel-mark.service

ДА

Отключите selinux-autorelabel-mark.service только в том случае, если не используете SELinux

sshd.service

ДА

Отключите sshd.service только в том случае, если не нужны удаленные входы в систему с помощью сервера OpenSSH

sssd.service

ДА

Отключите sssd.service только в том случае, если нет пользователей, которые входят в систему по сети (например, с помощью LDAP или Kerberos). Рекомендуется отключить все sssd-* юниты, если отключите sssd.service. Можно настроить SSSD для преобразования пользовательских домашних каталогов в нижний регистр. Это помогает лучше интегрироваться с чувствительностью к регистру среды ОС. Опция в override_homedir разделе [nss] файла распознает /etc/sssd/sssd.conf значение шаблона. При использовании %h как части определения SSSD заменяется %h домашним каталогом пользователя override_homedir%h в нижнем регистре

syslog.service

ДА

Псевдоним для rsyslog.service

tuned.service

ДА

Отключите tuned.service только в том случае, если действительно нужно использовать настройку производительности

lvm2-lvmpolld.socket

ДА

Отключите lvm2-lvmpolld.socket только в том случае, если не используете диспетчер логических томов (LVM)

dnf-makecache.timer

ДА

Отключите dnf-makecache.timer только в том случае, если не нужно, чтобы метаданные пакета обновлялись автоматически

unbound-anchor.timer

ДА

Отключите unbound-anchor.timer только в том случае, если не требуется ежедневного обновления корневого ключа для якоря доверия, отвечающего за расширение безопасности DNS (DNSSEC). Этот якорь доверия используется несвязанным распознавателем и библиотекой распознавателей для проверки DNSSEC

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

systemctl cat <service_name>
systemctl help <service_name>

Команда systemctl cat предоставляет содержимое служебного файла, расположенного в файле /usr/lib/systemd/system/<service>, а также все применимые переопределения. Применимые переопределения включают переопределения единичных файлов из файла /etc/systemd/system/<service> или выпадающих файлов из unit.type.d справочника.

Для получения дополнительной информации введите:

systemctl help

Команда systemctl help показывает справочную страницу конкретной службы.

Настройка политик 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.