Менеджер сервисов systemd

Файл сервиса systemd
Типы служб
Замещение файла юнита
Компоненты system
Запуск сервисов после подключения к сети

Systemd – менеджер системы и сервисов в операционной системе РЕД ОС.

Systemd приносит концепцию юнитов systemd. Юниты представлены конфигурационными файлами, размещенными в одной из директорий:

• /usr/lib/systemd/system/ – юниты из установленных пакетов RPM.

• /run/systemd/system/ — юниты, созданные в рантайме. Этот каталог приоритетнее каталога с установленными юнитами из пакетов.

• /etc/systemd/system/ — юниты, созданные и управляемые системным администратором. Этот каталог приоритетнее каталога юнитов, созданных в рантайме.

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

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

• .service – системный сервис,
• .target — группа юнитов systemd,
• .automount – точка автомонтирования файловой системы,
• .device – файл устройства, распознанного ядром,
• .mount – точка монтирования файловой системы,
• .path – файл или директория в файловой системе,
• .scope – процесс, созданный извне,
• .slice – группа иерархически организованных юнитов, управляющая системными процессами,
• .snapshot – сохраненное состояние менеджера systemd,
• .socket – сокет межпроцессного взаимодействия,
• .swap – свап-устройство или свап-файл (файл подкачки),
• .timer – таймер systemd.

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

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

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

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

Система может сохранять состояние всех юнитов и восстанавливать предыдущее состояние системы.

Systemd отслеживает и управляет точками монтирования и автомонтирования.

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

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

SystemD полностью поддерживает скрипты инициализации SysV, как описано в спецификации Linux Standard Base (LSB), что упрощает переход на systemd.

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

При использовании systemctl указывать расширение файла не обязательно.

Основные команды systemctl:

 systemctl start name.service – запуск сервиса, 
 systemctl stop name.service — остановка сервиса, 
 systemctl restart name.service — перезапуск сервиса,  
 systemctl try-restart name.service — перезапуск сервиса только, если он запущен, 
 systemctl reload name.service — перезагрузка конфигурации сервиса, 
 systemctl status name.service — проверка, запущен ли сервис с детальным выводом состояния сервиса, 
 systemctl is-active name.service — проверка, запущен ли сервис с простым ответом: active или inactive, 
 systemctl list-units --type service --all – отображение статуса всех сервисов, 
 systemctl --failed – отображение списка юнитов, которые не удалось запустить, 
 systemctl enable name.service – активирует сервис (позволяет стартовать во время запуска системы), 
 systemctl disable name.service – деактивирует сервис, 
 systemctl reenable name.service – деактивирует сервис и сразу активирует его, 
 systemctl is–enabled name.service – проверяет, активирован ли сервис, 
 systemctl list-unit-files --type service – отображает все сервисы и проверяет, какие из них активированы, 
 systemctl cat name.service – позволит просмотреть содержимое файла юнита и связанных с ним drop-in сниппетов,
 systemctl mask name.service – заменяет файл сервиса симлинком на /dev/null, делая юнит недоступным для systemd, 
 systemctl unmask name.service – возвращает файл сервиса, делая юнит доступным для systemd. 

Файлы целей systemd .target предназначены для группировки вместе других юнитов systemd через цепочку зависимостей. Например, юнит graphical.target, использующийся для старта графической сессии, запускает системные сервисы GNOME Display Manager (gdm.service) и Accounts Service (accounts–daemon.service) и активирует multi–user.target. В свою очередь multi–user.target запускает другие системные сервисы, такие как Network Manager (NetworkManager.service) или D-Bus (dbus.service) и активирует другие целевые юниты basic.target.

В РЕД ОС присутствуют предопределенные цели, похожие на стандартный набор уровней запуска. По соображениям совместимости они также имеют псевдонимы на эти цели, которые напрямую отображаются в уровнях запуска SysV.

 poweroff.target (runlevel0.target) – завершение работы и отключение системы 
 rescue.target (runlevel1.target) – настройка оболочки восстановления 
 multi–user.target (runlevel2.target, runlevel3.target, runlevel4.target) – настройка неграфической многопользовательской системы 
 graphical.target (runlevel5.target) – настройка графической многопользовательской системы 
 reboot.target (runlevel6.target) – выключение и перезагрузка системы 

Команды runlevel и telinit по-прежнему доступны, но оставлены в системе по соображениям совместимости. Рекомендуется использовать systemctl для изменения или настройки системных целей.

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

systemctl get–default

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

systemctl list-units --type target

а для просмотра вообще всех целевых юнитов командой:

systemctl list-units --type target --all

Для изменения цели по умолчанию поможет команда:

systemctl set-default name.target

Для изменения текущей цели:

systemctl isolate name.target

Команда запустит целевой юнит и все его зависимости и немедленно остановит все остальные.

В РЕД ОС systemctl заменяет значительное количество команд управления питанием. Прежние команды сохранены для совместимости, но рекомендуется использовать systemctl:

• systemctl halt – останавливает систему,

• systemctl poweroff – выключает систему,

• systemctl reboot – перезагружает систему,

• systemctl suspend – переводит систему в режим ожидания,

• systemctl hibernate – переводит систему в спящий режим,
  

• systemctl hybrid-sleep – переводит систему в режим гибридного сна.
  

Systemd позволяет управлять удаленной машиной по SSH. Для управления используйте команду:

systemctl --host <user_name>@<host_name> <command>

где user_name – имя пользователя, host_name – имя хоста, которым осуществляется удаленное управление, а command – выполняемая команда systemd. Подробная информация о всех параметрах файла .service есть в соответствующем разделе документации по systemd.

Файл сервиса systemd

[Unit]
Description=Daemon to detect crashing apps
After=syslog.target

[Service]
ExecStart=/usr/sbin/abrtd
Type=forking

[Install]
WantedBy=multi-user.target

Давайте посмотрим на секцию [Unit]. Она содержит общую информацию о сервисе. Такая секция есть не только в сервис-юнитах, но и в других юнитах (например при управлении устройствами, точками монтирования и т.д.). В примере мы даем описание сервиса и указываем на то, что демон должен быть запущен после Syslog.

В следующей секции [Service] непосредственно содержится информация о нашем сервисе. Используемый параметр ExecStart указывает на исполняемый файл нашего сервиса. В Type мы указываем, как сервис уведомляет systemd об окончании запуска.

Финальная секция [Install] содержит информацию о цели, в которой сервис должен стартовать. В данном случае мы говорим, что сервис должен быть запущен, когда будет активирована цель multi–user.target. Это минимальный работающий файл сервиса systemd. Написав свой, для тестирования скопируйте его в /etc/systemd/system/.service. Выполните команду:

systemctl daemon-reload

Systemd узнает о сервисе и вы сможете его запустить.

Типы служб

Службы различаются по типу запуска, что следует учитывать при написании юнитов. Тип определяется параметром Type= в разделе [Service]:

• Type=simple (по умолчанию): systemd запустит эту службу незамедлительно. Процесс при этом не должен разветвляться (fork). Если после данной службы должны запускаться другие, то этот тип использовать не стоит (исключение — служба использует сокетную активацию).

• Type=forking: systemd считает службу запущенной после того, как процесс разветвляется с завершением родительского процесса. Используется для запуска классических демонов за исключением тех случаев, когда в таком поведении процесса нет необходимости. Укажите параметр PIDFile=, чтобы systemd мог отслеживать основной процесс.

• Type=oneshot: удобен для сценариев, которые выполняют одно задание и завершаются. Если задать параметр RemainAfterExit=yes, то systemd будет считать процесс активным даже после его завершения.

• Type=notify: идентичен параметру Type=simple, но с уточнением, что демон пошлет systemd сигнал готовности. Реализация уведомления находится в библиотеке libsystemd-daemon.so.

• Type=dbus: служба считается находящейся в состоянии готовности после появления указанного BusName в системной шине DBus.

• Type=idlel: systemd отложит выполнение двоичного файла службы до окончания запуска остальных ("более срочных") задач. В остальном поведение аналогично Type=simple.

Замещение файла юнита

Можно полностью заместить файл юнита /usr/lib/systemd/system/<юнит>, для этого необходимо создать файл с таким же именем /etc/systemd/system/<юнит> и включить заново юнит для обновления символических ссылок.

 systemctl edit --full <юнит>

Эта команда откроет файл /etc/systemd/system/<юнит> в текстовом редакторе (если файл ещё не существует, будет скопирован оригинал) и автоматически перезагрузит юнит после завершения редактирования.

Компоненты system

• systemd-boot — простой менеджер загрузки для UEFI;

• systemd-firstboot — инициализация системных настроек при первой загрузке;

• systemd-homed — переносимые аккаунты пользователей;

• systemd-logind — управление сеансами;

• systemd-networkd — управление сетевыми настройками;

• systemd-nspawn — приложение для контейнеризации процессов;

• systemd-resolved — разрешение сетевых имён;

• systemd-sysusers — создание системных пользователей/групп и добавление пользователей в группы при установке пакетов и загрузке системы;

• systemd-timesyncd — синхронизация системных часов по сети;

• systemd/Журнал — системные логи;

• systemd/Таймеры — таймеры для управления событиями и службами, альтернатива cron.

Запуск сервисов после подключения к сети

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

 nano /etc/system/system/foo.service 

 [Unit]
 …
 Wants=network-online.target
 After = network-online.target
 …

Дата последнего изменения: 03.10.2024

Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.