Наши партнеры

UnixForum





Библиотека сайта rus-linux.net

systemd: основные приемы работы с юнит-файлами

Оригинал: systemd unit file basics
Автор: Bryan Sutherland
Дата публикации: 28 октября 2015 г.
Перевод: А.Панин
Дата перевода: 12 ноября 2015 г.

systemd: основные приемы работы с юнит-файлами

Добро пожаловать в серию статей о системе инициализации systemd, в которой мы разбираемся с тем, как работает эта центральная часть вашей системы Fedora. В данной статье речь пойдет о юнит-файлах (unit files).

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

Юнит-файлы: что это такое?

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

Юнит-файлы могут храниться в нескольких различных директориях вашей файловой системы. systemd осуществляет поиск системных юнит-файлов в директориях в следующей последовательности:

  1. /etc/systemd/system

  2. /run/systemd/system

  3. /usr/lib/systemd/system

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

Также systemd может работать в контексте пользователей и управлять ресурсами отдельных пользователей, в дополнение управлению ресурсами системы. Юнит-файлы пользовательских юнитов по аналогии хранятся в директориях /etc/systemd/<имя пользователя>, /run/sustemd/<имя пользователя> и /usr/lib/systemd/<имя пользователя>. Упомянутые директории имеют аналогичный приоритет.

Вы можете получить информацию об этих юнит-файлах с помощью команды systemctl. Если вы хотите увидеть список всех юнит-файлов, установленных в вашей системе, выполните следующую команду:

systemctl list-unit-files

Каждый юнит-файл содержит пары параметр-значение в формате ИмяПараметра=значение, разделенные на секции, выделенные с помощью заголовков в формате [ИмяСекции]. Эти пары параметр-значение описывают принцип работы юнита, а также способ взаимодействия systemd с ним.

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

systemctl list-unit-files --type service
systemctl list-unit-files --type target

Юниты служб

Данные юниты описывают процесс, который может быть запущен и отслеживаться с помощью systemd. Юниты служб являются наиболее часто используемыми юнитами при повседневной работе с системой. Управление данными юнитами может осуществляться с помощью команды systemctl от лица пользователя root:

sudo systemctl [команда] ИМЯ.service

Стандартные команды:

  • start: запускает службу, представленную в виде юнита systemd
  • stop: пытается "корректно" завершить работу службы
  • status: выводит подробную информацию о состоянии службы
  • restart: перезапускает (завершает работу и впоследствии запускает) указанную службу
  • enable: активирует юнит-файл (создает символьные ссылки) в различных директориях для запуска службы в процессе загрузки системы
  • disable: деактивирует юнит-файл (удаляет символьные ссылки) для того, чтобы соответствующая служба не запускалась автоматически

В следующем примере приведено содержимое юнит-файла sshd.service. Он позволяет systemd управлять демоном sshd, который предназначен для обеспечения удаленного доступа к вашей системе по протоколу SSH (Secure Shell).

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

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

[Install]
WantedBy=multi-user.target

Этот юнит-файл содержит как часто используемые, так и специфичные для юнита данной службы параметры. Часто используемыми параметрами, использованными в данном файле, являются описание службы и информация о расположении документации. Разумеется, в данном файле используются и такие параметры, которые не будут описаны в данной статье. Но вы наверняка догадаетесь, что параметр ExecStart, к примеру, предназначен для запуска демона sshd при активации юнита.

Процессы системных служб

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

•  sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2015-10-20 14:51:24 EDT; 1 weeks 0 days ago
   Docs: man:sshd(8)
         man:sshd_config(5)
   Main PID: 1090 (sshd)
   CGroup: /system.slice/sshd.service
           └─1090 /usr/sbin/sshd -D

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

Обратите внимание на то, что при запуске службы данный процесс был помещен в группу управления с соответствующим именем. Группа управления (control group или "cgroup") позволяет systemd осуществлять управление группами ассоциированных процессов. В следующих статьях серии мы поговорим о том, как данная возможность может использоваться для регулирования производительности и установки ограничений ресурсов для процессов служб.

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

systemctl stop httpd.service

Но что случится в том случае, если служба не ответит на запрос завершения работы и не будет каким-либо образом взаимодействовать с systemd? Для таких случаев утилита systemctl предоставляет встроенную реализацию команды kill:

systemctl kill httpd.service

Юниты целей

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

Ниже приведен пример содержимого файла юнита цели multi-user.target.

[Unit]
Description=Multi-User System
Documentation=man:systemd.special(7)
Requires=basic.target
Conflicts=rescue.service rescue.target
After=basic.target rescue.service rescue.target
AllowIsolate=yes

Обратите внимание на то, что этот файл юнита цели не содержит команды для исполнения. Вместо нее он содержит списки юнитов (в данном случае в основном юнитов целей) и используется для объединения этих юнитов. Данный файл описывает следующее правила:

  • Цель multi-user.target требует, чтобы была успешно достигнута цель basic.target.
  • В том случае, если исполняется служба, соответствующая юниту rescue.service, или достигнута цель, соответствующая юниту rescue.target, данный юнит будет остановлен и наоборот.
  • Достижение цели multi-user.target начинается сразу после начала инициирования достижения цели basic.target и после запуска службы rescue.target и достижения цели rescue.target в случае активации последних.

Кроме того, данный юнит цели содержит параметр AllowIsolate. Этот параметр позволяет вашей системе рассматривать юнит цели multi-user.target в качестве цели процесса загрузки системы благодаря выполнению команды systemctl isolate.

Юниты целей позволяют группировать другие юниты не только на основе содержимого соответствующих файлов юнитов. Файл юнита цели может использовать директорию .wants для размещения ссылок на юниты, которые должны запускаться вместе с юнитом цели. Например, файл /usr/lib/systemd/system/multi-user.target имеет ассоциированную директорию /usr/lib/systemd/system/multi-user.target.wants. Эта директория содержит ссылки на юниты (не только юниты служб, но и юниты других целей), которые будут исполняться при инициировании достижения соответствующей цели. Каждый из этих юнитов может иметь свои зависимости, а также такие параметры, как приведенный выше параметр Requires, позволяющий указать юниты, которые должны быть запущенны для запуска рассматриваемого юнита.

Полезные информационные ресурсы

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

man systemd.unit

Также существует документация, относящаяся к файлам юнитов служб и целей. Вы можете ознакомится с ней, выполнив следующие команды:

man systemd.service
man systemd.target

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