Поиск по сайту:

Понимание модулей Systemd и файлов модулей

Введение

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

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

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

Что дают вам Systemd Units?

Единицы — это объекты, которыми systemd умеет управлять. По сути, это стандартизированное представление системных ресурсов, которыми может управлять набор демонов и которыми можно манипулировать с помощью предоставленных утилит.

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

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

Вот некоторые функции, которые легко реализуются модулями:

  • Активация на основе сокетов. Сокеты, связанные со службой, лучше отделить от самого демона, чтобы обрабатывать их отдельно. Это дает ряд преимуществ, таких как отсрочка запуска службы до тех пор, пока не будет осуществлен первый доступ к соответствующему сокету. Это также позволяет системе создавать все сокеты на ранней стадии процесса загрузки, что позволяет параллельно загружать связанные службы.
  • Активация на основе шины: Устройства также можно активировать через шинный интерфейс, предоставляемый D-Bus. Устройство можно запустить, когда опубликована соответствующая шина.
  • Активация на основе пути: модуль можно запустить на основе активности или доступности определенных путей файловой системы. При этом используется inotify.
  • активация на основе устройства. Модули также можно запускать при первой доступности соответствующего оборудования, используя события udev.
  • неявное сопоставление зависимостей: большая часть дерева зависимостей для модулей может быть построена самим systemd. Вы по-прежнему можете добавлять информацию о зависимостях и порядке, но большая часть тяжелой работы ложится на вас.
  • Экземпляры и шаблоны. Файлы модулей-шаблонов можно использовать для создания нескольких экземпляров одного и того же общего модуля. Это позволяет использовать небольшие вариации или одноуровневые блоки, которые выполняют одну и ту же общую функцию.
  • простое усиление безопасности: модули могут реализовывать некоторые довольно хорошие функции безопасности, добавляя простые директивы. Например, вы можете запретить или разрешить доступ только для чтения к части файловой системы, ограничить возможности ядра и назначить частный /tmp и сетевой доступ.
  • вставки и фрагменты. Модули можно легко расширить, предоставив фрагменты, которые переопределяют части системного файла модуля. Это позволяет легко переключаться между стандартной и индивидуальной реализацией модулей.

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

Где находятся файлы модулей Systemd?

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

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

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

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

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

Правильный способ сделать это — создать каталог с именем файла модуля с добавлением .d в конце. Таким образом, для единицы с именем example.service можно создать подкаталог с именем example.service.d. В этом каталоге файл, оканчивающийся на .conf, может использоваться для переопределения или расширения атрибутов файла системного модуля.

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

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

Типы юнитов

Systemd классифицирует блоки в соответствии с типом описываемого ими ресурса. Самый простой способ определить тип модуля — это использовать суффикс типа, который добавляется в конец имени ресурса. В следующем списке описаны типы единиц измерения, доступные для systemd:

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

.socket: файл модуля сокета описывает сетевой или IPC-сокет, или буфер FIFO, который systemd использует для активации на основе сокета. У них всегда есть связанный файл .service, который будет запускаться при обнаружении активности на сокете, который определяет этот модуль.

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

.mount: этот модуль определяет точку монтирования в системе, которой будет управлять systemd. Они названы в честь пути монтирования, косая черта заменена на тире. Записи в /etc/fstab могут иметь единицы, созданные автоматически.

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

.swap: этот модуль описывает пространство подкачки в системе. Имя этих единиц должно отражать устройство или путь к файлу пространства.

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

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

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

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

.slice: модуль .slice связан с узлами группы управления Linux, что позволяет ограничивать ресурсы или назначать их любым процессам, связанным с фрагментом. Имя отражает его иерархическое положение в дереве cgroup. По умолчанию юниты размещаются в определенных слайсах в зависимости от их типа.

.scope: единицы Scope автоматически создаются systemd из информации, полученной от его шинных интерфейсов. Они используются для управления наборами системных процессов, созданных извне.

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

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

Анатомия юнит-файла

Внутренняя структура юнит-файлов состоит из разделов. Разделы обозначаются парой квадратных скобок \[” и \]” с заключенным внутри именем раздела. Каждый раздел продолжается до начала следующего раздела или до конца файла.

Общие характеристики юнит-файлов

Имена разделов четко определены и чувствительны к регистру. Таким образом, секция [Unit] не будет правильно интерпретирована, если она написана как [UNIT]. Если вам нужно добавить нестандартные разделы для анализа приложениями, отличными от systemd, вы можете добавить префикс X- к имени раздела.

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

[Section]
Directive1=value
Directive2=value

. . .

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

Directive1=default_value

default_value можно удалить в файле переопределения, сославшись на Directive1 без значения, например:

Directive1=

В общем, systemd обеспечивает простую и гибкую настройку. Например, допускается несколько логических выражений (1, yes, on и true для утвердительных и 0, нет off и false для противоположного ответа). Время можно анализировать разумно, принимая секунды за безразмерные значения и комбинируя несколько форматов, выполняемых внутри.

Директивы раздела [Unit]

Первым разделом в большинстве файлов модулей является раздел [Unit]. Обычно это используется для определения метаданных для единицы и настройки отношения единицы к другим единицам.

Хотя порядок разделов не имеет значения для systemd при синтаксическом анализе файла, этот раздел часто помещается вверху, потому что он предоставляет обзор модуля. Некоторые общие директивы, которые вы найдете в разделе [Unit]:

  • Description=: эта директива может использоваться для описания имени и основных функций устройства. Его возвращают различные инструменты systemd, поэтому лучше указать что-то короткое, конкретное и информативное.
  • Documentation=: эта директива предоставляет место для списка URI для документации. Это могут быть внутренние страницы man или URL-адреса, доступные в Интернете. Команда systemctl status предоставит эту информацию, чтобы ее было легко обнаружить.
  • Requires=: эта директива перечисляет все модули, от которых существенно зависит данный модуль. Если текущий юнит активирован, перечисленные здесь юниты также должны успешно активироваться, иначе этот юнит выйдет из строя. По умолчанию эти блоки запускаются параллельно с текущим блоком.
  • Wants=: эта директива похожа на Requires=, но менее строгая. Systemd попытается запустить любые перечисленные здесь юниты, когда этот юнит будет активирован. Если эти блоки не будут найдены или не запустятся, текущий блок будет продолжать функционировать. Это рекомендуемый способ настройки большинства отношений зависимости. Опять же, это подразумевает параллельную активацию, если только это не изменено другими директивами.
  • BindsTo=: эта директива похожа на Requires=, но также приводит к остановке текущего модуля при завершении работы связанного модуля.
  • Before=: устройства, перечисленные в этой директиве, не будут запущены до тех пор, пока текущее устройство не будет помечено как запущенное, если они будут активированы одновременно. Это не подразумевает отношения зависимости и должно использоваться в сочетании с одной из вышеуказанных директив, если это желательно.
  • After=: устройства, перечисленные в этой директиве, будут запущены до запуска текущего устройства. Это не подразумевает отношений зависимости, и если это требуется, то их необходимо установить с помощью вышеуказанных директив.
  • Конфликты=: можно использовать для списка модулей, которые не могут быть запущены одновременно с текущим модулем. Запуск блока с этим отношением приведет к остановке других блоков.
  • Condition...=: существует ряд директив, начинающихся с Condition, которые позволяют администратору проверить определенные условия перед запуском модуля. Это можно использовать для предоставления универсального файла модуля, который будет запускаться только в соответствующих системах. Если условие не выполняется, модуль корректно пропускается.
  • Assert...=: Подобно директивам, начинающимся с Condition, эти директивы проверяют различные аспекты рабочей среды, чтобы решить, следует ли активировать модуль. Однако, в отличие от директив Condition, отрицательный результат приводит к сбою этой директивы.

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

[Установить] Директивы раздела

На противоположной стороне файла модуля последним разделом часто является раздел [Install]. Этот раздел является необязательным и используется для определения поведения или модуля, если он включен или отключен. Включение модуля означает, что он будет автоматически запускаться при загрузке. По сути, это достигается путем привязки рассматриваемого устройства к другому устройству, которое находится где-то в ряду устройств, запускаемых при загрузке.

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

  • WantedBy=. Директива WantedBy= — это наиболее распространенный способ указать, как должен включаться модуль. Эта директива позволяет указать отношение зависимости аналогично директиве Wants= в разделе [Unit]. Разница в том, что эта директива включена в вспомогательный блок, что позволяет первичному блоку оставаться относительно чистым. Когда модуль с этой директивой включен, в /etc/systemd/system будет создан каталог с именем указанного модуля с добавлением .wants в конец. При этом будет создана символическая ссылка на текущий модуль, создающая зависимость. Например, если текущий объект имеет WantedBy=multi-user.target, в /etc/ будет создан каталог с именем multi-user.target.wants. systemd/system (если он еще не доступен), и внутри него будет размещена символическая ссылка на текущий модуль. При отключении этого блока удаляется ссылка и удаляется отношение зависимости.
  • RequiredBy=: эта директива очень похожа на директиву WantedBy=, но вместо этого указывает обязательную зависимость, которая приведет к сбою активации, если она не будет выполнена. Если эта функция включена, модуль с этой директивой создаст каталог, оканчивающийся на .requires.
  • Alias=: эта директива позволяет использовать устройство под другим именем. Помимо прочего, это позволяет использовать несколько поставщиков функции, чтобы соответствующие подразделения могли искать любого поставщика с общим псевдонимом.
  • Also=: эта директива позволяет включать и отключать блоки как набор. Вспомогательные юниты, которые всегда должны быть доступны, когда этот юнит активен, могут быть перечислены здесь. Они будут управляться как группа для задач установки.
  • DefaultInstance=: для единиц шаблона (описанных ниже), которые могут создавать экземпляры единиц с непредсказуемыми именами, это можно использовать в качестве резервного значения для имени, если подходящее имя не указано.

Директивы разделов для конкретных модулей

Между двумя предыдущими разделами вы, скорее всего, найдете разделы, посвященные конкретным типам юнитов. Большинство типов юнитов предлагают директивы, которые применяются только к их конкретному типу. Они доступны в разделах, названных в соответствии с их типом. Мы кратко рассмотрим их здесь.

Типы устройств device, target, snapshot и scope не имеют специфичных для устройства директив и, следовательно, не имеют связанные разделы для их типа.

Раздел [Сервис]

Раздел [Service] используется для предоставления конфигурации, применимой только для служб.

Одной из основных вещей, которые следует указать в разделе [Service], является Type= службы. Это классифицирует службы по их процессам и поведению демонизации. Это важно, поскольку сообщает systemd, как правильно управлять сервисом и узнавать его состояние.

Директива Type= может быть одной из следующих:

  • простой: основной процесс службы указан в стартовой строке. Это значение по умолчанию, если директивы Type= и Busname= не установлены, но задан ExecStart=. Любая связь должна осуществляться за пределами модуля через второй модуль соответствующего типа (например, через модуль .socket, если этот модуль должен обмениваться данными с использованием сокетов).
  • разветвление: этот тип службы используется, когда служба разветвляет дочерний процесс, почти сразу же выходя из родительского процесса. Это сообщает systemd, что процесс все еще выполняется, несмотря на то, что родительский процесс завершился.
  • oneshot: этот тип указывает, что процесс будет недолговечным и что systemd должен дождаться завершения процесса, прежде чем продолжить работу с другими модулями. Это значение по умолчанию Type= и ExecStart= не установлены. Он используется для разовых задач.
  • dbus: указывает, что устройство получит имя на шине D-Bus. Когда это произойдет, systemd продолжит обработку следующего модуля.
  • notify: указывает, что служба выдаст уведомление после завершения запуска. Процесс systemd будет ждать, пока это произойдет, прежде чем перейти к другим модулям.
  • idle: указывает, что служба не будет запущена, пока не будут отправлены все задания.

При использовании определенных типов служб могут потребоваться некоторые дополнительные директивы. Например:

  • RemainAfterExit=: эта директива обычно используется с типом oneshot. Это указывает на то, что службу следует считать активной даже после завершения процесса.
  • PIDFile=: если тип службы помечен как «разветвление», эта директива используется для установки пути к файлу, который должен содержать идентификационный номер основного дочернего процесса, который должен быть отслеживается.
  • BusName=: в этой директиве должно быть указано имя шины D-Bus, которое служба будет пытаться получить при использовании типа службы \dbus.
  • NotifyAccess=: указывает доступ к сокету, который следует использовать для прослушивания уведомлений, когда выбран тип службы «уведомление». Это может быть «нет», «основной», или все. Значение по умолчанию, \none, игнорирует все сообщения о состоянии. Параметр main будет прослушивать сообщения от основного процесса, а параметр all приведет к обработке всех членов контрольной группы службы.

До сих пор мы обсуждали некоторую предварительную информацию, но на самом деле мы не определили, как управлять нашими службами. Директивы для этого:

  • ExecStart=: указывает полный путь и аргументы команды, которая должна быть выполнена для запуска процесса. Это можно указать только один раз (кроме служб «oneshot»). Если перед путем к команде стоит символ тире «-», ненулевые статусы выхода будут приниматься без пометки активации объекта как неудачная.< /li>
  • ExecStartPre=: это можно использовать для предоставления дополнительных команд, которые должны быть выполнены до запуска основного процесса. Это можно использовать несколько раз. Опять же, команды должны указывать полный путь, и им может предшествовать \-, чтобы указать, что сбой команды допустим.
  • ExecStartPost=: обладает теми же качествами, что и ExecStartPre=, за исключением того, что указывает команды, которые будут выполняться после основного процесса. началось.
  • ExecReload=: эта необязательная директива указывает команду, необходимую для перезагрузки конфигурации службы, если она доступна.
  • ExecStop=: указывает команду, необходимую для остановки службы. Если это не указано, процесс будет немедленно остановлен при остановке службы.
  • ExecStopPost=: можно использовать для указания команд, которые должны выполняться после команды остановки.
  • RestartSec=: если включен автоматический перезапуск службы, здесь указывается время ожидания перед попыткой перезапуска службы.
  • Restart=: указывает обстоятельства, при которых systemd попытается автоматически перезапустить службу. Для этого можно установить такие значения, как «всегда», «при успехе», «при сбое», «при ненормальном», «при прерывании» или «при сторожевом таймере». Это вызовет перезапуск в соответствии с тем, как служба была остановлена.
  • TimeoutSec=: настраивает количество времени, в течение которого systemd будет ждать при остановке или остановке службы, прежде чем пометить ее как неисправную или принудительно убить. Вы также можете установить отдельные тайм-ауты с помощью TimeoutStartSec= и TimeoutStopSec=.

Раздел [Сокет]

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

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

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

  • ListenStream=: определяет адрес потокового сокета, который поддерживает последовательную и надежную связь. Службы, использующие TCP, должны использовать этот тип сокета.
  • ListenDatagram=: определяет адрес сокета дейтаграмм, который поддерживает быстрые и ненадежные коммуникационные пакеты. Службы, использующие UDP, должны установить этот тип сокета.
  • ListenSequentialPacket=: определяет адрес для последовательной надежной связи с дейтаграммами максимальной длины, сохраняющими границы сообщений. Это чаще всего встречается для сокетов Unix.
  • ListenFIFO: наряду с другими типами прослушивания вы также можете указать буфер FIFO вместо сокета.

Существует больше типов директив слушания, но вышеперечисленные являются наиболее распространенными.

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

  • Accept=: определяет, будет ли запускаться дополнительный экземпляр службы для каждого подключения. Если установлено значение false (по умолчанию), один экземпляр будет обрабатывать все соединения.
  • SocketUser=: для сокета Unix указывает владельца сокета. Это будет пользователь root, если его не установить.
  • SocketGroup=: для сокета Unix указывает группу-владельца сокета. Это будет корневая группа, если ни это, ни вышеперечисленное не установлены. Если задан только SocketUser=, systemd попытается найти соответствующую группу.
  • SocketMode=: для сокетов Unix или буферов FIFO устанавливает разрешения для созданного объекта.
  • Service=: если имя службы не совпадает с именем .socket, служба может быть указана с помощью этой директивы.

Раздел [Mount]

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

Например, начальный слэш удаляется, все остальные слэши преобразуются в тире \-, а все тире и непечатаемые символы заменяются escape-кодами в стиле C. Результат такого преобразования используется в качестве имени модуля монтирования. юниты будут иметь неявную зависимость от других монтирований над ним в иерархии.

Модули монтирования часто транслируются непосредственно из файлов /etc/fstab в процессе загрузки. Для автоматически созданных определений юнитов и тех, которые вы хотите определить в файле юнитов, полезны следующие директивы:

  • What=: абсолютный путь к ресурсу, который необходимо смонтировать.
  • Where=: абсолютный путь к точке монтирования, в которую должен быть смонтирован ресурс. Оно должно совпадать с именем файла модуля, за исключением использования обычной нотации файловой системы.
  • Type=: тип файловой системы монтирования.
  • Options=: любые параметры монтирования, которые необходимо применить. Это список, разделенный запятыми.
  • SloppyOptions=: логическое значение, определяющее, произойдет ли монтирование со сбоем, если есть нераспознанный параметр монтирования.
  • DirectoryMode=: если для точки подключения необходимо создать родительские каталоги, это определяет режим разрешений для этих каталогов.
  • TimeoutSec=: настраивает время, в течение которого система будет ждать, пока операция монтирования не будет отмечена как неудачная.

Раздел [Автомонтирование]

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

Раздел [Automount] довольно прост, разрешены только следующие два параметра:

  • Where=: абсолютный путь к точке автоматического монтирования в файловой системе. Это будет соответствовать имени файла, за исключением того, что вместо перевода используется обычная запись пути.
  • DirectoryMode=: если необходимо создать точку автоматического монтирования или какие-либо родительские каталоги, это определит параметры разрешений для этих компонентов пути.

Раздел [Обмен]

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

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

Раздел [Swap] юнит-файла может содержать следующие директивы для конфигурации:

  • What=: абсолютный путь к месту подкачки, будь то файл или устройство.
  • Priority=: принимает целое число, указывающее приоритет настраиваемого обмена.
  • Options=: с помощью этой директивы можно задать любые параметры, которые обычно задаются в файле /etc/fstab. Используется список, разделенный запятыми.
  • TimeoutSec=: количество времени, в течение которого systemd ожидает активации свопа, прежде чем пометить операцию как неудачную.

Раздел [Путь]

Блок пути определяет путь к файловой системе, который systmed может отслеживать на наличие изменений. Должен существовать другой модуль, который будет активирован при обнаружении определенной активности в местоположении пути. Активность пути определяется через события inotify.

Раздел [Path] юнит-файла может содержать следующие директивы:

  • PathExists=: эта директива используется для проверки существования рассматриваемого пути. Если это так, связанный блок активируется.
  • PathExistsGlob=: то же самое, что и выше, но поддерживает выражения файлового шаблона для определения существования пути.
  • PathChanged=: отслеживает изменение пути. Связанный блок активируется, если при закрытии отслеживаемого файла обнаруживается изменение.
  • PathModified=: следит за изменениями, как и указанная выше директива, но активируется при записи в файл, а также при закрытии файла.
  • DirectoryNotEmpty=: эта директива позволяет systemd активировать связанный модуль, когда каталог больше не пуст.
  • Unit=: указывает блок, который нужно активировать, когда выполняются условия пути, указанные выше. Если это значение опущено, systemd будет искать файл .service с тем же именем базового модуля, что и у этого модуля.
  • MakeDirectory=: определяет, будет ли systemd создавать структуру каталогов рассматриваемого пути перед просмотром.
  • DirectoryMode=: если указанный выше параметр включен, будет установлен режим разрешений для всех компонентов пути, которые должны быть созданы.

Раздел [Таймер]

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

Раздел [Timer] юнит-файла может содержать некоторые из следующих директив:

  • OnActiveSec=: эта директива позволяет активировать связанный блок относительно активации блока .timer.
  • OnBootSec=: эта директива используется для указания периода времени после загрузки системы, когда должен быть активирован соответствующий модуль.
  • OnStartupSec=: эта директива похожа на указанный выше таймер, но в отношении того, когда был запущен сам процесс systemd.
  • OnUnitActiveSec=: устанавливает таймер в зависимости от того, когда в последний раз была активирована соответствующая единица.
  • OnUnitInactiveSec=: устанавливает таймер в зависимости от того, когда связанный блок в последний раз был помечен как неактивный.
  • OnCalendar=: это позволяет вам активировать связанный блок, указав абсолютное, а не относительное значение события.
  • AccuracySec=: эта единица используется для установки уровня точности, с которой следует придерживаться таймера. По умолчанию связанный блок будет активирован в течение одной минуты после достижения таймера. Значение этой директивы будет определять верхние границы окна, в котором systemd планирует активацию.
  • Unit=: эта директива используется для указания устройства, которое должно быть активировано по истечении таймера. Если не задано, systemd будет искать модуль .service с именем, совпадающим с этим модулем.
  • Persistent=: если это установлено, systemd будет запускать связанный модуль, когда таймер становится активным, если он должен был быть запущен в течение периода, в котором таймер был активирован. неактивен.
  • WakeSystem=: установка этой директивы позволяет вывести систему из режима ожидания, если таймер находится в этом состоянии.

Раздел [Срез]

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

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

  • [Срез]
  • [Область применения]
  • [Сервис]
  • [Сокет]
  • [Крепление]
  • [Поменять местами]

Создание экземпляров единиц из файлов шаблонов единиц

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

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

Имена шаблонов и экземпляров единиц

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

example@.service

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

example@instance1.service

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

Спецификаторы шаблона

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

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

  • %n: везде, где это встречается в файле шаблона, будет вставлено полное имя результирующего модуля.
  • %N: то же самое, что и выше, но любое экранирование, например присутствующее в шаблонах пути к файлу, будет отменено.
  • %p: ссылается на префикс имени устройства. Это часть названия объекта, предшествующая символу @.
  • %P: то же самое, что и выше, но с обратным кодированием.
  • %i: ссылается на имя экземпляра, которое является идентификатором, следующим за @ в единице экземпляра. Это один из наиболее часто используемых спецификаторов, поскольку он гарантированно будет динамическим. Использование этого идентификатора поощряет использование идентификаторов, важных для конфигурации. Например, порт, на котором будет запущена служба, может использоваться в качестве идентификатора экземпляра, а шаблон может использовать этот спецификатор для настройки спецификации порта.
  • %I: этот спецификатор такой же, как и указанный выше, но с обратным кодированием.
  • %f: будет заменено неэкранированным именем экземпляра или именем префикса, перед которым стоит /.
  • %c: это указывает на контрольную группу объекта, при этом стандартная родительская иерархия /sys/fs/cgroup/ssytemd/ удалена.
  • %u: имя пользователя, сконфигурированного для запуска модуля.
  • %U: то же, что и выше, но в виде числового UID вместо имени.
  • %H: имя хоста системы, на которой работает модуль.
  • %%: используется для вставки буквального знака процента.

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

Заключение

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

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