Введение в Systemd. Часть 3. Юниты и цели






Работа, выполняемая Systemd в процессе загрузки системы (создание сокетов, настройка оборудования, монтирование ФС, запуск демонов и т. п.), группируется в юниты. Каждая задача, выполняемая Systemd  требует наличия конфигурационного файла для соответствующего юнита. В этих конфигурационных файлах содержится вся необходимая информация для каждого юнита. Например, для mount-юнита требуется имя устройства и путь к каталогу монтирования. В отличие от традиционных init-сценариев, фийлы конфигурации юнитов значительно короче и читабельнее и своим синтаксисом напоминают ini-файлы.

Systemd


Systemd определяет тип юнита исходя из имени его конфиг-файла. Файлы, чьи имена имеют суффикс .service описывают юниты служб и предназначены для управления SysV-init службами — их запуском и остановом, используя традиционные init-сценарии. Юниты, управляющие монтированием файловых систем конфигурируются файлами, в именах которых присутствует суффикс .mount и .automount. Во втором случае задействуется компонент automounter, выполняющий автоматическое монтирование ФС в ответ на события доступа к файлам. Юниты с суффиксом .path позволяют Systemd наблюдать за определёнными в файле конфигурации юнита файлами и каталогами, и выполнять действия в ответ на попытки доступа к ним.

Файлы юнитов, имена которых оканчиваются на .socket, отвечают за создание сокетов. Обратите внимание, что они не запускают служб. За запуск служб отвечают service-юниты, связанные с соответствующими socket-юнитами. Когда будет получен запрос на подключение к сокету, Systemd запустит нужную службу, предоставив ей доступ к требуемым сокетам. Этот подход немного напоминает поведение старого-доброго inetd.

Юнит-файлы располагаются в каталоге /lib/systemd/system/ или в /etc/systemd/system/, при этом второй имеет более высокий приоритет. Традиционная методика распределения файлов конфигурации между двумя каталогами позволяет системным администраторам модифицировать нужные конфиг-файлы без опасения, что те будут затёрты при следующем обновлении системы. Такие казусы частенько происходят в SysV-init системах, где все init-сценарии свалены в одном каталоге /etc/rc.d/init.d/.

Некоторые юниты Systemd создаёт «на лету», так что вы не увидите их конфиг-файлов, хотя сами юниты будут в списке вывода утилиты systemctl. Например, вместе с запуском udev, для определённых устройств (вроде дисков, PCI-устройств и TTY) автоматически создаются соответствующие юниты, которые в правилах udev помечаются при помощи TAG+="systemd". Так же, как в случае с зависимостью сокетов и служб, некоторые юниты могут зависеть от других device-юнитов. Последние автоматически запускаются тогда, когда какому-то юниту требуется подключение к устройству. Такой подход используется также при работе со swap-юнитами. Эти юниты генерируются автоматически на основе информации из /etc/fstab и запускаются как только нужное swap-устройство будет доступно, конфигурируя таким образом системный swap. Кроме того, Systemd генерирует automount-юниты для остальных устройств, перечисленных в /etc/fstab, таким образом в итоге вывод systemctl покажет вам больше mount-юнитов, чем определено файлами конфигурации.

Цели

Файлы с суффиксами .target предназначены организованного запуска групп юнитов. Смысл работы целей очень сходен с работой классических уровней запуска (runlevels) в SysV-init. Например, multi-user.target запускает набор служб, эквивалентный набору runlevel 3 в Fedora и OpenSUSE. Другими словами, будут запущены все необходимые службы, кроме графического логин-менеджера, который традиционно запускается на runlevel 5. Эквивалентом пятому уровню в Systemd является цель graphical.target, которая обычно срабатывает по умолчанию.

В процессе загрузки системы Systemd активирует специальную цель с именем default.target. Обычно эта цель является символической ссылкой на multi-user.target или graphical.target. Цели, как и юниты, могут зависеть друг от друга: например, graphical.target будет ожидать запуска multi-user.target, прежде чем запустится логин-менеджер.

В случае необходимости можно явно определять зависимости между юнитами при помощи суффикса .wants. Это может быть актуально, например, при управлении веб-сервером Apache, которому для успешного запуска требуется настроенная сетевая подсистема. В подобной ситуации зависящий сервис будет зависеть от цели network.target. А вот такие сервисы, как Avahi и Bind подобной зависимостью не ограничены, поскольку самостоятельно умеют разбираться с появлением и пропаданием сетевых соединений во время работы.

Источник