Понимание системных единиц и файлов модулей

Вступление

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

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

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

Что дают вам системные блоки?

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

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

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

Некоторые функции, которые единицы могут легко реализовать:

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

Есть много других преимуществ, которые модули + 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 Control Group, что позволяет ограничивать ресурсы или назначать их любым процессам, связанным со слайсом. Имя отражает его иерархическую позицию в дереве + cgroup +. Единицы размещены в определенных срезах по умолчанию в зависимости от их типа.
* + .scope + *: Единицы области создаются автоматически с помощью + systemd + из информации, полученной из ее шинных интерфейсов. Они используются для управления наборами системных процессов, которые создаются извне.

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

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

Анатомия файла блока

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

Общие характеристики файлов модулей

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

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

[]
=
=

. . .

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

+ Default_value + можно удалить в файле переопределения, ссылаясь на ++ без значения, например так:

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

[Блок] Раздел Директивы

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

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

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

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

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

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

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

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

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

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

Типы + device,` + target`, + snapshot и` + scope of` не имеют директив, относящихся к конкретным единицам, и, следовательно, не имеют связанных разделов для своего типа.

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

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

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

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

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

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

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

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

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

Секция [Socket]

Сокетные блоки очень распространены в конфигурациях `+ 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 = + *: Абсолютный путь к ресурсу, который необходимо смонтировать.
* + Где = + *: Абсолютный путь к точке монтирования, где должен быть смонтирован ресурс. Это должно совпадать с именем файла модуля, за исключением использования условных обозначений файловой системы.
* + Type = + *: тип файловой системы монтирования.
* + Options = + *: Любые параметры монтирования, которые необходимо применить. Это список через запятую.
* + SloppyOptions = + *: логическое значение, определяющее, не удастся ли монтировать, если есть нераспознанная опция монтирования.
* + DirectoryMode = + *: Если для точки монтирования необходимо создать родительские каталоги, это определяет режим разрешения этих каталогов.
* + TimeoutSec = + *: Настраивает время, в течение которого система будет ждать, пока операция монтирования не будет помечена как неудачная.

Раздел [Automount]

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

Секция + [Automount] + довольно проста, допускаются только следующие две опции:

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

Раздел [Swap]

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

Как и параметры монтирования, модули подкачки могут быть автоматически созданы из записей + / 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 +. Они действительны в следующих разделах, относящихся к единице:

'+ [Фрагмент] + `
+ [Scope] +
+ [Service] +
'+ [Гнездо] + `
+ [Гора] +
+ [Обмен] +

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

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

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

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

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

[email protected]

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

[email protected]

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

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

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

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

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

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

Заключение

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

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

TOC