Опубликовано Автор: Lector

Глава 10. Управление сервисами в systemd. 10.6. Создание и изменение файлов юнитов в systemd. Часть 1

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

unit_name.type_extension

где unit_name – имя юнита, type_extension – его тип. Полный список типов юнитов см. в Таблице 10.1, “Доступные типы юнитов systemd”. Например, обычно в системе существуют юниты sshd.service и sshd.socket.
Файлы юнитов могут быть дополнены каталогом дополнительных конфигурационных файлов. Например, чтобы добавить пользовательскую конфигурацию sshd.service, создайте файл sshd.service.d/custom.conf и добавьте в него дополнительные директивы. Больше информации о директориях конфигурации см. в разделе 10.6.4, “Изменение существующих файлов юнитов”.
Кроме того, могут быть созданы директории sshd.service.wants/ и sshd.service.requires/. Эти директории содержат символические ссылки (симлинки) на файлы юнитов сервиса sshd. Симлинки либо автоматически создаются во время установки в соответствии с параметрами в секции [Install] файла юнита (см. таблицу 10.11, “Важные опции секции [Install]), либо во время выполнения в соответствии с параметрами секции [Unit] (см. таблицу 10.9, “Важные опции секции [Unit]). Также можно создать эти директории и симлинки вручную.
Многие опции юнит-файла могут быть установлены с использованием так называемых спецификаторов юнитов – подстановочных строк, которые динамически заменяются параметрами юнита при загрузке файла юнита. Это позволяет создавать общие файлы юнитов, которые служат шаблонами для генерации конкретных экземпляров. См. раздел 10.6.5, “Работа с юнитами, созданными из шаблона (Instantiated Units)” для получения дополнительной информации.

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, зависимости последовательности все еще должны быть определены. Связано это с тем, что зависимости упорядочения и требований работают раздельно.

Таблица 10.10, Важные параметры секции [Service]
Опция[a] Описание
Type Настраивает тип запуска юнита, который влияет на функциональность ExecStart и связанных с ним опций. Возможные значения:

  • simple – Значение по умолчанию. Процесс стартующий с ExecStart, является основным процессом сервиса.
  • forking – Процесс, запущенный с ExecStart, порождает дочерний процесс, который становится основным процессом сервиса. После завершения запуска родительский процесс завершается.
  • oneshot – Этот тип похож на simple, но процесс завершается до запуска последующих юнитов.
  • dbus – Этот тип похож на simple, но последующие юниты запускаются только после того, как основной процесс получает D-Bus имя.
  • notify – похож на simple, но последующие юниты запускаются только после отправвки уведомления посредством функции sd_notify().
  • idle – похож на simple, фактическое выполнение сервиса задерживается до завершения всех заданий, что позволяет избежать смешивания потока вывода состояния с выводом сервиса.
ExecStart Указывает команды или сценарии, которые должны выполняться при запуске юнита. ExecStartPre и ExecStartPost определяют пользовательские команды, которые должны выполняться до и после ExecStart. Type=oneshot позволяет указать несколько пользовательских команд, которые затем выполняются последовательно.
ExecStop Определяет команды или скрипты, которые должны выполняться при остановке юнита.
ExecReload Определяет команды или скрипты, которые должны выполняться при перезагрузке юнита.
Restart Если эта опция включена, сервис перезапускается после завершения его процесса, за исключением чистой остановки командой systemctl.
RemainAfterExit Если установлено значение True, сервис считается активным, даже когда все его процессы завершены. Значение по умолчанию – False. Эта опция особенно полезна, если используется Type=oneshot.
[a] Полный список параметров, настраиваемых в разделе [Service], см. в man systemd.service (5).

Таблица 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, «Изменение существующих файлов модуля». Следующая процедура описывает общий процесс создания пользовательского юнита:

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

    Замените name имененм сервиса, который должен быть создан. Обратите внимание, что файл не должен быть исполняемым.

  3. Откройте файл name.service, созданный на предыдущем шаге и добавьте параметры конфигурации сервиса. Существует множество вариантов, которые можно использовать в зависимости от типа службы, которую вы хотите создать, см. раздел 10.6.1, «Понимание структуры файлов модуля». Ниже приведен пример конфигурации модуля для сетевой службы: 
    [Unit]
Description=service_description
After=network.target
 
[Service]
ExecStart=path_to_executable
Type=forking
PIDFile=path_to_pidfile
 
[Install]
WantedBy=default.target

    Где:

    • service_description – это информативное описание, которое отображается в логах (журналах) и в выводе команды systemctl status.
    • настройка After обеспечивает запуск службы только после запуска сети. Добавьте добавьте другие службы или таргеты, разделив их пробелами.
    • path_to_executable устанавливает путь к исполняемому файлу службы.
    • Type=forking используется для демонов, которые делают системный вызов fork. Основной процесс службы создается с PID, указанным в path_to_pidfile. Другие типы запуска можно посмотреть в таблице 10.10, «Важные опции [Service]».
    • WantedBy указывает таргет или таргеты, под которыми служба должна быть запущена. Представьте, что это замена старой концепции ранлевелов, подробнее см. Раздел 10.3, «Работа с таргетами systemd».
  4. Сообщите systemd о существовании нового файла с именем name.service выполнив следующую команду от root: 
    systemctl daemon-reload
systemctl start name.service

    Предупреждение!
    Всегда выполняйте команду systemctl daemon-reload после создания нового файла юнита или модификации существующего. В противном случае, команды systemctl start или systemctl enable могут завершиться ошибкой из-за несоответствия между состоянием systemd и актуальными файлами юнитов на диске.
    Юнит name.service теперь может управляться как любой другой сервис с помощью команд, описанных в разделе 10.2 “Управление системными сервисами”.

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

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

  1. Создайте юнит-файл в директории /etc/systemd/system/ удостоверьтесь, что он имеет корректные права доступа. Выполните как root: 
    ~]# touch /etc/systemd/system/emacs.service
~]# chmod 664 /etc/systemd/system/emacs.service
  2. Добавьте в файл следующее содержимое: 
    [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

    В приведенной выше конфигурации исполняемый файл /usr/bin/emacs запускается как демон при запуске службы. Переменная среды SSH_AUTH_SOCK задается с помощью спецификатора “%t”, который stands for the runtime directory. Сервис также перезапускает процесс emacs, если он неожиданно завершает работу.

  3. Выполните следующие команды, чтобы перезагрузить конфигурацию и запустить пользовательский сервис: 
    ~]# systemctl daemon-reload
~]# systemctl start emacs.service

Поскольку редактор теперь зарегистрирован как сервис systemd, вы можете использовать все стандартные команды systemctl. Например, запустите systemctl status emacs для отображения статуса редактора или systemctl enable emacs для автоматического запуска редактора при загрузке системы.

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

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

  1. Создайте копию файла sshd_config file который будет использоваться вторым демоном: 
    ~]# cp /etc/ssh/sshd{,-second}_config
  2. Отредактируйте ранее созданный файл sshd-second_config, ччтобы назначить другой порт и и PID-файл для второго демона: 
    Port 22220
PidFile /var/run/sshd-second.pid

    См. мануал sshd_config(5) (man sshd_config) для получения дополнительной информации об опция Port и PidFile. Удостоверьтесь, что порт, который вы выбрали, не используется другим сервисом. PID-файл не должен существовать до запуска сервиса, он генерируется автоматически при старте сервиса.

  3. Создайте копию файла юнита systemd для сервиса sshd: 
    ~]# cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service
  4. После измените файл sshd-second.service следующим образом:
    • Измените опцию Description: 
      Description=OpenSSH server second instance daemon
    • Добавьте sshd.service к службам, указанным в опции After, чтобы второй экземпляр запускался только после того, как первый уже запущен: 
      After=syslog.target network.target auditd.service sshd.service
    • Первый экземпляр sshd включает генерацию ключа, поэтому удалите строку ExecStartPre=/usr/sbin/sshd-keygen.
    • Добавьте параметр -f /etc/ssh/sshd-second_config к команде запуска sshd, чтобы использовать альтеративный файл конфигурации: 
      ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
    • После вышеуказанных изменений sshd-second.service должен выглядеть следующим образом: 
      [Unit]
Description=OpenSSH server second instance daemon
After=syslog.target network.target auditd.service sshd.service
 
[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s
 
[Install]
WantedBy=multi-user.target
  5. Если вы используете SELinux, добавьте порт для второго экземпляра sshd в порты для SSH, иначе привязка у порту для второго экземпляра будет отклонена: 
    ~]# semanage port -a -t ssh_port_t -p tcp 22220
  6. Добавьте сервис sshd-second.service в автоматическую загрузку: 
    ~]# systemctl enable sshd-second.service

    Проверьте, запущен ли sshd-second.service, с помощью команды systemctl status. Также проверьте, доступен ли порт, подключившись к сервису:

    ~]~]$ ssh -p 22220 user@server

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

Для получения информации о том, как правильно выбрать таргет, для упорядочения и зависимостей пользовательских юнитов, см следующие статьи:
How to write a service unit file which enforces that particular services have to be started
How to decide what dependencies a systemd service unit definition should have
Дополнительная информация с реальными примерами упорядочения и зависимостей для файлов юнитов доступна в следующей статье: Is there any useful information about writing unit files?
Как установить ограничения для служб, запускаемых systemd, см. в Статье базы знаний Red Hat How to set limits for services in RHEL 7 and systemd. Эти ограничения должны быть установлены в файле юнита службы. Обратите внимание, что systemd игнорирует ограничения, установленные в файлах конфигурации /etc/security/limits.conf и /etc/security/limits.d/*.conf. Ограничения, определенные в этих файлах, устанавливаются PAM при запуске сеанса входа в систему, но демоны, запущенные systemd, не используют сеансы входа в PAM.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *