diff options
Diffstat (limited to 'documentation/content/ru/articles/rc-scripting/_index.adoc')
| -rw-r--r-- | documentation/content/ru/articles/rc-scripting/_index.adoc | 775 |
1 files changed, 775 insertions, 0 deletions
diff --git a/documentation/content/ru/articles/rc-scripting/_index.adoc b/documentation/content/ru/articles/rc-scripting/_index.adoc new file mode 100644 index 0000000000..0f34f38d22 --- /dev/null +++ b/documentation/content/ru/articles/rc-scripting/_index.adoc @@ -0,0 +1,775 @@ +--- +authors: + - + author: 'Yar Tikhiy' + email: yar@FreeBSD.org +copyright: '2005-2006, 2012 The FreeBSD Project' +description: 'Руководство по написанию новых rc.d-скриптов и пониманию уже существующих' +tags: ["rc.d", "scripting", "guide", "tutorial", "FreeBSD"] +title: 'Практическое руководство по написанию rc.d скриптов в BSD' +trademarks: ["freebsd", "netbsd", "general"] +--- + += Практическое руководство по написанию rc.d скриптов в BSD +:doctype: article +:toc: macro +:toclevels: 1 +:icons: font +:sectnums: +:sectnumlevels: 6 +:source-highlighter: rouge +:experimental: +:images-path: articles/rc-scripting/ + +ifdef::env-beastie[] +ifdef::backend-html5[] +include::shared/authors.adoc[] +include::shared/mirrors.adoc[] +include::shared/releases.adoc[] +include::shared/attributes/attributes-{{% lang %}}.adoc[] +include::shared/{{% lang %}}/teams.adoc[] +include::shared/{{% lang %}}/mailing-lists.adoc[] +include::shared/{{% lang %}}/urls.adoc[] +:imagesdir: ../../../images/{images-path} +endif::[] +ifdef::backend-pdf,backend-epub3[] +include::../../../../shared/asciidoctor.adoc[] +endif::[] +endif::[] + +ifndef::env-beastie[] +include::../../../../../shared/asciidoctor.adoc[] +endif::[] + +[.abstract-title] +Аннотация + +Новичкам может быть сложно соотнести факты из официальной документации по фреймворку [.filename]#rc.d# в BSD с практическими задачами написания скриптов для [.filename]#rc.d#. В этой статье мы рассмотрим несколько типичных случаев возрастающей сложности, покажем возможности [.filename]#rc.d#, подходящие для каждого случая, и обсудим, как они работают. Такое рассмотрение должно дать ориентиры для дальнейшего изучения устройства и эффективного применения [.filename]#rc.d#. + +''' + +toc::[] + +[[rcng-intro]] +== Введение + +Исторически в BSD был монолитный стартовый сценарий [.filename]#/etc/rc#. Он вызывался man:init[8] во время загрузки системы и выполнял все задачи пользовательского пространства, необходимые для многопользовательского режима: проверку и монтирование файловых систем, настройку сети, запуск демонов и так далее. Точный список задач не был одинаковым в каждой системе; администраторам требовалось его настраивать. За редкими исключениями, [.filename]#/etc/rc# приходилось изменять, и настоящим хакерам это нравилось. + +Основная проблема монолитного подхода заключалась в том, что он не предоставлял контроля над отдельными компонентами, запускаемыми из [.filename]#/etc/rc#. Например, [.filename]#/etc/rc# не мог перезапустить отдельный демон. Администратору системы приходилось вручную находить процесс демона, завершать его, ждать, пока он действительно завершится, затем искать в [.filename]#/etc/rc# нужные флаги и, наконец, вводить полную командную строку для повторного запуска демона. Задача становилась ещё сложнее и более подверженной ошибкам, если служба состояла из нескольких демонов или требовала дополнительных действий. Одним словом, единый скрипт не справлялся с тем, для чего скрипты вообще предназначены: облегчать жизнь администратору системы. + +Позже была предпринята попытка разделить некоторые части [.filename]#/etc/rc# для возможности отдельного запуска наиболее важных подсистем. Известным примером стал [.filename]#/etc/netstart#, предназначенный для настройки сети. Это позволяло получить доступ к сети в однопользовательском режиме, но плохо интегрировалось в автоматический процесс запуска, так как части его кода требовалось переплетаться с действиями, по сути не связанными с сетью. Именно поэтому [.filename]#/etc/netstart# превратился в [.filename]#/etc/rc.network#. Последний больше не был обычным скриптом; он состоял из больших, запутанных функций man:sh[1], вызываемых из [.filename]#/etc/rc# на разных этапах загрузки системы. Однако по мере того, как задачи при запуске становились разнообразнее и сложнее, "квазимодульный" подход стал ещё большей обузой, чем монолитный [.filename]#/etc/rc#. + +Без чистого и хорошо продуманного каркаса, стартовые скрипты вынуждены были идти на всевозможные ухищрения, чтобы удовлетворить потребности быстро развивающихся BSD-ориентированных операционных систем. В конце концов стало очевидно, что необходимы дополнительные шаги на пути к детализированной и расширяемой системе [.filename]#rc#. Так появилась BSD [.filename]#rc.d#. Её признанными создателями стали Люк Мьюберн и сообщество NetBSD. Позже она была импортирована в FreeBSD. Её название отсылает к расположению системных скриптов для отдельных служб, которое находится в [.filename]#/etc/rc.d#. Вскоре мы узнаем больше о компонентах системы [.filename]#rc.d# и увидим, как вызываются отдельные скрипты. + +Основные идеи, лежащие в основе BSD [.filename]#rc.d#, — это _тонкая модульность_ и __повторное использование кода__. _Тонкая модульность_ означает, что каждая базовая «служба», такая как системный демон или примитивная задача запуска, получает собственный сценарий man:sh[1], способный запустить службу, остановить её, перезагрузить или проверить её состояние. Конкретное действие выбирается аргументом командной строки, переданным в сценарий. Сценарий [.filename]#/etc/rc# по-прежнему управляет запуском системы, но теперь он просто вызывает небольшие сценарии один за другим с аргументом `start`. Также легко выполнять задачи завершения работы, запуская тот же набор сценариев с аргументом `stop`, что и делает [.filename]#/etc/rc.shutdown#. Обратите внимание, насколько это близко следует Unix-подходу, где используется набор небольших специализированных инструментов, каждый из которых выполняет свою задачу наилучшим образом. _Повторное использование кода_ означает, что общие операции реализованы как функции man:sh[1] и собраны в [.filename]#/etc/rc.subr#. Теперь типичный сценарий может состоять всего из нескольких строк кода man:sh[1]. Наконец, важной частью инфраструктуры [.filename]#rc.d# является man:rcorder[8], который помогает [.filename]#/etc/rc# упорядоченно запускать небольшие сценарии с учётом зависимостей между ними. Он также может помочь [.filename]#/etc/rc.shutdown#, поскольку правильный порядок завершения работы противоположен порядку запуска. + +Дизайн BSD [.filename]#rc.d# описан в crossref:rc-scripting[lukem, оригинальной статье Люка Мьюберна], а компоненты [.filename]#rc.d# подробно документированы в crossref:rc-scripting[manpages, соответствующих руководствах]. Однако новичку в [.filename]#rc.d# может быть неочевидно, как связать многочисленные элементы вместе, чтобы создать хорошо структурированный скрипт для конкретной задачи. Поэтому в этой статье будет предпринята попытка описать [.filename]#rc.d# с другого ракурса. В ней будет показано, какие функции следует использовать в ряде типичных случаев и почему. Обратите внимание, что это не руководство, поскольку наша цель — не предоставление готовых рецептов, а демонстрация нескольких простых способов входа в мир [.filename]#rc.d#. Также эта статья не заменяет соответствующие руководства. Не стесняйтесь обращаться к ним для получения более формальной и полной документации во время чтения этой статьи. + +Для понимания этой статьи есть предварительные требования. Прежде всего, вы должны быть знакомы с языком написания сценариев man:sh[1], чтобы освоить [.filename]#rc.d#. Кроме того, вы должны знать, как система выполняет задачи запуска и завершения работы пользовательского пространства, что описано в man:rc[8]. + +Эта статья посвящена ветке FreeBSD в [.filename]#rc.d#. Тем не менее, она может быть полезна и разработчикам NetBSD, потому что две ветки BSD [.filename]#rc.d# не только разделяют одинаковый дизайн, но и остаются схожими в аспектах, видимых авторам скриптов. + +[[rcng-task]] +== Обрисовка задачи + +Немного размышлений перед запуском `$EDITOR` не повредит. Чтобы написать хорошо продуманный скрипт [.filename]#rc.d# для системной службы, сначала нужно ответить на следующие вопросы: + +* Является ли служба обязательной или опциональной? +* Будет ли скрипт обслуживать одну программу, например, демон, или выполнять более сложные действия? +* От каких других служб зависит наша служба, и наоборот? + +Из следующих примеров мы увидим, почему важно знать ответы на эти вопросы. + +[[rcng-dummy]] +== Примитивный скрипт + +Следующий скрипт просто выводит сообщение каждый раз при загрузке системы: + +[.programlisting] +.... +#!/bin/sh <.> + +. /etc/rc.subr <.> + +name="dummy" <.> +start_cmd="${name}_start" <.> +stop_cmd=":" <.> + +dummy_start() <.> +{ + echo "Nothing started." +} + +load_rc_config $name <.> +run_rc_command "$1" <.> +.... + +Вот что следует учитывать: + +➊ Интерпретируемый скрипт должен начинаться с "волшебной" строки shebang. Эта строка указывает программу-интерпретатор для скрипта. Благодаря строке shebang скрипт может быть запущен точно так же, как бинарная программа, при условии что у него установлен бит выполнения. (См. man:chmod[1].) Например, системный администратор может запустить наш скрипт вручную из командной строки: + +[source, shell] +.... +# /etc/rc.d/dummy start +.... + +[NOTE] +==== +Для корректного управления в рамках [.filename]#rc.d# скрипты должны быть написаны на языке man:sh[1]. Если у вас есть служба или порт, который использует двоичную утилиту управления или процедуру запуска, написанную на другом языке, установите этот компонент в [.filename]#/usr/sbin# (для системы) или [.filename]#/usr/local/sbin# (для портов) и вызовите его из man:sh[1] скрипта в соответствующем каталоге [.filename]#rc.d#. +==== + +[TIP] +==== +Если вы хотите узнать подробности о том, почему скрипты [.filename]#rc.d# должны быть написаны на языке man:sh[1], изучите, как [.filename]#/etc/rc# вызывает их с помощью `run_rc_script`, а затем изучите реализацию `run_rc_script` в [.filename]#/etc/rc.subr#. +==== + +➋ В файле [.filename]#/etc/rc.subr# определено несколько функций man:sh[1], которые могут использоваться скриптами [.filename]#rc.d#. Эти функции описаны в man:rc.subr[8]. Хотя теоретически возможно написать скрипт [.filename]#rc.d# без использования man:rc.subr[8], его функции оказываются чрезвычайно полезными и значительно упрощают задачу. Поэтому неудивительно, что все используют man:rc.subr[8] в скриптах [.filename]#rc.d#. Мы не будем исключением. + +Файл [.filename]#rc.d# должен "подгрузить" ([.filename]#/etc/rc.subr#, включить его с помощью "`.`") _до_ вызова функций man:rc.subr[8], чтобы у man:sh[1] была возможность знать об этих функциях заранее. Предпочтительный стиль — подгружать [.filename]#/etc/rc.subr# в самом начале. + +[NOTE] +==== +Некоторые полезные функции, связанные с сетью, предоставляются другим включаемым файлом — [.filename]#/etc/network.subr#. +==== + +➌ [[name-var]]Обязательная переменная `name` определяет имя нашего скрипта. Она требуется man:rc.subr[8]. То есть, каждый скрипт в [.filename]#rc.d# _должен_ установить `name` перед вызовом функций man:rc.subr[8]. + +Теперь самое время раз и навсегда выбрать уникальное имя для нашего скрипта. Мы будем использовать его в нескольких местах при разработке скрипта. Содержимое переменной name должно соответствовать имени скрипта, так как некоторые части FreeBSD (например, crossref:rc-scripting[rcng-service-jails, сервисные клетки (jail)] и функция cpuset в rc framework) зависят от этого. Таким образом, имя файла также не должно содержать символов, которые могут вызвать проблемы в скриптах (например, не используйте дефис "-" и другие). + +[NOTE] +==== +Текущий стиль написания скриптов в [.filename]#rc.d# заключается в заключении значений, присваиваемых переменным, в двойные кавычки. Имейте в виду, что это всего лишь вопрос стиля, который может быть не всегда применим. Вы можете безопасно опустить кавычки вокруг простых слов без метасимволов man:sh[1], тогда как в некоторых случаях вам понадобятся одинарные кавычки, чтобы предотвратить интерпретацию значения man:sh[1]. Программист должен уметь отличать синтаксис языка от стилевых соглашений и разумно использовать и то, и другое. +==== + +➍ Основная идея man:rc.subr[8] заключается в том, что скрипт [.filename]#rc.d# предоставляет обработчики (или методы) для вызова man:rc.subr[8]. В частности, аргументы `start`, `stop` и другие, передаваемые в скрипт [.filename]#rc.d#, обрабатываются таким образом. Метод представляет собой выражение man:sh[1], сохранённое в переменной с именем `argument_cmd`, где _argument_ соответствует тому, что может быть указано в командной строке скрипта. Далее мы увидим, как man:rc.subr[8] предоставляет стандартные методы для типовых аргументов. + +[NOTE] +==== +Чтобы сделать код в [.filename]#rc.d# более единообразным, обычно используют `${name}` везде, где это уместно. Таким образом, множество строк можно просто копировать из одного скрипта в другой. +==== + +➎ Следует помнить, что man:rc.subr[8] предоставляет методы по умолчанию для стандартных аргументов. Следовательно, если мы хотим, чтобы стандартный метод ничего не делал, мы должны переопределить его с помощью no-op man:sh[1] выражения. + +➏ Тело сложного метода может быть реализовано в виде функции. Хорошей практикой является использование осмысленного имени функции. + +[IMPORTANT] +==== +Настоятельно рекомендуется добавлять префикс `${name}` к именам всех функций, определенных в нашем скрипте, чтобы они никогда не конфликтовали с функциями из man:rc.subr[8] или другого общего включаемого файла. +==== + +➐ Этот вызов man:rc.subr[8] загружает переменные man:rc.conf[5]. Наш скрипт пока их не использует, но всё равно рекомендуется загружать man:rc.conf[5], потому что могут быть переменные man:rc.conf[5], управляющие самим man:rc.subr[8]. + +➑ Обычно это последняя команда в скрипте [.filename]#rc.d#. Она вызывает механизм man:rc.subr[8] для выполнения запрошенного действия, используя переменные и методы, предоставленные нашим скриптом. + +[[rcng-confdummy]] +== Настраиваемый фиктивный скрипт + +Теперь добавим некоторые элементы управления в наш тестовый скрипт. Как вам может быть известно, скрипты [.filename]#rc.d# управляются с помощью man:rc.conf[5]. К счастью, man:rc.subr[8] скрывает от нас все сложности. Следующий скрипт использует man:rc.conf[5] через man:rc.subr[8], чтобы проверить, включен ли он вообще, и получить сообщение для отображения во время загрузки. Эти две задачи на самом деле независимы. С одной стороны, скрипт [.filename]#rc.d# может просто поддерживать включение и выключение своего сервиса. С другой стороны, обязательный скрипт [.filename]#rc.d# может иметь переменные конфигурации. Однако мы реализуем обе возможности в одном скрипте: + +[.programlisting] +.... +#!/bin/sh + +. /etc/rc.subr + +name=dummy +rcvar=dummy_enable <.> + +start_cmd="${name}_start" +stop_cmd=":" + +load_rc_config $name <.> +: ${dummy_enable:=no} <.> +: ${dummy_msg="Nothing started."} <.> + +dummy_start() +{ + echo "$dummy_msg" <.> +} + +run_rc_command "$1" +.... + +Что изменилось в этом примере? + +➊ Переменная `rcvar` определяет имя переменной-переключателя ON/OFF. + +➋ Теперь `load_rc_config` вызывается раньше в скрипте, до обращения к любым переменным man:rc.conf[5]. + +[NOTE] +==== +При изучении скриптов в [.filename]#rc.d# следует помнить, что man:sh[1] откладывает вычисление выражений в функции до её вызова. Поэтому не будет ошибкой вызвать `load_rc_config` непосредственно перед `run_rc_command` и при этом обращаться к переменным man:rc.conf[5] из функций методов, экспортируемых в `run_rc_command`. Это связано с тем, что функции методов вызываются `run_rc_command`, который выполняется _после_ `load_rc_config`. +==== + +➌ `run_rc_command` выдаст предупреждение, если переменная `rcvar` установлена, но указанная переменная-флаг не задана. Если ваш скрипт [.filename]#rc.d# предназначен для базовой системы, вы должны добавить значение по умолчанию для флага в [.filename]#/etc/defaults/rc.conf# и задокументировать его в man:rc.conf[5]. В противном случае ваш скрипт должен предоставить значение по умолчанию для флага. Канонический подход для последнего случая показан в примере. + +[NOTE] +==== +Вы можете заставить man:rc.subr[8] действовать так, как если бы переключатель установлен в `ON`, независимо от его текущего значения, добавив перед аргументом скрипта префикс `one` или `force`, например `onestart` или `forcestop`. Однако учтите, что `force` имеет другие опасные эффекты, которые мы затронем ниже, тогда как `one` просто переопределяет переключатель ON/OFF. Например, предположим, что `dummy_enable` установлен в `OFF`. Следующая команда выполнит метод `start`, несмотря на настройку: + +[source, shell] +.... +# /etc/rc.d/dummy onestart +.... + +==== + +➍ Теперь сообщение, отображаемое при загрузке, больше не жестко закодировано в скрипте. Оно задается переменной `dummy_msg` в man:rc.conf[5]. Это простой пример того, как переменные man:rc.conf[5] могут управлять скриптом в [.filename]#rc.d#. + +[IMPORTANT] +==== +Имена всех переменных man:rc.conf[5], используемых исключительно нашим скриптом, _должны_ иметь один и тот же префикс: `${name}_`. Например: `dummy_mode`, `dummy_state_file` и так далее. +==== + +[NOTE] +==== +Хотя можно использовать более короткое имя внутри, например, просто `msg`, добавление уникального префикса `${name}_` ко всем глобальным именам, вводимым нашим скриптом, избавит нас от возможных конфликтов с пространством имен man:rc.subr[8]. + +Как правило, скрипты [.filename]#rc.d# базовой системы не должны предоставлять значения по умолчанию для своих переменных man:rc.conf[5], поскольку значения по умолчанию должны быть установлены в [.filename]#/etc/defaults/rc.conf#. С другой стороны, скрипты [.filename]#rc.d# для портов должны предоставлять значения по умолчанию, как показано в примере. +==== + +➎ Здесь мы используем `dummy_msg` для фактического управления нашим скриптом, т.е., для выдачи переменного сообщения. Использование shell-функции здесь избыточно, так как она выполняет только одну команду; равнозначной альтернативой является: + +[.programlisting] +.... +start_cmd="echo \"$dummy_msg\"" +.... + +[[rcng-daemon]] +== Запуск и остановка простого демона + +Мы ранее говорили, что man:rc.subr[8] может предоставлять методы по умолчанию. Очевидно, что такие методы не могут быть слишком общими. Они подходят для стандартного случая запуска и остановки простого демона. Предположим, что нам нужно написать скрипт [.filename]#rc.d# для такого демона с именем `mumbled`. Вот он: + +[.programlisting] +.... +#!/bin/sh + +. /etc/rc.subr + +name=mumbled +rcvar=mumbled_enable + +command="/usr/sbin/${name}" <.> + +load_rc_config $name +run_rc_command "$1" +.... + +Приятно просто, не так ли? Давайте рассмотрим наш небольшой скрипт. Единственное новое, на что стоит обратить внимание, это следующее: + +➊ Переменная `command` имеет значение для man:rc.subr[8]. Если она установлена, man:rc.subr[8] будет действовать по сценарию обслуживания обычного демона. В частности, будут предоставлены стандартные методы для таких аргументов: `start`, `stop`, `restart`, `poll` и `status`. + +Демон будет запущен выполнением `$command` с флагами командной строки, указанными в `$mumbled_flags`. Таким образом, все входные данные для метода `start` по умолчанию доступны в переменных, установленных нашим скриптом. В отличие от `start`, другие методы могут требовать дополнительной информации о запущенном процессе. Например, `stop` должен знать PID процесса, чтобы завершить его. В данном случае, man:rc.subr[8] будет просматривать список всех процессов, ища процесс с именем, равным `procname`. Последний является ещё одной значимой переменной для man:rc.subr[8], и её значение по умолчанию совпадает со значением `command`. Другими словами, когда мы устанавливаем `command`, `procname` фактически устанавливается в то же значение. Это позволяет нашему скрипту завершить демон и проверить, запущен ли он вообще. + +[NOTE] +==== +Некоторые программы на самом деле являются исполняемыми скриптами. Система запускает такие скрипты, запуская их интерпретатор и передавая ему имя скрипта в качестве аргумента командной строки. Это отражается в списке процессов, что может сбить с толку man:rc.subr[8]. Дополнительно следует установить `command_interpreter`, чтобы man:rc.subr[8] знал фактическое имя процесса, если `$command` является скриптом. + +Для каждого скрипта [.filename]#rc.d# существует необязательная переменная man:rc.conf[5], которая имеет приоритет над `command`. Её имя формируется следующим образом: `${name}_program`, где `name` — это обязательная переменная, которую мы обсуждали crossref:rc-scripting[name-var, ранее]. Например, в данном случае это будет `mumbled_program`. Именно man:rc.subr[8] обеспечивает переопределение `command` с помощью `${name}_program`. + +Конечно, man:sh[1] позволяет установить `${name}_program` из man:rc.conf[5] или самого скрипта, даже если `command` не задан. В этом случае специальные свойства `${name}_program` теряются, и она становится обычной переменной, которую ваш скрипт может использовать для своих целей. Однако использование `${name}_program` в одиночку не рекомендуется, так как совместное использование с `command` стало идиомой в [.filename]#rc.d# скриптах. +==== + +Для получения более подробной информации о стандартных методах обратитесь к man:rc.subr[8]. + +[[rcng-daemon-adv]] +== Запуск и остановка продвинутого демона + +Добавим немного мяса к костям предыдущего скрипта и сделаем его более сложным и функциональным. Стандартные методы могут хорошо справляться с задачами, но иногда требуется их тонкая настройка. Теперь мы узнаем, как адаптировать стандартные методы под наши нужды. + +[.programlisting] +.... +#!/bin/sh + +. /etc/rc.subr + +name=mumbled +rcvar=mumbled_enable + +command="/usr/sbin/${name}" +command_args="mock arguments > /dev/null 2>&1" <.> + +pidfile="/var/run/${name}.pid" <.> + +required_files="/etc/${name}.conf /usr/share/misc/${name}.rules" <.> + +sig_reload="USR1" <.> + +start_precmd="${name}_prestart" <.> +stop_postcmd="echo Bye-bye" <.> + +extra_commands="reload plugh xyzzy" <.> + +plugh_cmd="mumbled_plugh" <.> +xyzzy_cmd="echo 'Nothing happens.'" + +mumbled_prestart() +{ + if checkyesno mumbled_smart; then <.> + rc_flags="-o smart ${rc_flags}" <.> + fi + case "$mumbled_mode" in + foo) + rc_flags="-frotz ${rc_flags}" + ;; + bar) + rc_flags="-baz ${rc_flags}" + ;; + *) + warn "Invalid value for mumbled_mode" <.> + return 1 <.> + ;; + esac + run_rc_command xyzzy <.> + return 0 +} + +mumbled_plugh() <.> +{ + echo 'A hollow voice says "plugh".' +} + +load_rc_config $name +run_rc_command "$1" +.... + +➊ Дополнительные аргументы для `$command` могут быть переданы в `command_args`. Они будут добавлены в командную строку после `$mumbled_flags`. Поскольку итоговая командная строка передаётся в `eval` для фактического выполнения, перенаправления ввода и вывода могут быть указаны в `command_args`. + +[NOTE] +==== +Никогда не включайте параметры с дефисами, такие как `-X` или `--foo`, в `command_args`. Содержимое `command_args` будет добавлено в конец итоговой командной строки, поэтому, скорее всего, окажется после аргументов, указанных в `${name}_flags`; однако большинство команд не распознают параметры с дефисами после обычных аргументов. Лучший способ передать дополнительные параметры в `$command` — добавить их в начало `${name}_flags`. Другой способ — изменить `rc_flags` crossref:rc-scripting[rc-flags, как показано далее]. +==== + +➋ Вежливый демон должен создавать _pidfile_, чтобы его процесс можно было найти проще и надежнее. Переменная `pidfile`, если она установлена, указывает man:rc.subr[8], где можно найти pidfile для использования его стандартными методами. + +[NOTE] +==== +На самом деле, man:rc.subr[8] также использует pidfile для проверки, запущен ли демон, перед его запуском. Эту проверку можно пропустить, используя аргумент `faststart`. +==== + +➌ Если демон не может работать без определённых файлов, просто укажите их в `required_files`, и man:rc.subr[8] проверит их наличие перед запуском демона. Также существуют `required_dirs` и `required_vars` для каталогов и переменных окружения соответственно. Все они подробно описаны в man:rc.subr[8]. + +[NOTE] +==== +Метод по умолчанию из man:rc.subr[8] можно принудительно заставить пропустить проверки предварительных условий, используя аргумент `forcestart` в скрипте. +==== + +➍ Мы можем настроить сигналы, отправляемые демону, если они отличаются от общеизвестных. В частности, `sig_reload` указывает сигнал, который заставляет демона перезагрузить свою конфигурацию; по умолчанию это SIGHUP. Другой сигнал отправляется для остановки процесса демона; по умолчанию используется SIGTERM, но это можно изменить, установив `sig_stop` соответствующим образом. + +[NOTE] +==== +Имена сигналов должны указываться для man:rc.subr[8] без префикса `SIG`, как показано в примере. Версия man:kill[1] в FreeBSD может распознавать префикс `SIG`, но версии из других типов ОС могут не поддерживать его. +==== + +➎➏ Выполнение дополнительных задач до или после стандартных методов — это просто. Для каждого аргумента команды, поддерживаемого нашим скриптом, мы можем определить `argument_precmd` и `argument_postcmd`. Эти команды man:sh[1] вызываются до и после соответствующего метода, что очевидно из их названий. + +[NOTE] +==== +Переопределение стандартного метода с помощью пользовательского `argument_cmd` всё равно не мешает нам использовать `argument_precmd` или `argument_postcmd`, если это необходимо. В частности, первый полезен для проверки пользовательских сложных условий, которые должны быть выполнены перед выполнением самой команды. Использование `argument_precmd` вместе с `argument_cmd` позволяет логически разделить проверки от действия. + +Не забывайте, что вы можете вставлять любые допустимые выражения из man:sh[1] в определяемые вами методы, а также команды pre- и post-. Просто вызывать функцию, которая выполняет основную работу, — это хороший стиль в большинстве случаев, но никогда не позволяйте стилю ограничивать ваше понимание того, что происходит за кулисами. +==== + +➐ Если мы хотим реализовать пользовательские аргументы, которые также можно рассматривать как _команды_ для нашего скрипта, необходимо перечислить их в `extra_commands` и предоставить методы для их обработки. + +[NOTE] +==== +Команда `reload` является особенной. С одной стороны, у неё есть предустановленный метод в man:rc.subr[8]. С другой стороны, `reload` не предлагается по умолчанию. Причина в том, что не все демоны используют одинаковый механизм перезагрузки, а у некоторых вообще нет ничего для перезагрузки. Поэтому нам нужно явно запросить предоставление встроенной функциональности. Это можно сделать с помощью `extra_commands`. + +Что мы получаем от метода по умолчанию для `reload`? Довольно часто демоны перезагружают свою конфигурацию при получении сигнала — обычно, SIGHUP. Поэтому man:rc.subr[8] пытается перезагрузить демона, отправляя ему сигнал. Сигнал предустановлен на SIGHUP, но может быть изменён через `sig_reload` при необходимости. +==== + +➑⓮ Наш скрипт поддерживает две нестандартные команды: `plugh` и `xyzzy`. Мы видели их в списке `extra_commands`, и теперь пришло время реализовать методы для них. Метод для `xyzzy` просто встроен в код, а для `plugh` он реализован как функция `mumbled_plugh`. + +Нестандартные команды не вызываются во время запуска или завершения работы. Обычно они предназначены для удобства системного администратора. Они также могут использоваться другими подсистемами, например, man:devd[8], если указаны в man:devd.conf[5]. + +Полный список доступных команд можно найти в строке использования, выводимой man:rc.subr[8], когда скрипт вызывается без аргументов. Например, вот строка использования из изучаемого скрипта: + +[source, shell] +.... +# /etc/rc.d/mumbled +Usage: /etc/rc.d/mumbled [fast|force|one](start|stop|restart|rcvar|reload|plugh|xyzzy|status|poll) +.... + +⓭ Скрипт может вызывать свои собственные стандартные или нестандартные команды, если это необходимо. Это может выглядеть похоже на вызов функций, но мы знаем, что команды и функции оболочки не всегда одно и то же. Например, `xyzzy` не реализован как функция в данном случае. Кроме того, могут существовать пред-команда и пост-команда, которые должны вызываться в определённом порядке. Поэтому правильный способ для скрипта выполнить свою собственную команду — с помощью man:rc.subr[8], как показано в примере. + +➒ Полезная функция `checkyesno` предоставляется man:rc.subr[8]. Она принимает имя переменной в качестве аргумента и возвращает нулевой код выхода только если переменная установлена в `YES`, `TRUE`, `ON` или `1`, без учёта регистра; в противном случае возвращается ненулевой код выхода. В последнем случае функция проверяет, установлена ли переменная в `NO`, `FALSE`, `OFF` или `0`, также без учёта регистра; если переменная содержит что-то иное (т.е. мусор), функция выводит предупреждение. + +Имейте в виду, что для man:sh[1] нулевой код возврата означает истину, а ненулевой код возврата означает ложь. + +[IMPORTANT] +==== +Функция `checkyesno` принимает __имя переменной__. Не передавайте ей _значение_ переменной; это не будет работать, как ожидается. + +Ниже приведено правильное использование `checkyesno`: + +[.programlisting] +.... +if checkyesno mumbled_enable; then + foo +fi +.... + +Напротив, вызов `checkyesno`, как показано ниже, не сработает — по крайней мере, не так, как ожидается: + +[.programlisting] +.... +if checkyesno "${mumbled_enable}"; then + foo +fi +.... + +==== + +➓ [[rc-flags]] Мы можем влиять на флаги, передаваемые команде `$command`, изменяя `rc_flags` в `$start_precmd`. + +⓫ В некоторых случаях может потребоваться вывести важное сообщение, которое также должно попасть в `syslog`. Это можно легко сделать с помощью следующих функций man:rc.subr[8]: `debug`, `info`, `warn` и `err`. Последняя функция завершает выполнение скрипта с указанным кодом. + +⓬ Коды выхода из методов и их предварительных команд не просто игнорируются по умолчанию. Если `argument_precmd` возвращает ненулевой код выхода, основной метод не будет выполнен. В свою очередь, `argument_postcmd` не будет вызван, если основной метод возвращает ненулевой код выхода. + +[NOTE] +==== +Однако man:rc.subr[8] можно указать из командной строки игнорировать эти коды завершения и выполнять все команды в любом случае, добавив префикс `force` к аргументу, например `forcestart`. +==== + +[[rcng-hookup]] +== Подключение скрипта к инфраструктуре rc.d + +После написания скрипта его необходимо интегрировать в [.filename]#rc.d#. Ключевой шаг — установка скрипта в [.filename]#/etc/rc.d# (для базовой системы) или [.filename]#/usr/local/etc/rc.d# (для портов). И [.filename]#bsd.prog.mk#, и [.filename]#bsd.port.mk# предоставляют удобные механизмы для этого, и обычно вам не нужно беспокоиться о правильных правах доступа и режиме. Системные скрипты должны устанавливаться из [.filename]#src/libexec/rc/rc.d# через [.filename]#Makefile#, находящийся там. Скрипты портов можно установить с помощью `USE_RC_SUBR`, как описано extref:{porters-handbook}special/[в Руководстве FreeBSD по созданию портов, rc-скрипты]. + +Однако следует заранее продумать место нашего скрипта в последовательности запуска системы. Скорее всего, обслуживаемый нашим скриптом сервис зависит от других сервисов. Например, сетевой демон не может работать без поднятых сетевых интерфейсов и маршрутизации. Даже если сервис, казалось бы, ничего не требует, он вряд ли сможет запуститься до проверки и монтирования основных файловых систем. + +Мы уже упоминали man:rcorder[8]. Теперь пришло время рассмотреть его подробнее. В двух словах, man:rcorder[8] принимает набор файлов, анализирует их содержимое и выводит на `stdout` список этих файлов, упорядоченный по зависимостям. Главная идея заключается в том, чтобы хранить информацию о зависимостях _внутри_ файлов, чтобы каждый файл мог описывать только себя. Файл может содержать следующую информацию: + +* имена "условий" (что для нас означает сервисы), которые он __предоставляет__; +* имена "условий", которые он __требует__; +* имена "условий", перед которыми должен выполняться этот файл; +* дополнительные _ключевые слова_, которые могут использоваться для выбора подмножества из всего набора файлов (man:rcorder[8] может быть настроен с помощью опций для включения или исключения файлов, содержащих указанные ключевые слова.) + +Неудивительно, что man:rcorder[8] может обрабатывать только текстовые файлы с синтаксисом, близким к man:sh[1]. То есть специальные строки, понимаемые man:rcorder[8], выглядят как комментарии в man:sh[1]. Синтаксис таких специальных строк довольно жёсткий, чтобы упростить их обработку. Подробности см. в man:rcorder[8]. + +Помимо использования специальных строк man:rcorder[8], скрипт может настаивать на своей зависимости от другой службы, просто принудительно запуская её. Это может быть необходимо, когда другая служба является опциональной и не запускается самостоятельно, потому что системный администратор ошибочно отключил её в man:rc.conf[5]. + +С учетом этих общих знаний рассмотрим простой скрипт демона, дополненный зависимостями: + +[.programlisting] +.... +#!/bin/sh + +# PROVIDE: mumbled oldmumble <.> +# REQUIRE: DAEMON cleanvar frotz <.> +# BEFORE: LOGIN <.> +# KEYWORD: nojail shutdown <.> + +. /etc/rc.subr + +name=mumbled +rcvar=mumbled_enable + +command="/usr/sbin/${name}" +start_precmd="${name}_prestart" + +mumbled_prestart() +{ + if ! checkyesno frotz_enable && \ + ! /etc/rc.d/frotz forcestatus 1>/dev/null 2>&1; then + force_depend frotz || return 1 <.> + fi + return 0 +} + +load_rc_config $name +run_rc_command "$1" +.... + +Как и ранее, следует детальный анализ: + +➊ Эта строка объявляет названия "условий", которые предоставляет наш скрипт. Теперь другие скрипты могут указывать зависимость от нашего скрипта по этим именам. + +[NOTE] +==== +Обычно скрипт указывает одно предоставленное условие. Однако ничто не мешает нам перечислить несколько условий, например, по причинам совместимости. + +В любом случае, название основного или единственного условия `PROVIDE:` должно совпадать с `${name}`. +==== + +➋➌ Таким образом, наш скрипт указывает, от каких "условий", предоставляемых другими скриптами, он зависит. Согласно строкам, наш скрипт просит man:rcorder[8] разместить его после скрипта(ов), предоставляющих [.filename]#DAEMON# и [.filename]#cleanvar#, но перед тем, который предоставляет [.filename]#LOGIN#. + +[NOTE] +==== +Строку `BEFORE:` не следует использовать для обхода неполного списка зависимостей в другом скрипте. Правильный случай для использования `BEFORE:` — когда другой скрипт не зависит от нашего, но наш скрипт может выполнить свою задачу лучше, если запустится до другого. Типичный пример из реальной жизни — сетевые интерфейсы и межсетевой экран: хотя интерфейсы не зависят от межсетевого экрана при выполнении своей работы, безопасность системы выиграет, если межсетевой экран будет готов до начала сетевого трафика. + +Помимо условий, соответствующих отдельным службам, существуют метаусловия и их "заглушки" скриптов, используемые для обеспечения выполнения определённых групп операций в заданном порядке. Они обозначаются именами в [.filename]#ВЕРХНЕМ РЕГИСТРЕ#. Их список и назначение можно найти в man:rc[8]. + +Имейте в виду, что указание имени службы в строке `REQUIRE:` не гарантирует, что служба действительно будет запущена к моменту старта нашего скрипта. Требуемая служба может не запуститься или быть отключена в man:rc.conf[5]. Очевидно, man:rcorder[8] не может отслеживать такие детали, и man:rc[8] тоже этого не делает. Следовательно, приложение, запускаемое нашим скриптом, должно быть способно обрабатывать ситуации, когда требуемые службы недоступны. В некоторых случаях мы можем помочь ему, как описано в crossref:rc-scripting[forcedep, ниже] +==== + +[[keywords]]➍ Как мы помним из текста выше, ключевые слова man:rcorder[8] могут использоваться для выбора или исключения некоторых скриптов. А именно, любой потребитель man:rcorder[8] может указать с помощью опций `-k` и `-s`, какие ключевые слова находятся в "списке сохранения" и "списке пропуска" соответственно. Из всех файлов, подлежащих сортировке по зависимостям, man:rcorder[8] выберет только те, которые имеют ключевое слово из списка сохранения (если он не пуст) и не имеют ключевого слова из списка пропуска. + +В FreeBSD, man:rcorder[8] используется [.filename]#/etc/rc# и [.filename]#/etc/rc.shutdown#. Эти два скрипта определяют стандартный список ключевых слов [.filename]#rc.d# FreeBSD и их значения следующим образом: + +nojail:: Сервис не предназначен для окружения man:jail[8]. Процедуры автоматического запуска и остановки будут игнорировать скрипт, если он находится внутри клетки. + +nostart:: Служба должна запускаться вручную или не запускаться вовсе. Процедура автоматического запуска проигнорирует скрипт. В сочетании с ключевым словом [.filename]#shutdown# это может использоваться для написания скриптов, выполняющих действия только при выключении системы. + +shutdown:: Этот ключевой параметр должен быть указан __явно__, если службу необходимо остановить перед завершением работы системы. + +[NOTE] +==== +Когда система собирается завершить работу, выполняется [.filename]#/etc/rc.shutdown#. Предполагается, что большинству скриптов [.filename]#rc.d# в этот момент нечего делать. Поэтому [.filename]#/etc/rc.shutdown# выборочно запускает скрипты [.filename]#rc.d# с ключевым словом [.filename]#shutdown#, фактически игнорируя остальные скрипты. Для ещё более быстрого завершения работы [.filename]#/etc/rc.shutdown# передаёт команду [.filename]#faststop# запускаемым скриптам, чтобы они пропускали предварительные проверки, например, проверку pid-файла. Поскольку зависимые службы должны быть остановлены до своих зависимостей, [.filename]#/etc/rc.shutdown# запускает скрипты в обратном порядке зависимостей. Если вы пишете настоящий скрипт [.filename]#rc.d#, стоит подумать, актуален ли он во время завершения работы системы. Например, если ваш скрипт выполняет свою работу только в ответ на команду [.filename]#start#, то включать это ключевое слово не нужно. Однако если ваш скрипт управляет службой, вероятно, стоит остановить её до того, как система перейдёт к финальной стадии завершения работы, описанной в man:halt[8]. В частности, службу следует останавливать явно, если для её корректного завершения требуется значительное время или специальные действия. Типичный пример такой службы — система управления базами данных. +==== + +[[forcedep]]➎ Прежде всего, `force_depend` следует использовать с большой осторожностью. Обычно лучше пересмотреть иерархию конфигурационных переменных для ваших [.filename]#rc.d# скриптов, если они взаимозависимы. + +Если вам всё ещё не обойтись без `force_depend`, в примере показано, как вызвать его условно. В примере наш демон `mumbled` требует, чтобы другой демон, `frotz`, был запущен заранее. Однако `frotz` также является опциональным, и man:rcorder[8] ничего не знает о таких деталях. К счастью, наш скрипт имеет доступ ко всем переменным man:rc.conf[5]. Если `frotz_enable` имеет значение true, мы надеемся на лучшее и полагаемся на [.filename]#rc.d#, что `frotz` был запущен. В противном случае мы принудительно проверяем статус `frotz`. Наконец, мы принудительно устанавливаем зависимость от `frotz`, если обнаруживаем, что он не запущен. `force_depend` выдаст предупреждение, так как его следует вызывать только в случае обнаружения неправильной конфигурации. + +[[rcng-args]] +== Придание большей гибкости скрипту rc.d + +При вызове во время запуска или завершения работы скрипт [.filename]#rc.d# должен воздействовать на всю подсистему, за которую он отвечает. Например, [.filename]#/etc/rc.d/netif# должен запускать или останавливать все сетевые интерфейсы, описанные в man:rc.conf[5]. Любая из этих задач может быть однозначно указана единственным аргументом команды, таким как `start` или `stop`. Между запуском и завершением работы скрипты [.filename]#rc.d# помогают администратору управлять работающей системой, и именно тогда возникает потребность в большей гибкости и точности. Например, администратор может добавить настройки нового сетевого интерфейса в man:rc.conf[5], а затем запустить его, не затрагивая работу существующих интерфейсов. В следующий раз администратору может потребоваться остановить отдельный сетевой интерфейс. В духе командной строки, соответствующий скрипт [.filename]#rc.d# требует дополнительного аргумента — имени интерфейса. + +К счастью, man:rc.subr[8] позволяет передавать любое количество аргументов (в пределах системных ограничений) методам скрипта. Благодаря этому изменения в самом скрипте могут быть минимальными. + +Как man:rc.subr[8] может получить доступ к дополнительным аргументам командной строки. Должен ли он просто захватывать их напрямую? Ни в коем случае. Во-первых, функция man:sh[1] не имеет доступа к позиционным параметрам своего вызывающего объекта, но man:rc.subr[8] — это просто набор таких функций. Во-вторых, хороший стиль [.filename]#rc.d# предписывает, что именно главный скрипт должен решать, какие аргументы передавать его методам. + +Итак, подход, принятый в man:rc.subr[8], следующий: `run_rc_command` передаёт все свои аргументы, кроме первого, в соответствующий метод в неизменном виде. Первый, опущенный аргумент — это имя самого метода: `start`, `stop` и т.д. Он будет удалён с помощью `shift` в `run_rc_command`, так что то, что было `$2` в оригинальной командной строке, будет представлено как `$1` в методе, и так далее. + +Чтобы проиллюстрировать эту возможность, давайте изменим примитивный скрипт-заглушку так, чтобы его сообщения зависели от дополнительных переданных аргументов. Вот как это выглядит: + +[.programlisting] +.... +#!/bin/sh + +. /etc/rc.subr + +name="dummy" +start_cmd="${name}_start" +stop_cmd=":" +kiss_cmd="${name}_kiss" +extra_commands="kiss" + +dummy_start() +{ + if [ $# -gt 0 ]; then <.> + echo "Greeting message: $*" + else + echo "Nothing started." + fi +} + +dummy_kiss() +{ + echo -n "A ghost gives you a kiss" + if [ $# -gt 0 ]; then <.> + echo -n " and whispers: $*" + fi + case "$*" in + *[.!?]) + echo + ;; + *) + echo . + ;; + esac +} + +load_rc_config $name +run_rc_command "$@" <.> +.... + +Какие основные изменения мы можем заметить в скрипте? + +➊ Все аргументы, которые вы вводите после `start`, могут стать позиционными параметрами для соответствующего метода. Мы можем использовать их любым способом в соответствии с нашей задачей, навыками и предпочтениями. В текущем примере мы просто передаем все их в man:echo[1] как одну строку в следующей строке — обратите внимание на `$*` в двойных кавычках. Вот как теперь можно вызывать этот скрипт: + +[source, shell] +.... +# /etc/rc.d/dummy start +Nothing started. + +# /etc/rc.d/dummy start Hello world! +Greeting message: Hello world! +.... + +➋ То же самое относится к любому методу, который предоставляет наш скрипт, не только к стандартному. Мы добавили пользовательский метод с именем `kiss`, и он может использовать дополнительные аргументы не меньше, чем `start`. Например: + +[source, shell] +.... +# /etc/rc.d/dummy kiss +A ghost gives you a kiss. + +# /etc/rc.d/dummy kiss Once I was Etaoin Shrdlu... +A ghost gives you a kiss and whispers: Once I was Etaoin Shrdlu... +.... + +➌ Если мы хотим просто передать все дополнительные аргументы любому методу, мы можем просто заменить `"$@"` на `"$1"` в последней строке нашего скрипта, где мы вызываем `run_rc_command`. + +[IMPORTANT] +==== +Программист man:sh[1] должен понимать тонкую разницу между `$*` и `$@` как способами обозначения всех позиционных параметров. Для детального обсуждения обратитесь к хорошему руководству по написанию скриптов на man:sh[1]. _Не используйте_ эти выражения, пока полностью не поймёте их, так как их неправильное применение приведёт к созданию ненадёжных и небезопасных скриптов. +==== + +[NOTE] +==== +В настоящее время в `run_rc_command` может присутствовать ошибка, которая мешает ему сохранять исходные границы между аргументами. То есть аргументы с встроенными пробелами могут обрабатываться некорректно. Ошибка возникает из-за неправильного использования `$*`. +==== + +[[rcng-service-jails]] +== Подготовка скрипта для сервисных клеток + +Скрипты, запускающие долго работающую службу, подходят для служебных клеток и должны поставляться с соответствующей конфигурацией сервисной клетки. + +Некоторые примеры скриптов, которые не подходят для запуска в сервисной клетке: + +* любой скрипт, который в команде start только изменяет настройки времени выполнения для программ или ядра, +* или пытается что-то смонтировать, +* или находит и удаляет файлы + +Необходимо предотвратить использование внутри сервисных клеток скриптов, не предназначенных для запуска в сервисной клетке. + +Скрипт с долго работающей службой, которому необходимо выполнить одно из перечисленных выше действий перед запуском или после остановки, может быть разделён на два скрипта с зависимостями или использовать части `precommand` и `postcommand` скрипта для выполнения этого действия. + +По умолчанию только части `start` и `stop` скрипта выполняются внутри сервисной клетки, остальное выполняется вне клетки. Таким образом, любые настройки, используемые в частях `start`/`stop` скрипта, не могут быть заданы, например, из `precommand`. + +Чтобы сделать скрипт готовым к использованию с extref:../../books/handbook/jails/#service-jails[Сервисными Клетками], необходимо добавить всего одну строку конфигурации: + +[.programlisting] +.... +#!/bin/sh + +. /etc/rc.subr + +name="dummy" +start_cmd="${name}_start" +stop_cmd=":" + +: ${dummy_svcj_options:=""} <.> + +dummy_start() +{ + echo "Nothing started." +} + +load_rc_config $name +run_rc_command "$1" +.... + +➊ Если имеет смысл, чтобы скрипт выполнялся в клетке, он должен иметь переопределяемую конфигурацию сервисных клеток. Если ему не требуется доступ к сети или любым другим ресурсам, которые ограничены в клетках, достаточно пустой конфигурации, как показано. + +Строго говоря, пустая конфигурация не обязательна, но она явно указывает, что скрипт готов к работе с сервисными клетками и не требует дополнительных разрешений для клеток. Поэтому настоятельно рекомендуется добавить такую пустую конфигурацию в таком случае. Наиболее распространённая опция — "net_basic", которая позволяет использовать IPv4 и IPv6 адреса хоста. Все возможные опции описаны в man:rc.conf[5]. + +Если настройка запуска/остановки зависит от переменных из rc-фреймворка (например, заданных в man:rc.conf[5]), это должно обрабатываться с помощью ``load_rc_config`` и ``run_rc_command``, а не внутри precommand. + +Если по какой-то причине скрипт не может быть запущен внутри сервисной клетки, например, потому что его невозможно запустить или нет смысла запускать его в клетке, используйте следующее: + +[.programlisting] +.... +#!/bin/sh + +. /etc/rc.subr + +name="dummy" +start_cmd="${name}_start" +stop_cmd=":" + +dummy_start() +{ + echo "Nothing started." +} + +load_rc_config $name +dummy_svcj="NO" # does not make sense to run in a svcj <.> +run_rc_command "$1" +.... + +➊ Отключение должно происходить после вызова ``load_rc_config``, иначе параметр из man:rc.conf[5] может переопределить его. + +[[rcng-instancing]] +== Продвинутые сценарии rc: запуск нескольких экземпляров + +Иногда полезно запускать несколько экземпляров службы. Обычно требуется иметь возможность независимо запускать/останавливать такие экземпляры, а также иметь отдельный файл конфигурации для каждого из них. Каждый экземпляр должен запускаться при загрузке, после обновления каждый экземпляр должен оставаться, и при этом должен обновиться. + +Вот пример rc-скрипта, который поддерживает это: + +[.programlisting] +.... +#!/bin/sh + +# +# PROVIDE: dummy +# REQUIRE: NETWORKING SERVERS +# KEYWORD: shutdown +# +# Add these following line to /etc/rc.conf.local or /etc/rc.conf +# to enable this service: +# +# dummy_enable (bool): Set it to YES to enable dummy on startup. +# Default: NO +# dummy_user (string): User account to run with. +# Default: www +# + +. /etc/rc.subr + +case $0 in <.> +/etc/rc*) + # during boot (shutdown) $0 is /etc/rc (/etc/rc.shutdown), + # so get the name of the script from $_file + name=$_file + ;; +*) + name=$0 + ;; +esac + +name=${name##*/} <.> +rcvar="${name}_enable" <.> +desc="Short description of this service" +command="/usr/local/sbin/dummy" + +load_rc_config "$name" + +eval "${rcvar}=\${${rcvar}:-'NO'}" <.> +eval "${name}_svcj_options=\${${name}_svcj_options:-'net_basic'}" <.> +eval "_dummy_user=\${${name}_user:-'www'}" <.> + +_dummy_configname=/usr/local/etc/${name}.cfg <.> +pidfile=/var/run/dummy/${name}.pid +required_files ${_dummy_configname} +command_args="-u ${_dummy_user} -c ${_dummy_configfile} -p ${pidfile}" + +run_rc_command "$1" +.... + +➊ и ➋ убедитесь, что переменная name установлена в значение man:basename[1] имени скрипта. Если имя файла — [.filename]#/usr/local/etc/rc.d/dummy#, то name будет установлено в [.filename]#dummy#. Таким образом, изменение имени rc-скрипта автоматически изменит содержимое переменной name. + +➌ указывает имя переменной, которая используется в [.filename]#rc.conf# для включения этой службы на основе имени файла этого скрипта. В данном примере это преобразуется в dummy_enable. + +➍ убеждается, что значение по умолчанию для переменной _enable установлено в NO. + +➎ Вот пример установки некоторых значений по умолчанию для переменных фреймворка, специфичных для службы, в данном случае — опций клетки службы. + +➏ и ➐ устанавливают переменные, внутренние для скрипта (обратите внимание на подчёркивание в начале _dummy_user, чтобы отличать её от dummy_user, которая может быть задана в [.filename]#rc.conf#). + +Часть в ➎ предназначена для переменных, которые не используются внутри самого скрипта, но используются в рамках rc. Все переменные, которые используются как параметры в скрипте, присваиваются общей переменной, как в ➐, чтобы упростить их использование (нет необходимости выполнять eval при каждом обращении). + +Этот скрипт теперь будет вести себя по-другому, если скрипт запуска имеет другое имя. Это позволяет создавать символьные ссылки на него: + +[source, shell] +.... +# ln -s dummy /usr/local/etc/rc.d/dummy_foo +# sysrc dummy_foo_enable=YES +# service dummy_foo start +.... + +Вышеприведенное создает экземпляр службы dummy с именем dummy_foo. Он использует не файл конфигурации [.filename]#/usr/local/etc/dummy.cfg#, а файл конфигурации [.filename]#/usr/local/etc/dummy_foo.cfg# (➐), и использует PID-файл [.filename]#/var/run/dummy/dummy_foo.pid# вместо [.filename]#/var/run/dummy/dummy.pid#. + +Сервисы dummy и dummy_foo могут управляться независимо друг от друга, при этом скрипт запуска обновляется автоматически при обновлении пакета (благодаря символьной ссылке). Это не обновляет строку REQUIRE, поэтому нет простого способа зависеть от конкретного экземпляра. Чтобы зависеть от конкретного экземпляра в порядке запуска, необходимо создать копию вместо использования символьной ссылки. Это предотвращает автоматическое применение изменений в скрипте запуска при установке обновления. + +[[rcng-furthur]] +== Дополнительная литература + +[[lukem]]http://www.mewburn.net/luke/papers/rc.d.pdf[Оригинальная статья Люка Мьюберна] предлагает общий обзор [.filename]#rc.d# и подробное обоснование принятых при его проектировании решений. В ней представлено понимание всего фреймворка [.filename]#rc.d# и его места в современной BSD-системе. + +[[manpages]]Руководства man:rc[8], man:rc.subr[8] и man:rcorder[8] подробно описывают компоненты [.filename]#rc.d#. Без изучения этих руководств и обращения к ним при написании собственных скриптов невозможно в полной мере использовать возможности [.filename]#rc.d#. + +Основным источником рабочих, жизненных примеров является [.filename]#/etc/rc.d# в работающей системе. Его содержимое легко и приятно читать, поскольку большинство сложных моментов скрыто глубоко в man:rc.subr[8]. Однако помните, что скрипты в [.filename]#/etc/rc.d# были написаны не ангелами, поэтому они могут содержать ошибки и неоптимальные решения. Теперь вы можете их улучшить! |