Как создавать файлы модулей systemd

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

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

Для чего нужны модули systemd?

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

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

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

Некоторыми легко воплощаемыми функциами модулей могут быть:

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

У модулей 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 с тем же основным названием будет запущен при достижении модулем .path определенного состояния. Для мониторинга изменения модуля пути используется inotify.
    .timer: модуль .timer определяет таймер, управляемый systemd, схожий с заданием cron для отложенной или запланированной активации. При достижении таймера будет запущен связанный модуль.
    .snapshot: модуль .snapshot создается автоматически при выполнении команды systemctl snapshot. Он позволяет воссоздать текущее состояние системы после внесения изменений. Снимки действуют только во время сессии и используются для отката временного состояния.
    .slice: модуль .slice связан с узлами Linux Control Group, позволяя ограничивать ресурсы или выделять их любым процессам, связанным со срезом. Название отражает его позицию в иерархии дерева cgroup. модули размещаются в определенных срезах по умолчанию в зависимости от их типа.
    .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, no, off и false ждя отрицательного ответа).

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

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

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

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

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

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

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

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

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

Директивы раздела, специфичные для модулей

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

У типов модулей - устройство, цель, снимок и сфера - нет специфичных для типа модуля директив и связанных с ними разделов соответственно.

Раздел [Service]

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

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

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

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

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

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

    ExecStart=: она определяет полный путь и аргументы команды, которую нужно выполнить для старта процесса. Ее можно указать только один раз (кроме служб “oneshot”). Если путь к команде предваряется символом тире “-”, будут приняты ненулевые статусы выхода без обозначения активации модуля как неудачной.
    ExecStartPre=: с ее помощью можно установить дополнительные команды, которые должны быть выполнены до старта главного процесса. Ее можно использовать несколько раз. Опять же, команды должны определять полный путь и могут быть предварены символом “-” для указания допустимости неудачного выполнения команды.
    ExecStartPost=: эта директива схожа с ExecStartPre= за исключением того, что определеяет команды, выполняемые после старта главного процесса.
    ExecReload=: эта опциональная директива определяет команду, необходимую для перезагрузки конфигурации службы при ее доступности.
    ExecStop=: она определяет команду, необходимую для остановки службы. Если она не задана, процесс будет убит сразу же после остановки службы.
    ExecStopPost=: она может использоваться для определения команд, выполняемых после команды stop.
    RestartSec=: если включен автоматический перезапуск службы, она определяет время ожидания до попоытки перезапуска службы.
    Restart=: она определяет обстоятельства, при которых systemd будет пытаться автоматически перезапустить службу. Ее можно задать значениями “always”, “on-success”, “on-failure”, “on-abnormal”, “on-abort” или “on-watchdog”. Они запустят рестарт в соответствии с тем, как служба была остановлена.
    TimeoutSec=: она настраивает время, которое systemd будет ждать при запуске или остановке службы до того, как отметить ее как отказавшую или принудительно убить. Можно задать отдельные временные интервалы с помощью значений TimeoutStartSec= и TimeoutStopSec=.

Раздел [Socket]

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

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

Для указания текущего сокета есть общие директивы:

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

Есть и другие типы директив прослушивания, однако эти используются чаще всего.

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

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

Раздел [Mount]

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

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

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

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

Раздел [Automount]

Этот модуль позволяет связанному модулю .mount автоматически монтироваться при запуске. Как и с модулем .mount, его названием должен быть транслированный путь точки монтирования.
Раздел [Automount] очень простой, в нем могут быть только две следующие опции:

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

Раздел [Swap]

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

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

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

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

Раздел [Path]

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

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

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

Раздел [Timer]

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

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

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

Раздел [Slice]

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

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

    [Slice]
    [Scope]
    [Service]
    [Socket]
    [Mount]
    [Swap]

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

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

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

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

Шаблоны файлов модулей можно определить по наличию символа @ после основного названия модуля и до суффикса его типа. Шаблон файла модуля может называться примерно так:

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 оптимизировать параллельную инициализацию, но также сохраняет конфигурацию достаточно простой, позволяя вам изменять и перезапускать некоторые модули без срывов и пересоздания связанных с ними подключений. Использование этих возможностей может дать вам больше гибкости и возможностей при администрировании.

Источник: DigitalOcean