Просмотр исходного текста страницы Systemd для администраторов, часть 3: HOW-TO: преобразование SysV init-скрипта в systemd service-файл

Традиционно, службы Unix и Linux (демоны) запускаются через SysV init-скрипты. Эти скрипты пишутся на языке Bourne Shell ({{Источник|/bin/sh}}), располагаются в специальном каталоге (обычно {{Источник|/etc/rc.d/init.d/}}) и вызываются с одним из стандартных параметров ('''start''', '''stop''', '''reload''' и т.п.) &#8212; таким образом указывается действие, которое необходимо прозвести над службой (запустить, остановить, заставить перечитать конфигурацию). При запуске службы такой скрипт, как правило, вызывает бинарник демона, который, в свою очередь, форкается, порождая фоновый процесс (т.е.  демонизируется). Заметим, что shell-скрипты, как правило, отличается низкой скоростью работы, излишней подробностью изложения и крайней хрупкостью. Читать их, из-за изобилия всевозможного вспомогательного и дополнительного кода, чрезвычайно тяжело. Впрочем, нельзя не упомянуть, что эти скрипты являются очень гибким инструментом (ведь, по сути, это всего лишь код, который можно модифицировать как угодно). С другой стороны, многие задачи, возникающие при работе со службами, довольно тяжело решить средствами shell-скриптов. К таким задачам относятся: организация параллельного исполнения, корректное отслеживание процессов, конфигурирование различных параметров среды исполнения процесса. {{Программа|systemd}} обеспечивает совместимость с init-скриптами, однако, с учетом описанных выше их недостатков, более правильным решением будет использование штатных service-файлов {{Программа|systemd}} для всех установленных в системе служб. Стоит отметить что, в отличие от init-скриптов, которые часто приходится
модифицировать при переносе из одного дистрибутива в другой, один и тот же '''service-файл''' будет работать в любом дистрибутиве, использующем {{Программа|systemd}} (а таких дистрибутивов с каждым днем становится все больше и больше). Далее мы вкратце рассмотрим процесс преобразования SysV init-скрипта в service-файл {{Программа|systemd}}.

Вообще говоря, service-файл должен создаваться разработчиками каждого демона, и включаться в комплект его поставки. Если вам удалось успешно создать работоспособный service-файл для какого-либо демона, настоятельно рекомендуем вам отправить этот файл разработчикам. Вопросы по полноценной интеграции демонов с {{Программа|systemd}}, с максимальным использованием всех его возможностей, будут рассмотрены в последующих статьях этого цикла, пока же ограничимся ссылкой на [http://0pointer.de/public/systemd-man/daemon.html страницу] официальной
документации.

Итак, приступим. В качестве пример возьмем init-скрипт демона ABRT (Automatic Bug Reporting Tool, службы, занимающейся сбором crash dump'ов). Исходный скрипт (в варианте для дистрибутива Fedora) можно загрузить [http://0pointer.de/public/abrtd здесь].

Начнем с того, что прочитаем исходный скрипт (неожиданный ход, правда?) и выделим полезную информацию из груды хлама. Практически у всех init-скриптов большая часть кода является чисто вспомогательной, и мало чем отличается от одного скрипта к другому. Как правило, при создании новых скриптов этот код просто копируется из уже существующих (разработка в стиле copy-paste). Итак, в исследуемом скрипте нас интересует следующая информация:

* Строка описания службы: &#171;Daemon to detect crashing apps&#187;. Как нетрудно заметить, комментарии в заголовке скрипта весьма пространны и описывают не сколько саму службу, сколько скрипт, ее запускающий. service-файлы {{Программа|systemd}} также включают описание, но оно относится исключительно к службе, а не к service-файлу.

* '''LSB-заголовок'''<sup>[1]</sup>, содержащий информацию о зависимостях. {{Программа|systemd}}, базирующийся на идеях socket-активации, обычно не требует явного описания зависимостей (либо требует самого минимального описания). Заметим, что основополагающие принципы {{Программа|systemd}}, включая '''socket-активацию''', рассмотрены в статье [http://0pointer.de/blog/projects/systemd.html Rethinking PID 1], в которой {{Программа|systemd}} был впервые представлен широкой публике. Ее русский перевод можно прочитать здесь: [http://tux-the-penguin.blogspot.com/2010/09/systemd.html часть 1], [http://tux-the-penguin.blogspot.com/2010/09/systemd-ii.html часть 2]. Возвращаясь к нашему примеру: в данном случае ценной информацией о зависимостях является только строка <u>Required-Start: $syslog</u>, сообщающая, что для работы abrtd требуется демон системного лога. Информация о второй зависимости, <u>$local_fs</u>, является избыточной, так как {{Программа|systemd}} приступает к запуску служб уже после того, как все файловые системы готовы для работы.

* Также, LSB-заголовок сообщает, что данная служба должна быть запущена на уровнях исполнения '''(runlevels) 3''' (консольный многопользовательский) и '''5''' (графический многопользовательской).

* Исполняемый бинарник демона называется {{Источник|/usr/sbin/abrtd}}.

Вот и вся полезная информация. Все остальное содержимое 115-строчного скрипта является чисто вспомогательным кодом: операции синхронизации и упорядочивания запуска (код, относящийся к lock-файлам), вывод информационных сообщений (команды {{cmd|echo}}), разбор входных параметров (монструозный блок case).

На основе приведенной выше информации, мы можем написать следующий '''service-файл''':

<pre>
[Unit]
Description=Daemon to detect crashing apps
After=syslog.target

[Service]
ExecStart=/usr/sbin/abrtd
Type=forking

[Install]
WantedBy=multi-user.target
</pre>

Рассмотрим этот файл поподробнее.

Секция {{Меню|[Unit]}} содержит самую общую информацию о службе. Не будем забывать, что {{Программа|systemd}} управляет не только службами, но и многими другими объектами, в частности, устройствами, точками монтирования, таймерами и т.п. Общее наименование всех этих объектов &#8212; юнит (unit). Одноименная секция конфигурационного файла определяет наиболее общие свойства, которые могут быть
присущи любому юниту. В нашем случае это, во-первых, строка описания, и во-вторых, указание, что данный юнит рекомендуется активировать после запуска демона системного лога<sup>[2]</sup>. Эта информация, как мы помним, была указана в LSB-заголовке исходного init-скрипта. В нашем конфигурационном файле мы указываем зависимость от демона системного лога при помощи директивы <u>After</u>, указывающей на юнит {{Процесс|syslog.taget}}. Это специальный юнит, позволяющий ссылаться на любую реализацию демона системного лога, независимо от используемой программы (например, {{Программа|rsyslog}} или {{Программа|syslog-ng}}) и типа активации (как обычной службы или через
'''log-сокет'''). Подробнее о таких специальных юнитах можно почитать [http://0pointer.de/public/systemd-man/systemd.special.html страницу]
официальной документации. Обратите внимание, что директива <u>After</u>, в отсутствие директивы <u>Requires</u>, задает лишь порядок загрузки, но не задает жесткой зависимости. То есть, если при загрузке конфигурация {{Программа|systemd}} будет предписывать запуск как демона системного лога, так и {{Программа|abrtd}}, то сначала будет запущен демон системного лога, и только потом {{Программа|abrtd}}. Если же конфигурация не будет содержать явного указания запустить демон системного лога, он не будет запущен даже при запуске {{Программа|abrtd}}. И это поведение нас полностью устраивает, так как {{Программа|abrtd}} прекрасно может обходиться и без демона системного лога. В противном случае, мы могли бы воспользоваться директивой <u>Requires</u>, задающей жесткую зависимость между юнитами.

Следующая секция, {{Меню|[Service]}}, содержит информацию о службе. Сюда включаются настройки, относящие именно к службам, но не к другим типам юнитов. В нашем случае, таких настроек две: <u>ExecStart</u>, определяющая расположение бинарника демона и аргументы, с которыми он будет вызван (в нашем случае они отсутствуют), и Type, позволяющая задать метод, по которому {{Программа|systemd}} определит окончание периода запуска службы. Традиционный для Unix метод демонизации процесса, когда исходный процесс форкается, порождая демона, после чего завершается, описывается типом <u>forking</u> (как в нашем случае). Таким образом, {{Программа|systemd}} считает службу запущенной с момента завершения работы исходного процесса, и рассматривает в качестве основного процесса этой службы порожденный им процесс-демон.

И наконец, третья секция, {{Меню|[Install]}}. Она содержит рекомендации по установке конкретного юнита, указывающие, в каких ситуациях он должен быть активирован. В нашем случае, служба {{Программа|abrtd}} запускается при активации юнита {{Процесс|multi-user.target}}.
Это специальный юнит, примерно соответствующий роли третьего уровня исполнения классического SysV<sup>[3]</sup>. Директива <u>WantedBy</u> никак не влияет на уже работающую службу, но она играет важную роль при выполнении команды {{cmd|systemctl enable}}, задавая, в каких условиях должен активироваться устанавливаемый юнит. В нашем примере, служба {{Программа|abrtd}} будет активироваться при переходе в состояние {{Процесс|multi-user.target}}, т.е., при каждой нормальной загрузке<sup>[4]</sup> (к &#171;ненормальным&#187; можно отнести, например, загрузки в режиме {{Процесс|emergency.target}}, который является аналогом первого уровня исполнения в классической SysV).

Вот и все. Мы получили минимальный рабочий service-файл {{Программа|systemd}}. Чтобы проверить его работоспособность, скопируем его в {{Источник|/etc/systemd/system/abrtd.service}}, после чего командой {{cmd|systemctl daemon-reload}} уведомим {{Программа|systemd}} об изменении конфигурации. Теперь нам остается только запустить нашу службу: {{cmd|systemctl start abrtd.service}}. Проверить состояние службы можно командой {{cmd|systemctl status abrtd.service}}, а чтобы остановить ее, нужно скомандовать {{cmd|systemctl stop abrtd.service}}. И наконец, команда {{cmd|systemctl enable abrtd.service}} выполнит установку service-файла, обеспечив его активацию при каждой загрузке (аналог {{cmd|chkconfig abrtd on}} в классическом SysV).

Приведенный выше service-файл является практический точным переводом исходного init-скрипта, и он никак не использует широкий спектр возможностей, предоставляемых {{Программа|systemd}}. Ниже приведен немного улучшенный вариант этого же файла:
<pre>
[Unit]
Description=ABRT Automated Bug Reporting Tool
After=syslog.target

[Service]
Type=dbus
BusName=com.redhat.abrt
ExecStart=/usr/sbin/abrtd -d -s

[Install]
WantedBy=multi-user.target
</pre>

Чем же новый вариант отличается от предыдущего? Ну, прежде всего, мы уточнили описание службы. Однако, ключевым изменением является замена значения Type с <u>forking</u> на <u>dbus</u> и связанные с ней изменения: добавление имени службы в шине D-Bus (директива <u>BusName</u>) и задание дополнительных аргументов {{cmd|abrtd -d -s}}. Но зачем вообще нужна эта замена? Каков ее практический смысл? Чтобы ответить на этот вопрос, мы снова возвращаемся к демонизации. В ходе этой операции, процесс дважды форкается и отключается от всех терминалов. Это очень удобно при запуске демона через скрипт, но в случае использования таких продвинутых систем инициализации, как {{Программа|systemd}}, подобное поведение не дает никаких преимуществ, но вызывает неоправданные задержки.  Даже если мы оставим в стороне вопрос скорости загрузки, останется такой важный аспект, как отслеживание состояния служб. {{Программа|systemd}} решает и эту задачу, контролируя работу службы и при необходимости реагируя на различные события. Например, при неожиданном падении основного процесса службы, {{Программа|systemd}} должен зарегистрировать идентификатор и код выхода процесса, также, в зависимости от настроек, он может попытаться перезапустить службу, либо активировать какой-либо заранее заданный юнит. Операция демонизации несколько затрудняет решение этих задач, так как обычно довольно сложно найти связь демонизированного процесса с исходным (собственно, смысл демонизации как раз и сводится к уничтожению этой связи) и, соответственно, для {{Программа|systemd}} сложнее определить, какой из порожденных в рамках данной службы
процессов является основным. Чтобы упростить для него решение этой задачи, мы и воспользовались типом запуска dbus. Он подходит для всех служб, которые в конце процесса инициализации регистрируют свое имя на шине D-Bus<sup>[5]</sup>. ABRTd относится к ним. С новыми настройками, {{Программа|systemd}} запустит процесс abrtd, который уже не будет форкаться (согласно указанным нами ключам {{cmd|-d -s}}), и в качестве момента окончания периода запуска данной службы {{Программа|systemd}} будет рассматривать момент регистрации имени <u>com.redhat.abrt</u> на шине D-Bus. В этом случае основным для данной службы будет считаться процесс, непосредственно порожденный {{Программа|systemd}}. Таким образом, {{Программа|systemd}} располагает удобным методом для определения момента окончания запуска службы, а также может легко отслеживать ее состояние.

Собственно, это все, что нужно было сделать. Мы получили простой конфигурационный файл, в 10 строчках которого содержится больше полезной
информации, чем в 115 строках исходного init-скрипта. Добавляя в наш файл по одной строчке, мы можем использовать различные полезные функции {{Программа|systemd}}, создание аналога которых в традиционном init-скрипте потребовало бы значительных усилий. Например, добавив строку <u>Restart=restart-always</u>, мы приказываем {{Программа|systemd}} автоматически перезапускать службу после каждого ее падения. Или, например, добавив <u>OOMScoreAdjust=-500</u>, мы попросим ядро сберечь эту службу, даже если OOM Killer выйдет на тропу войны. А если мы добавим строчку <u>CPUSchedulingPolicy=idle</u>, процесс abrtd будет работать только в те моменты, когда система больше ничем не занята, что позволит не создавать помех для процессов, активно использующих CPU.

За более подробным описанием всех опций настройки, вы можете обратиться к страницам рукводства [http://0pointer.de/public/systemd-man/systemd.unit.html systemd.unit], [http://0pointer.de/public/systemd-man/systemd.service.html systemd.service], [http://0pointer.de/public/systemd-man/systemd.exec.html systemd.exec]. Полный список доступных страниц можно просмотреть [http://0pointer.de/public/systemd-man/ здесь].

Конечно, отнюдь не все init-скрипты так же легко преобразовать в service-файлы. Но, к счастью, &#171;проблемных&#187; скриптов не так уж и много.

= Примечания =

1. LSB-заголовок &#8212; определенная в
[http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/initscrcomconv.html Linux Standard Base] схема записи метаданных о службах в блоках комментариев соответствующих init-скриптов. Изначально эта схема была введена именно для
того, чтобы стандартизировать init-скрипты во всех дистрибутивах. Однако разработчики многих дистрибутивов не считают нужным точно исполнять требования LSB, и поэтому формы представления метаданных в различных дистрибутивах могут отличаться. Вследствие этого, при переносе init-скрипта из одного дистрибутива в другой, скрипт приходится модифицировать. Например, демон пересылки почты при описании зависимостей может именоваться <u>MTA</u> или <u>smtpdaemon</u> (Fedora), <u>smtp</u> (openSUSE), <u>mail-transport-agent</u> (Debian и Ubuntu), <u>mail-transfer-agent</u>. Таким образом, можно утверждать, что стандарт LSB не справляется с поставленной задачей.

2. Строго говоря, эту зависимость здесь указывать не нужно &#8212; в системах, в которых демон системного лога активируется через сокет, эта зависимость является избыточной. Современные реализации демона системного лога (например, rsyslog начиная с пятой версии) поддерживают активацию через сокет. В системах, использующих такие реализации, явное указание <u>After=syslog.target</u> будет избыточным, так как соответствующая функциональность поддерживается автоматически. Однако, эту строчку стоит все-таки указать для обеспечения
совместимости с системами, использующими устаревшие реализации демона системного лога.

3. В том контексте, в котором он используется в большинстве дистрибутивов семейства Red Hat, а именно, многопользовательский режим без
запуска графической оболочки.

4. Обратите внимание, что режим графической загрузки в {{Программа|systemd}} ({{Процесс|graphical.target}}, аналог runlevel 5 в SysV) является надстройкой над режимом многопользовательской консольной загрузки ({{Процесс|multi-user.target}}, аналог runlevel 3 в SysV). Таким образом, все службы, запускаемые в режиме {{Процесс|multi-user.target}}, будут также запускаться и в режиме {{Процесс|graphical.target}}.

5. В настоящее время практически все службы дистрибутива Fedora после запуска регистрируется на шине D-Bus.


Исходная статья: [http://0pointer.de/blog/projects/systemd-for-admins-3 systemd for Administrators, Part III: How Do I Convert A SysV Init Script Into A systemd Service File?], автор Lennart Poettering.<br />
Оригинал русского перевода [http://wiki.opennet.ru/Systemd_%D0%B4%D0%BB%D1%8F_%D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%BE%D1%80%D0%BE%D0%B2%2C_%D1%87%D0%B0%D1%81%D1%82%D1%8C_3:_HOW-TO:_%D0%BF%D1%80%D0%B5%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_SysV_init-%D1%81%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%B0_%D0%B2_systemd_service-%D1%84%D0%B0%D0%B9%D0%BB находится здесь]

{{Примечание|Все материалы данного цикла статей распростроняются под лицензией [http://creativecommons.org/licenses/by-sa/3.0/ Creative Commons Attribution-ShareAlike (BY-SA)]}}