Какие типы юнит файлов unit files поддерживает демон systemd

Обновлено: 15.01.2025

Файл юнита содержит директивы, которые описывают юнит и определяют его поведение. Некоторые команды systemctl работают с файлами юнитов в фоновом режиме. Чтобы произвести более детальную настройку, системный администратор должен отредактировать или создать файл юнита вручную. В Таблице 10.2 «Расположение файлов юнитов systemd » перечислены три основных директории, в которых хранятся файлы юнитов системы. Каталог /etc/systemd/system/ зарезервирован для юнитов, созданных или настроенных системным администратором.
Имена файлов имеют следующий вид:

10.6.1 Понимание структуры файла юнита

Файлы юнитов обычно содержат три секции:

Таблица 10.9, Важные параметры секции [Unit]

Опция [a]	Описание
Description	Информативное описание юнита. Эта информация отображается, например, в выводе команды systemctl status
Documentation	Предоставляет список URI (Uniform Resource Identifier — унифицированный идентификатор ресурса), ссылающийся на документацию для юнита.
After [b]	Определяет порядок запуска юнитов. Юнит запускается только после того, как активированы юниты, указанные в After . В отличие от Requires , After не активирует явно определенные юниты. Опция Before имеет противоположную функциональность After .
Requires	Настраивает зависимости от других юнитов. Юниты, перечисленные в разделе Requires , активируются вместе с юнитом. Если какой-либо из необходимых юнитов не запускается, юнит не активируется.
Wants	Настраивает более слабые зависимости, чем Requires . Если какой-либо из перечисленных юнитов не запускается, он не влияет на активацию данного юнита. Это рекомендуемый способ установки зависимостей пользовательских юнитов.
Conflicts	Настраивает отрицательные зависимости, противоположные Requires .
[a] Полный список параметров, настраиваемых в разделе [Unit], см. в man systemd.unit (5).
[b] В большинстве случаев, достаточно устновить зависимости с опциями After и Before . Если вы также установили зависимость от требований Wants (рекомендуется) или Requires , зависимости последовательности все еще должны быть определены. Связано это с тем, что зависимости упорядочения и требований работают раздельно.

simple – Значение по умолчанию. Процесс стартующий с ExecStart, является основным процессом сервиса.
forking – Процесс, запущенный с ExecStart, порождает дочерний процесс, который становится основным процессом сервиса. После завершения запуска родительский процесс завершается.
oneshot – Этот тип похож на simple, но процесс завершается до запуска последующих юнитов.
dbus – Этот тип похож на simple, но последующие юниты запускаются только после того, как основной процесс получает D-Bus имя.
notify – похож на simple, но последующие юниты запускаются только после отправвки уведомления посредством функции sd_notify().
idle – похож на simple, фактическое выполнение сервиса задерживается до завершения всех заданий, что позволяет избежать смешивания потока вывода состояния с выводом сервиса.

Таблица 10.11, Важные параметры секции [Install]

Опция [a]	Описание
Alias	Предоставляет список дополнительных имен для юнита, разделенных побелами. Большая часть команд systemctl , за исключением systemctl enable , может использовать алиасы вместо фактического имени юнита.
RequiredBy	Список юнитов, которые зависят от этого юнита. Когда этот юнит включен, юниты перечисленные в RequiredBy gain a Require dependency on the unit.
WantedBy	Список юнитов, которые слабо зависят от этого юнита. Когда этот юнит включен, юниты перечисленные в WantedBy gain a Want dependency on the unit.
Also	Указывает список юнитов, которые будут установлены или удалены вместе с юнитом.
DefaultInstance	Ограничена конкретным юнитом, эта опция определяет экземпляр по умолчанию для которого активирован юнит. См. раздел 10.6.5, “Работа с юнитами, созданными из шаблона (Instantiated Units)”
[a] Полный список параметров, настраиваемых в разделе [Install], см. в man systemd.unit (5).

Пример 10.17, «Юнит-файл postfix.service» показывает пример сервисного юнита, установленного в системе. Кроме того, параметры файла юнита могут быть определены таким образом, чтобы обеспечить динамическое создание юнитов, как описано в Разделе 10.6.5 «Работа с юнитами, созданными из шаблона (Instantiated Units)».

Пример 10.17. Юнит-файл postfix.service

Ниже представлено содержание файла юнита /usr/lib/systemd/system/postifix.service :

[Unit] Description=Postfix Mail Transport Agent After=syslog.target network.target Conflicts=sendmail.service exim.service [Service] Type=forking PIDFile=/var/spool/postfix/pid/master.pid EnvironmentFile=-/etc/sysconfig/network ExecStartPre=-/usr/libexec/postfix/aliasesdb ExecStartPre=-/usr/libexec/postfix/chroot-update ExecStart=/usr/sbin/postfix start ExecReload=/usr/sbin/postfix reload ExecStop=/usr/sbin/postfix stop [Install] WantedBy=multi-user.target

Секция [Unit] описывает сервис, определяет зависимости, а также конфликтующие юниты. В [Service] указывается последовательность пользовательских скриптов, которые должны выполняться во время активации юнита, остановки и перезагрузки. EnvironmentFile указывает на место, где определены переменные среды для сервиса, PIDFile задает PID для основного процесса сервиса. Наконец, в разделе [Install] перечислены зависимости.

10.6.2. Создание пользовательских файлов юнитов

Существует несколько способов создания файлов юнитов с нуля: вы можете запустить собственны демон, создать второй экземпляр какой-либо существующей службы (как в примере 10.19, «Создание второго экземпляра службы sshd») или импортировать скрипт инициализации SysV (см. в разделе 10.6.3, «Преобразование сценариев инициализации SysV в файлы модулей»). С другой стороны, если вы намереваетесь просто изменить или расширить поведение существующего юнита, используйте инструкции из раздела 10.6.4, «Изменение существующих файлов модуля». Следующая процедура описывает общий процесс создания пользовательского юнита:

Подготовьте исполняемый файл с помощью пользовательского сервиса. Это может быть пользовательский скрипт или исполняемый файл, предоставленный поставщиком программного обеспечения. При необходимости подготовьте PID-файл для хранения постоянного PID основного процесса пользовательской службы. Также можно включить файлы среды для хранения переменных оболочки для сервиса. (It is also possible to include environment files to store shell variables for the service.) Убедитесь, что исходный скрипт является исполняемым (выполнив команду chmod a+x ) и не является интерактивным.
Создайте файл юнита в директории /etc/systemd/system/ и убедитесь, что он имеет корректные права доступа. Выполните от рута:

touch /etc/systemd/system/name.service chmod 664 /etc/systemd/system/name.service

[Unit] Description=service_description After=network.target [Service] ExecStart=path_to_executable Type=forking PIDFile=path_to_pidfile [Install] WantedBy=default.target

systemctl daemon-reload systemctl start name.service

Пример 10.18. Создание файла emacs.service

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

[Unit] Description=Emacs: the extensible, self-documenting text editor [Service] Type=forking ExecStart=/usr/bin/emacs --daemon ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)" Environment=SSH_AUTH_SOCK=%t/keyring/ssh Restart=always [Install] WantedBy=default.target

Пример 10.19. Создание второго экземпляра службы sshd

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

Systemd - это новый сервис в Red Hat Enterprise Linux 7, который отвечает за запуск всех видов вещей. Systemd выходит далеко за рамки запуска сервисов; другие элементы также запускаются из systemd.

В этой статье раскроем сам systemd и юнит-файлы.

Понимание systemd

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

Чтобы отобразить список всех доступных юнитов, введите systemctl -t help
Основное преимущество работы с systemd по сравнению с предыдущими методами, используемыми для управления сервисами, заключается в том, что он обеспечивает единый интерфейс для запуска юнитов. Этот интерфейс определен в файле юнита.

Системные юнит-файлы. Это юниты из установленных пакетов RPM — всякие nginx, apache, mysql и прочее.

Юниты, созданные нами, то есть админами. Переопределяют значения юнит-файлов по умолчанию. Юнит-файлы по умолчанию описаны выше.

runtime-юниты, которые генерируются автоматически.

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

Юнит-файл на примере vsftpd:
Из этого примера юнит-файла видно, что его относительно легко понять. Любой файл сервисного юнита systemd состоит из трех секций. (В других файл-юнитах могут быть другие секции, но эти три присутствуют во всех юнит-файлах.)

ExecStart - запустить юнит;
ExecStop - остановить юнит;
ExecReload - перезапустить юнит.

Далее идёт секция [Mount] , которая определяет, что и где надо монтировать. В этой секции четко видно, что будет выполнена команда mount , которую вы обычно вводите в терминале.

Наконец, есть оператор WantedBy, который определяет, где должен быть запущен юнит.

Юнит socket

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

Пример файла сокета показывает, как это происходит для virtlockd, системного сокета, который отслеживает активность для виртуальных машин.
При работе с файл-юнитами systemd вы рискуете оказаться перегруженными опциями.
Каждый файл-юнит может быть настроен с различными параметрами. Чтобы выяснить, какие параметры доступны для конкретного юнита, используйте команду systemctl show . Например, команда systemctl show sshd показывает все параметры systemd , которые можно настроить в юните sshd.service , включая их текущие значения по умолчанию.

Понимание целевых юнитов

Юнит-файлы используются для создания функциональности, необходимой на вашем сервере. Чтобы можно было загружать их в правильном порядке и в нужный момент, используется определенный тип юнитов: целевой юнит. Простое определение целевого юнита- это «группа юнитов». Некоторые цели используются как эквиваленты старых уровней выполнения, которые в более ранних версиях RHEL использовались для определения состояния, в котором должен запускаться сервер.
Уровень запуска - это набор сервисов, необходимых для запуска сервера в многопользовательском или графическом режиме. Хорошей отправной точкой для понимания юнитов целей является их видение как группы юнитов.

Вы можете видеть, что сам по себе целевой юнит не содержит много определений. Он просто определяет, что ему требуется, и с какими сервисами целями он не может сосуществовать. Он также определяет порядок загрузки с помощью оператора After в разделе Unit . И вы можете видеть, что в разделе «Install» он определен как default.target , поэтому ваш сервер запускается по умолчанию. Целевой файл-юнит не содержит никакой информации о юнитах, которые должны быть включены; это находится в отдельных файлах юнита и секции Wants .

Даже если цель systemd немного похожа на старые уровни запуска, это нечто большее. Цель - это группа юнитов, и существует несколько различных целей. Некоторые цели, такие как multi-user.target и graphical.target , определяют конкретное состояние, в которое должна войти система. Другие цели просто объединяют группу юнитов, например, nfs.target и printer.target . Эти цели включены из других целей, таких как многопользовательские или графические цели.

Понимание Wants

Чтобы понять концепцию желания (Want), давайте начнем смотреть на глагол потребности, как в «Я хочу печенье». Want в systemd определяет, какие единицы systemd он хочет при запуске определенной цели. Want создаются, когда юниты включены в systemd , и это происходит путем создания символической ссылки в каталоге /etc/systemd/system . В этом каталоге вы найдете подкаталог для каждой цели, содержащий в качестве символических ссылок ссылки на конкретные сервисы, которые должны быть запущены.

Во второй части статьи о systemd разберемся, как управлять юнитами, зависимостями и целями.

Что дадут вам Systemd юниты?

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

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

Активация на основе сокетов: Сокеты, связанные с сервисом, лучше всего вырываются из самого демона, чтобы обрабатываться отдельно. Это дает ряд преимуществ,- например, задержка запуска службы до тех пор, пока соответствующий сокет не будет доступен. Это также позволяет системе создавать все сокеты до начала запуска процесса, что позволяет параллельно загружать связанные службы.
Активация на основе шины: Unit-ы также могут быть активированы на интерфейсе шины, предоставляемом D-Bus-ом. Устройство может быть запущено когда соответствующая шина доступна.
Активация на основе пути: Unit может быть запущен на основе активности или наличия определенных путей к файловой системе. Это использует inotify.
Активация на основе устройства: Unit-ы также могут быть запущены при первой доступности (подключении) связанного оборудования за счет использования событий udev.
Неявное сопоставление зависимостей: Большая часть структуры зависимостей для юнитов может быть построена самой системой. Вы все равно можете добавить информацию о зависимостях, но большая часть тяжелой работы будет решена за вас.
Экземпляры и шаблоны: Файлы блока шаблонов могут использоваться для создания нескольких экземпляров одного и того же общего устройства. Это позволяет создавать небольшие вариации или единичные unit-ы, которые обеспечивают одну и ту же общую функцию.
Простое упрощение безопасности: Юниты могут реализовать некоторые довольно хорошие функции безопасности, добавив простые директивы. Например, вы можете указать какой доступ можно использовать ( чтение, запись) при работе с файловой системой, ограничить возможности ядра, установить приватный /tmp фолдер и сетевой доступ.
Drop-ins и snippets: Units можно легко расширить, предоставив фрагменты, которые будут отменять части файла системы. Это позволяет легко переключаться между vanilla и индивидуальными реализациями.

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

Как я могу найти/ Где находятся Systemd Unit в Unix/Linux?

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

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

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

Также есть место для определения run-time unit-ов в /run/systemd/system. Файлы, найденные в этом каталоге, имеют приоритет между /etc/systemd/system и/lib/systemd/system.

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

Типы systemd Unit файлов

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

Структура systemd Unit файлов

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

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

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

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

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

Сейчас рассмотрим каждый из юнитов по отдельности.

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

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

[Install]

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

[Service]

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

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

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

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

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

[Socket]

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

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

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

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

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

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

[Mount]

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

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

What=: Абсолютный путь к ресурсу, который необходимо смонтировать.
Where=: Абсолютный путь точки монтирования, в которой должен быть установлен ресурс. Это должно быть таким же, как имя файла устройства, за исключением использования стандартной записи файловой системы.
Type=: Тип файловой системы для монтирования.
Options=: Любые параметры монтирования, которые необходимо применить. Это список, разделенный запятыми.
SloppyOptions=: Логическое значение (0 или 1), которое определяет произойдет ли сбой монтирования, если есть параметр непризнанного монтирования.
DirectoryMode=: Если родительские каталоги необходимо создать для точки монтирования, это определяет режим разрешений этих папок.
TimeoutSec=: Настраивает время, в течение которого система будет ждать, пока операция монтирования не будет отмечена как сбой.

[Automount]

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

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

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

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

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

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

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

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

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

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

[Timer]

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

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

[Slice]

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

Хватит теории, перейдем к практике.

Пишем systemd Unit файл

PS: Вот небольшая статья:

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

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

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

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

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

Примеры systemd Unit файлов

И записываем в него следующий код:

Добавим томкат в автозагрузку ОС:

Чтобы проверить статус, выполняем:

Как видим, все четко работает. На этом, у меня все! Больше примеров будет дальше. Я буду добавлять их по мере необходимости. Но в основном, я использую шаблон что выше ( только немного его видоизменяю).

10 thoughts on “ Пишем systemd Unit файл ”

Вроде даже в книгах читал по модули systemd, но тут очень хорошо так на пальцах всё показано, для дальнейшего понимания очень полезно. Спасибо!

Можно ли как-то указать куда писать лог-файл. Есть python программа, unit к ней оформил, всё работает, только вот лог она пишет в файл syslog, а нужно в другой в /var/log/python.log например.

Да, можно. Нужно прописать в [Service] секции, следующии строки:

На форуме капча не работает зарегистрироваться нельзя так что пишу сюда.

Пытаюсь оформить сервис для vmpsd. Не запускается.
Если добавить:
StandardOutput=
StandardError=

То получаю:
Failed to parse output specifier, ignoring:

Что-то не так делаешь, нужно привести к следующему виду:

[Service]
Type=forking
StandardOutput=/var/StandardOutput.log
StandardError=/var/StandardError.log

У меня такая же ошибка как у vasyun. Type=idle, если сделать forking, то вообще юнит не запускается, приходиться жать Ctrl-C.

Спасибо Автор! Ваш труд оказался полезным! Всех благ Вам!

Добрый день!
Можете объяснить точный функционал опции After?
Она несет только информацию для пользователя, что именно он должен запустить перед запуском текущего юнита?
Или все что там прописано автоматически запускается при запуске текущего юнита?

Первое и не просто для пользователя, а для правильной последовательности запуска того юнита, где встречается after и в данном случае не перед, а после.

Взято с другого сайта:
Запускать юнит после какого-либо сервиса или группы сервисов (например network.target):
After=network.target

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Systemd – менеджер системы и сервисов в операционной системе Linux. При разработке eго стремились спроектировать обратно совместимым со скриптами инициализации SysV init и предоставить полезные функции, такие, как параллельный запуск системных сервисов во время загрузки, активацию демонов по требованию, поддержку снепшотов состояния системы и логику управления сервисами, основанную на зависимостях. В CentOS 7 systemd заменяет Upstart как систему инициализации по умолчанию.

В этой статье мы рассмотрим процесс управления сервисами в systemd для пользователя CentOS 7. Эти знания будут полезны и в других дистрибутивах, ведь systemd уже давно используется в Fedora и планируется в Ubuntu 14.10 и Debian 8. Хорошо это или нет — оставим за кадром.

В процессе чтения статьи вы можете попробовать systemd на классических VPS и облачных VPS от Infobox. Мы стремимся своевременно добавлять поддержку современных ОС, чтобы вы могли использовать последние технологии для более эффективной работы. Сама идея написания статьи родилась после очередного вопроса пользователей об использовании сервисов в CentOS 7.

Введение

/usr/lib/systemd/system/ – юниты из установленных пакетов RPM.
/run/systemd/system/ — юниты, созданные в рантайме. Этот каталог приоритетнее каталога с установленными юнитами из пакетов.
/etc/systemd/system/ — юниты, созданные и управляемые системным администратором. Этот каталог приоритетнее каталога юнитов, созданных в рантайме.

.service – системный сервис
.target — группа юнитов systemd
.automount – точка автомонтирования файловой системы
.device – файл устройства, распознанного ядром
.mount – точка монтирования файловой системы
.path – файл или директория в файловой системе
.scope – процесс, созданный извне
.slice – группа иерархически организованных юнитов, управляющая системными процессами
.snapshot – сохраненное состояние менеджера systemd
.socket – сокет межпроцессного взаимодействия
.swap – Свап-устройство или свап-файл (файл подкачки)
.timer – таймер systemd

Основные функции systemd в CentOS 7

Управление сервисами

В предыдущих версиях CentOS использовалась SysV или Upstart. Скрипты инициализации располагались в директории /etc/rc.d/init.d/. Такие скрипты обычно писались на Bash и позволяли администратору управлять состоянием сервисов и демонов. В CentOS 7 скрипты инициализации были заменены сервисными юнитами.

По способу использования сервисные юниты .service напоминают скрипты инициализации. Для просмотра, старта, остановки, перезагрузки, включения или выключения системных сервисов используется команда systemctl. Команды service и chkconfig по-прежнему включены в систему, но только по соображениям совместимости.

При использовании systemctl указывать расширение файла не обязательно.

systemctl start name.service – запуск сервиса.
systemctl stop name.service — остановка сервиса
systemctl restart name.service — перезапуск сервиса
systemctl try-restart name.service — перезапуск сервиса только, если он запущен
systemctl reload name.service — перезагрузка конфигурации сервиса
systemctl status name.service — проверка, запущен ли сервис с детальным выводом состояния сервиса
systemctl is-active name.service — проверка, запущен ли сервис с простым ответом: active или inactive
systemctl list-units --type service --all – отображение статуса всех сервисов
systemctl enable name.service – активирует сервис (позволяет стартовать во время запуска системы)
systemctl disable name.service – деактивирует сервис
systemctl reenable name.service – деактивирует сервис и сразу активирует его
systemctl is–enabled name.service – проверяет, активирован ли сервис
systemctl list-unit-files --type service – отображает все сервисы и проверяет, какие из них активированы
systemctl mask name.service – заменяет файл сервиса симлинком на /dev/null, делая юнит недоступным для systemd
systemctl unmask name.service – возвращает файл сервиса, делая юнит доступным для systemd

Работаем с целями (targets) Systemd

Предыдущие версии CentOS с SysV init или Upstart включали предопределенный набор уровней запуска (runlevels), которые представляли специфичные режимы для операций, пронумерованные от 0 до 6. В CentOS 7 концепция уровней запуска была заменена целями systemd.

Файлы целей systemd .target предназначены для группировки вместе других юнитов systemd через цепочку зависимостей. Например юнит graphical.target, использующийся для старта графической сессии, запускает системные сервисы GNOME Display Manager (gdm.service) и Accounts Service (accounts–daemon.service) и активирует multi–user.target. В свою очередь multi–user.target запускает другие системные сервисы, такие как Network Manager (NetworkManager.service) или D-Bus (dbus.service) и активирует другие целевые юниты basic.target.

В CentOS 7 присутствуют предопределенные цели, похожие на стандартный набор уровней запуска. По соображениям совместимости они также имеют алиасы на эти цели, которые напрямую отображаются в уровнях запуска SysV.

poweroff.target (runlevel0.target) – завершение работы и отключение системы
rescue.target (runlevel1.target) – настройка оболочки восстановления
multi–user.target (runlevel2.target, runlevel3.target, runlevel4.target) – настройка неграфической многопользовательской системы
graphical.target (runlevel5.target) – настройка графической многопользовательской системы
reboot.target (runlevel6.target) – выключение и перезагрузка системы

Для определения, какой целевой юнит используется по умолчанию, полезна следующая команда: systemctl get–default.

Для просмотра всех загруженных целевых юнитов воспользуйтесь командой systemctl list-units --type target, а для просмотра вообще всех целевых юнитов командой: systemctl list-units --type target --all.

Для изменения цели по умолчанию поможет команда systemctl set-default name.target.

Для изменения текущей цели: systemctl isolate name.target. Команда запустит целевой юнит и все его зависимости и немедленно остановит все остальные.

Выключение и перезагрузка системы

В CentOS 7 systemctl заменяет значительное количество команд управления питанием. Прежние команды сохранены для совместимости, но рекомандуется использовать systemctl:
systemctl halt – останавливает систему
systemctl poweroff – выключает систему
systemctl reboot – перезагружает систему

Управление systemd на удаленной машине

Systemd позволяет управлять удаленной машиной по SSH. Для управления используйте команду:
systemctl --host user_name@host_name command, где user_name – имя пользователя, host_name – имя хоста, которым осуществляется удаленное управление, а command – выполняемая команда systemd.

Типичный systemd .service

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

Давайте посмотрим на секцию [Unit]. Она содержит общую информацию о сервисе. Такая секция есть не только в сервис-юнитах, но и в других юнитах (например при управлении устройствами, точками монтирования и т.д.). В нашем примере мы даем описание сервиса и указываем на то, что демон должен быть запущен после Syslog.

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

Финальная секция [Install] содержит информацию о цели, в которой сервис должен стартовать. В данном случае мы говорим, что сервис должен быть запущен, когда будет активирована цель multi–user.target.

Это минимальный работающий файл сервиса systemd. Написав свой, для тестирования скопируйте его в /etc/systemd/system/имя_сервиса.service. Выполните команды systemctl daemon-reload. Systemd узнает о сервисе и вы сможете его запустить.

Дополнительная информация

Заключение

В этой статье мы научились управлять сервисами CentOS 7. Конечно, это далеко не единственная функция systemd и другие ее стороны будут рассмотрены в будущем. Сама ОС практически со времени релиза доступна на классических VPS и облачных VPS от Infobox. Попробуйте systemd прямо сейчас. Эти знания будут полезны в связи с переходом многих дистрибутивов на systemd.

Если вы обнаружили ошибку в статье, автор ее с удовольствием исправит. Пожалуйста напишите в ЛС или на почту о ней.
В случае, если вы не можете оставлять комментарии на Хабре, можно написать их в блоге Сообщества InfoboxCloud или в нашей группе в Facebook.

Читайте также: