Автор: Lector

10.6.3. Конвертация SysV Init скриптов в файлы юнитов (Unit Files)

Прежде чем заняться преобразованием скрипта SysV (далее – init-скрпт) в файл юнита, убедитесь, что преобразование еще не было выполнено в другом месте. Все основные службы, установленные в Red Hat Enterprise Linux 7, поставляются со стандартными юнит-файлами, и то же самое относится ко многим сторонним программным пакетам.
Преобразование init-скрипта в юнит-файл требует анализа init-скрипта и извлечения из него необходимой информации. На основе полученных данных вы можете создать файл юнита, как описано в разделе 10.6.2 «Создание пользовательских файлов юнита». Поскольку init-скрипты могут сильно различаться в зависимости от типа сервиса, возможно вам потребуется использовать больше параметров конфигурации для конвертации, чем описано в этой главе. Обратите внимание, что некоторые уровни настройки, которые были доступны в init-скриптах, больше не поддерживаются модулями systemd, см. Раздел 10.1.2, «Изменения совместимости».
Большая часть информации, необходимой для конвертации, указана в заголовке скрипта. В следующем примере показан начальный раздел init-скрипта, используемого для запуска службы postfix в Red Hat Enterprise Linux 6 (пример файла юнита для postfix можно найти в предыдущей части):

#!/bin/bash
#
# postfix      Postfix Mail Transfer Agent
#
# chkconfig: 2345 80 30
# description: Postfix is a Mail Transport Agent, which is the program \
#              that moves mail from one machine to another.
# processname: master
# pidfile: /var/spool/postfix/pid/master.pid
# config: /etc/postfix/main.cf
# config: /etc/postfix/master.cf
 
### BEGIN INIT INFO
# Provides: postfix MTA
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop postfix
# Description: Postfix is a Mail Transport Agent, which is the program that 
#              moves mail from one machine to another.
### END INIT INFO

В приведенном выше примере обязательны только строки, начинающиеся с #chkconfig и #description, поэтому вы можете не найти остальных в разных init-файлах. Текст, заключенный между строками ### BEGIN INIT INFO и ### END INIT INFO, называется заголовком Linux Standard Base (LSB). Если LSB-заголовок указан, то он содержит директивы, определяющие описание службы, зависимости и уровни запуска (runlevels). Далее следует обзор аналитических задач, направленных на сбор данных, необходимых для нового юнит-файла. В качестве примера используется init-скрипт postfix, см. Итоговый файл модуля postfix в примере 10.17, «Файл юнита postfix.service».

Поиск описания сервиса

Найдите описание скрипта в строке, начинающейся с #description. Используйте это описание вместе с именем сервиса в опции Description секции [Unit] в файле юнита. Заголовок LSB может содержать аналогичные данные в строках #Short-Description и #Description.

Поиск зависимостей сервиса

Заголовок LSB может содержать несколько директив, которые формируют зависимости между сервисами. Большая часть может быть переведена в опции юнита systemd, см. Таблицу 10.12, «Параметры зависимостей из заголовка LSB».

Определение таргета для запуска сервиса

Строка, начинающаяся с #chkconfig, содержит три числовых значения. Для нас важно первое число, которым представлены уровни запуска по умолчанию для данного сервиса. Используйте Таблицу 10.6, «Сравнение уровней запуска SysV с таргетами systemd», чтобы перевести эти уровни выполнения в таргеты systemd. Затем перечислите эти таргеты в опции WantedBy в разделе [Install] файла юнита. Например, postfix ранее запускался на уровнях запуска 2, 3, 4 и 5, что соответствует таргетам multi-user.target и graphical.target в Red Hat Enterprise Linux 7. Обратите внимание, что graphical.target зависит от multiuser.target, поэтому нет необходимости указывать оба, как в примере 10.17, «Файл модуля postfix.service». Вы также можете найти информацию о дефолтных и запрещенных уровнях запуска в строках #Default-Start и #Default-Stop в заголовке LSB.
Два других значения, указанные в строке #chkconfig, представляют приоритеты запуска и завершения init-скрипта. Эти значения интерпретируются systemd, если он загружает init-скрипт, но нет эквивалентного юнит-файла.

Определение файлов, используемых сервисом

Init-скрипты требуют загрузки библиотеки функций из выделенной директории и позволяют импортировать файлы конфигурации, среды и PID файлы. Переменные среды указываются в строке, начинающейся с #config в заголовке скрипта и соответствует опции EnvironmentFile в файле юнита. Файл PID, указанный в init-скрипте в строке #pidfile импортируется в файл юнита с опцией PIDFile.
Ключевой информацией, которая не включена в заголовок скрипта, является путь к исполняемому файлу сервиса и, возможно, некоторые другие файлы, необходимые для сервиса. В предыдущих версиях Red Hat Enterprise Linux init-скрипты использовали оператор Bash case, чтобы определить поведение службы при действиях по умолчанию, таких как запуск, остановка или перезапуск, а также при выполнении определенных пользователем действий. Следующий фрагмент из init-скрипта postfix показывает блок кода, который должен быть выполнен при запуске сервиса.

conf_check() {
    [ -x /usr/sbin/postfix ] || exit 5
    [ -d /etc/postfix ] || exit 6
    [ -d /var/spool/postfix ] || exit 5
}
 
make_aliasesdb() {
	if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ]
	then
		# /etc/aliases.db might be used by other MTA, make sure nothing
		# has touched it since our last newaliases call
		[ /etc/aliases -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
		/usr/bin/newaliases
		touch -r /etc/aliases.db "$ALIASESDB_STAMP"
	else
		/usr/bin/newaliases
	fi
}
 
start() {
	[ "$EUID" != "0" ] && exit 4
	# Check that networking is up.
	[ ${NETWORKING} = "no" ] && exit 1
	conf_check
	# Start daemons.
	echo -n $"Starting postfix: "
	make_aliasesdb >/dev/null 2>&1
	[ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
	/usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
	RETVAL=$?
	[ $RETVAL -eq 0 ] && touch $lockfile
        echo
	return $RETVAL
}

Init-скрипт позволяет указать пользовательские функции, здесь это conf_check() и make_aliasesdb(), которые вызываются из функционального блока start(). В приведенном выше коде упоминаются несколько внешних файлов и директорий: исполняемый файл основного сервиса /usr/sbin/postfix, директории конфигураций /etc/postfix/ и /var/spool/postfix/, а также директория /usr/sbin/postconf/.
Systemd поддерживает только предопределенные действия, но позволяет выполнять пользовательские исполняемые файлы с помощью ExecStart, ExecStartPre, ExecStartPost, ExecStop и ExecReload. В случае с postfix в RHEL 7, /usr/sbin/postfix выполняется вместе со вспомогательными скриптами при запуске сервиса. Посмотрите файл юнита postfix в Примере 10.17, «Файл модуля postfix.service».
Преобразование сложных скриптов требует понимания назначения каждого оператора в скрипте. Некоторые операторы относятся к конкретной версии операционной системы, поэтому вам не нужно переводить их. С другой стороны, в новой среде могут потребоваться некоторые корректировки, как в файле юнита, так и в исполняемом файле сервиса и вспомогательных файлах.

10.6.4. Изменение существующих файлов юнитов

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

• Создайте директори. для дополнительных файлов конфигурации в /etc/systemd/system/unit.d/. Этот метод рекомендуется в большинстве случаев. Это позволяет расширить конфигурацию дополнительными функциональными возможностями, ссылаясь при этом на исходный файл юнита. Поэтому изменения в юните, поисходящие при обновлении пакета, применяются автоматически. См. Раздел «Расширение конфигурации юнита по умолчанию» для получения дополнительной информации.
• Создайте копию файла юнита из /usr/lib/systemd/system/ в /etc/systemd/system/ и делайте изменения в ней. Копия переопределяет исходный файл, поэтому изменения, внесенные обновлением пакета, не применяются. Этот метод полезен для внесения значительных изменений в юниты, которые должны сохраняться независимо от обновлений пакета. Подробнее см. в разделе «Переопределение конфигурации модуля по умолчанию».

Чтобы вернуться к стандартной конфигурации юнита, просто удалите пользовательские файлы конфигурации в /etc/systemd/system/. Чтобы применить изменения к файлам юнита без перезагрузки системы, выполните:

systemctl daemon-reload

Опция daemon-reload перезагружает все файлы юнитов и воссоздает все дерево зависимостей для применения любых изменений в файлах юнитов. Того же результата можно добиться с помощью следующей команды:

init q

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

systemctl restart name.service

Важно
Чтобы изменить свойства (такие как зависимости или тайм-ауты) сервиса, который обрабатывается init-скриптом SysV, не изменяйте сам init-скрипт. Вместо этого создайте системный файл конфигурации systemd для службы, как описано в разделе «Расширение конфигурации юнита по умолчанию» и в разделе «Переопределение конфигурации юнита по умолчанию». Затем управляйте этим сервисом так же, как обычным сервисом systemd.
Например, чтобы расширить конфигурацию сервиса network, не изменяйте init-файл /etc/rc.d/init.d/network. Вместо этого создайте новую директорию /etc/systemd/system/network.service.d/ и drop-in файл /etc/systemd/system/network.service.d/my_config.conf (прим. переводчика: для себя я определяю drop-in файлы как дополнительные конфиги. Система заглядывает в каталоги конфигурации и подбирает то, что там лежит). Затем поместите измененные значения в drop-in файл. Заметка: systemd знает сервис network как network.service, поэтому созданный каталог должен называться network.service.d.

Расширение конфигурации юнитов

Чтобы добавить дополнительные параметры конфигурации в файл юнита, сначала создайте директорию конфигурации в /etc/systemd/system/. Если вы расширяете юнит сервиса, выполните следующую команду от root:

mkdir /etc/systemd/system/name.service.d/

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

touch /etc/systemd/system/name.service.d/config_name.conf

Замените config_name на имя файла конфигурации. Этот файл имеет структуру обычного файла юнита, поэтому все директивы должны быть указаны в соответствующих разделах, см. Раздел 10.6.1, «Понимание структуры файла юнита».
Например, чтобы добавить зависимость, создайте файл конфигурации со следующим содержимым:

[Unit]
Requires=new_dependency
After=new_dependency

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

[Service]
Restart=always
RestartSec=30

Рекомендуется создавать небольшие файлы конфигураций, ориентированные на одну задачу. Такие файлы легко переместить или связать (создать линк) с каталогами конфигурации других сервисов.
Чтобы внесенные изменения вступили в силу, выполните от root:

systemctl daemon-reload
systemctl restart name.service

Пример 10.20. Расширение конфигурации httpd.service

Изменим юнит httpd.service так, чтобы при запуске Apache автоматически выполнялся shell-скрипт. Создайте каталог и файл конфигурации:

~]# mkdir /etc/systemd/system/httpd.service.d/
~]# touch /etc/systemd/system/httpd.service.d/custom_script.conf

Предположим, что /usr/local/bin/custom.sh – путь к скрипту, который вы хотите запустить вместе с Apache, вставьте следующий текст в файл custom_script.conf:

[Service]
ExecStartPost=/usr/local/bin/custom.sh

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

~]# systemctl daemon-reload
~]# systemctl restart httpd.service

Заметка

Файлы конфигурации из директорий /etc/systemd/system/ имеют приоритет над файлами юнитов в /usr/lib/systemd/system/. Следовательно, если файлы конфигурации содержат параметр, который может быть указан только один раз, например, Description или ExecStart, значение по умолчанию для этого параметра переопределяется. Обратите внимание, что в выходных данных команды systemd-delta, описанной в разделе «Мониторинг переопределенных юнитов», такие юниты всегда помечаются как [EXTENDED], хотя фактически некоторые параметры переопределяются.

Переопределение конфигурации юнита по умолчанию

Чтобы внести изменения в юнит, которые сохранятся после обновления пакета, сначала скопируйте файл в каталог /etc/systemd/system/. Для этого выполните от root:

cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service

Где name – имя сервиса, файл юнита которого вы хотите изменить. Этот синтаксис применим ко всем типам юнитов.
Откройте скопированный файл в текстовом редакторе и внесите желаемые изменения. Чтобы принять изменения, выполните от root:

systemctl daemon-reload
systemctl restart name.service

Пример 10.21. Изменение тайм-аута

Вы можете указать тайм-аут для каждой службы, чтобы предотвратить зависание системы из-за сбоя в работе службы. Обычно, тайм-аут установлен в 90 секунд для обычных сервисов и 300 секунд для SysV-совместимых сервисов.
Например, установим тайм-аут для httpd сервиса:

1. Скопируйте юнит-файл httpd в директорию /etc/systemd/system/:

   cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd.service

   cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd.service

2. Откройте файл /etc/systemd/system/httpd.service и определите значение TimeoutStartUSec в секции [Service]:

   ... [Service] ... PrivateTmp=true TimeoutStartSec=10   [Install] WantedBy=multi-user.target ...

   ... [Service] ... PrivateTmp=true TimeoutStartSec=10 [Install] WantedBy=multi-user.target ...

3. Перезагрузите демон systemd:

   systemctl daemon-reload

   systemctl daemon-reload

4. Проверьте, что новый тайм-аут установлен:

   systemctl show httpd -p TimeoutStartUSec

   systemctl show httpd -p TimeoutStartUSec

Заметка
Чтобы сменить тайм-аут глобально, введите значение DefaultTimeoutStartSec в файл /etc/systemd/system.conf. Подробнее см. раздел 10.1, “Введение в systemd”.

Мониторинг переопределенных юнитов

Чтобы просмотреть переопределенные или измененные юниты, используйте следующую команду:

systemd-delta

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

[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target
[OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service
 
--- /usr/lib/systemd/system/autofs.service      2014-10-16 21:30:39.000000000 -0400
+++ /etc/systemd/system/autofs.service  2014-11-21 10:00:58.513568275 -0500
@@ -8,7 +8,8 @@
 EnvironmentFile=-/etc/sysconfig/autofs
 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid
 ExecReload=/usr/bin/kill -HUP $MAINPID
-TimeoutSec=180
+TimeoutSec=240
+Restart=Always
 
 [Install]
 WantedBy=multi-user.target
 
[MASKED]     /etc/systemd/system/cups.service → /usr/lib/systemd/system/cups.service
[EXTENDED]   /usr/lib/systemd/system/sssd.service → /etc/systemd/system/sssd.service.d/journal.conf
 
4 overridden configuration files found.

В таблице 10.13 «Типы различий systemd-delta» перечислены типы переопределений, которые можно увидеть в выводе systemd-delta. Обратите внимание, что если файл переопределен, systemd-delta по умолчанию отображает сводку изменений, аналогичную выводу команды diff.

Рекомендуется запускать systemd-delta после обновления системы, чтобы проверить, есть ли какие-либо обновления для юнитов по умолчанию, которые в настоящее время переопределяются пользовательской конфигурацией. Также можно ограничить вывод только определенным типом различий. Например, чтобы просмотреть только переопределенные блоки [OVERRIDEN], выполните:

systemd-delta --type=overridden

10.6.5. Работа с юнитами, созданными из шаблона (Instantiated Units)

Можно создать несколько экземпляров из одного файла конфигурации шаблона во время выполнения. Символ «@» используется для обозначения шаблона и ассоциации юнита с ним. Instantiated units могут быть запущены из другого файла юнита (с использованием параметров Requires или Wants) или с помощью команды systemctl start. Instantiated service units именуются следующим образом:

template_name@instance_name.service

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

unit_name@.service

Например, следующая настройка Wants в файле юнита:

Wants=getty@ttyA.service,getty@ttyB.service

сначала выполняет поиск для заданных сервисных юнитов. Если таких юнитов не найдено, часть между “@” и суффиксом типа игнорируется, и systemd ищет файл getty@.service, считывает из него конфигурацию и запускает сервисы.
Подстановочные знаки, называемые спецификаторами единиц, могут использоваться в любом файле конфигурации юнитов. Спецификаторы юнита заменяют определенные параметры модуля и интерпретируются во время выполнения. В таблице 10.14 «Важные спецификаторы юнитов» перечислены полезные для юнитов-шаблонов спецификаторы юнитов.

Полный список спецификаторов см. в мануале systemd.unit(5).

Например, шаблон getty@.service содержит следующие директивы:

[Unit]
Description=Getty on %I
...
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
...

Когда создаются экземпляры getty@ttyA.service и getty@ttyB.service из вышеприведенного шаблона, Description = преобразуется в Getty on ttyA и Getty on ttyB.

10.7. Additional Resources – этот раздел я не вижу смысла переводить, так как он просто содержит ссылки на дополнительные источники информации. Но оставлю его тут)

Файл юнита содержит директивы, которые описывают юнит и определяют его поведение. Некоторые команды 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 Понимание структуры файла юнита

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

• [Unit] — содержит общие параметры, которые не зависят от типа юнита. Эти параметры описывают юнит, определяют его поведение и устанавливают зависимости по отношению к другим юнитам. Список часто используемых опций см. в Таблице 10.9, «Важные параметры секции [Unit]».
• [unit type] — если юнит имеет специфичные директивы, они группируются в секцию, названную по типу юнита. Например, юниты сервисов содержат секцию [Service]. Наиболее часто используемые параметры секции [Service] см. в Таблице 10.10, “Важные параметры секции [Service]”.
• [Install] — содержит информацию about unit installation used by systemctl enable and disable commands. Список опций секции [Install] см. в Таблице 10.11, “Важные параметры секции [Install]”.

Пример 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

   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

   [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 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

   ~]# 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

   [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

   ~]# 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

   ~]# cp /etc/ssh/sshd{,-second}_config

2. Отредактируйте ранее созданный файл sshd-second_config, ччтобы назначить другой порт и и PID-файл для второго демона:

   Port 22220 PidFile /var/run/sshd-second.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

   ~]# cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service

4. После измените файл sshd-second.service следующим образом:
   • Измените опцию Description:

     Description=OpenSSH server second instance daemon

     Description=OpenSSH server second instance daemon

   • Добавьте sshd.service к службам, указанным в опции After, чтобы второй экземпляр запускался только после того, как первый уже запущен:

     After=syslog.target network.target auditd.service sshd.service

     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

     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

     [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

   ~]# semanage port -a -t ssh_port_t -p tcp 22220

6. Добавьте сервис sshd-second.service в автоматическую загрузку:

   ~]# systemctl enable sshd-second.service

   ~]# systemctl enable sshd-second.service

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

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

   ~]~]$ 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.