Практическое руководство по написанию rc.d скриптов в BSD

Исторически в BSD был монолитный стартовый сценарий /etc/rc. Он вызывался init(8) во время загрузки системы и выполнял все задачи пользовательского пространства, необходимые для многопользовательского режима: проверку и монтирование файловых систем, настройку сети, запуск демонов и так далее. Точный список задач не был одинаковым в каждой системе; администраторам требовалось его настраивать. За редкими исключениями, /etc/rc приходилось изменять, и настоящим хакерам это нравилось.

Основная проблема монолитного подхода заключалась в том, что он не предоставлял контроля над отдельными компонентами, запускаемыми из /etc/rc. Например, /etc/rc не мог перезапустить отдельный демон. Администратору системы приходилось вручную находить процесс демона, завершать его, ждать, пока он действительно завершится, затем искать в /etc/rc нужные флаги и, наконец, вводить полную командную строку для повторного запуска демона. Задача становилась ещё сложнее и более подверженной ошибкам, если служба состояла из нескольких демонов или требовала дополнительных действий. Одним словом, единый скрипт не справлялся с тем, для чего скрипты вообще предназначены: облегчать жизнь администратору системы.

Позже была предпринята попытка разделить некоторые части /etc/rc для возможности отдельного запуска наиболее важных подсистем. Известным примером стал /etc/netstart, предназначенный для настройки сети. Это позволяло получить доступ к сети в однопользовательском режиме, но плохо интегрировалось в автоматический процесс запуска, так как части его кода требовалось переплетаться с действиями, по сути не связанными с сетью. Именно поэтому /etc/netstart превратился в /etc/rc.network. Последний больше не был обычным скриптом; он состоял из больших, запутанных функций sh(1), вызываемых из /etc/rc на разных этапах загрузки системы. Однако по мере того, как задачи при запуске становились разнообразнее и сложнее, "квазимодульный" подход стал ещё большей обузой, чем монолитный /etc/rc.

Без чистого и хорошо продуманного каркаса, стартовые скрипты вынуждены были идти на всевозможные ухищрения, чтобы удовлетворить потребности быстро развивающихся BSD-ориентированных операционных систем. В конце концов стало очевидно, что необходимы дополнительные шаги на пути к детализированной и расширяемой системе rc. Так появилась BSD rc.d. Её признанными создателями стали Люк Мьюберн и сообщество NetBSD. Позже она была импортирована в FreeBSD. Её название отсылает к расположению системных скриптов для отдельных служб, которое находится в /etc/rc.d. Вскоре мы узнаем больше о компонентах системы rc.d и увидим, как вызываются отдельные скрипты.

Основные идеи, лежащие в основе BSD rc.d, — это тонкая модульность и повторное использование кода. Тонкая модульность означает, что каждая базовая «служба», такая как системный демон или примитивная задача запуска, получает собственный сценарий sh(1), способный запустить службу, остановить её, перезагрузить или проверить её состояние. Конкретное действие выбирается аргументом командной строки, переданным в сценарий. Сценарий /etc/rc по-прежнему управляет запуском системы, но теперь он просто вызывает небольшие сценарии один за другим с аргументом start. Также легко выполнять задачи завершения работы, запуская тот же набор сценариев с аргументом stop, что и делает /etc/rc.shutdown. Обратите внимание, насколько это близко следует Unix-подходу, где используется набор небольших специализированных инструментов, каждый из которых выполняет свою задачу наилучшим образом. Повторное использование кода означает, что общие операции реализованы как функции sh(1) и собраны в /etc/rc.subr. Теперь типичный сценарий может состоять всего из нескольких строк кода sh(1). Наконец, важной частью инфраструктуры rc.d является rcorder(8), который помогает /etc/rc упорядоченно запускать небольшие сценарии с учётом зависимостей между ними. Он также может помочь /etc/rc.shutdown, поскольку правильный порядок завершения работы противоположен порядку запуска.

Дизайн BSD rc.d описан в оригинальной статье Люка Мьюберна, а компоненты rc.d подробно документированы в соответствующих руководствах. Однако новичку в rc.d может быть неочевидно, как связать многочисленные элементы вместе, чтобы создать хорошо структурированный скрипт для конкретной задачи. Поэтому в этой статье будет предпринята попытка описать rc.d с другого ракурса. В ней будет показано, какие функции следует использовать в ряде типичных случаев и почему. Обратите внимание, что это не руководство, поскольку наша цель — не предоставление готовых рецептов, а демонстрация нескольких простых способов входа в мир rc.d. Также эта статья не заменяет соответствующие руководства. Не стесняйтесь обращаться к ним для получения более формальной и полной документации во время чтения этой статьи.

Для понимания этой статьи есть предварительные требования. Прежде всего, вы должны быть знакомы с языком написания сценариев sh(1), чтобы освоить rc.d. Кроме того, вы должны знать, как система выполняет задачи запуска и завершения работы пользовательского пространства, что описано в rc(8).

Эта статья посвящена ветке FreeBSD в rc.d. Тем не менее, она может быть полезна и разработчикам NetBSD, потому что две ветки BSD rc.d не только разделяют одинаковый дизайн, но и остаются схожими в аспектах, видимых авторам скриптов.

Немного размышлений перед запуском $EDITOR не повредит. Чтобы написать хорошо продуманный скрипт rc.d для системной службы, сначала нужно ответить на следующие вопросы:

Из следующих примеров мы увидим, почему важно знать ответы на эти вопросы.

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

Вот что следует учитывать:

➊ Интерпретируемый скрипт должен начинаться с "волшебной" строки shebang. Эта строка указывает программу-интерпретатор для скрипта. Благодаря строке shebang скрипт может быть запущен точно так же, как бинарная программа, при условии что у него установлен бит выполнения. (См. chmod(1).) Например, системный администратор может запустить наш скрипт вручную из командной строки:

➋ В файле /etc/rc.subr определено несколько функций sh(1), которые могут использоваться скриптами rc.d. Эти функции описаны в rc.subr(8). Хотя теоретически возможно написать скрипт rc.d без использования rc.subr(8), его функции оказываются чрезвычайно полезными и значительно упрощают задачу. Поэтому неудивительно, что все используют rc.subr(8) в скриптах rc.d. Мы не будем исключением.

Файл rc.d должен "подгрузить" (/etc/rc.subr, включить его с помощью “.”) до вызова функций rc.subr(8), чтобы у sh(1) была возможность знать об этих функциях заранее. Предпочтительный стиль — подгружать /etc/rc.subr в самом начале.

➌ Обязательная переменная name определяет имя нашего скрипта. Она требуется rc.subr(8). То есть, каждый скрипт в rc.d должен установить name перед вызовом функций rc.subr(8).

Теперь самое время раз и навсегда выбрать уникальное имя для нашего скрипта. Мы будем использовать его в нескольких местах при разработке скрипта. Содержимое переменной name должно соответствовать имени скрипта, так как некоторые части FreeBSD (например, сервисные клетки (jail) и функция cpuset в rc framework) зависят от этого. Таким образом, имя файла также не должно содержать символов, которые могут вызвать проблемы в скриптах (например, не используйте дефис "-" и другие).

➍ Основная идея rc.subr(8) заключается в том, что скрипт rc.d предоставляет обработчики (или методы) для вызова rc.subr(8). В частности, аргументы start, stop и другие, передаваемые в скрипт rc.d, обрабатываются таким образом. Метод представляет собой выражение sh(1), сохранённое в переменной с именем argument_cmd, где argument соответствует тому, что может быть указано в командной строке скрипта. Далее мы увидим, как rc.subr(8) предоставляет стандартные методы для типовых аргументов.

➎ Следует помнить, что rc.subr(8) предоставляет методы по умолчанию для стандартных аргументов. Следовательно, если мы хотим, чтобы стандартный метод ничего не делал, мы должны переопределить его с помощью no-op sh(1) выражения.

➏ Тело сложного метода может быть реализовано в виде функции. Хорошей практикой является использование осмысленного имени функции.

➐ Этот вызов rc.subr(8) загружает переменные rc.conf(5). Наш скрипт пока их не использует, но всё равно рекомендуется загружать rc.conf(5), потому что могут быть переменные rc.conf(5), управляющие самим rc.subr(8).

➑ Обычно это последняя команда в скрипте rc.d. Она вызывает механизм rc.subr(8) для выполнения запрошенного действия, используя переменные и методы, предоставленные нашим скриптом.

Теперь добавим некоторые элементы управления в наш тестовый скрипт. Как вам может быть известно, скрипты rc.d управляются с помощью rc.conf(5). К счастью, rc.subr(8) скрывает от нас все сложности. Следующий скрипт использует rc.conf(5) через rc.subr(8), чтобы проверить, включен ли он вообще, и получить сообщение для отображения во время загрузки. Эти две задачи на самом деле независимы. С одной стороны, скрипт rc.d может просто поддерживать включение и выключение своего сервиса. С другой стороны, обязательный скрипт rc.d может иметь переменные конфигурации. Однако мы реализуем обе возможности в одном скрипте:

Что изменилось в этом примере?

➊ Переменная rcvar определяет имя переменной-переключателя ON/OFF.

➋ Теперь load_rc_config вызывается раньше в скрипте, до обращения к любым переменным rc.conf(5).

➌ run_rc_command выдаст предупреждение, если переменная rcvar установлена, но указанная переменная-флаг не задана. Если ваш скрипт rc.d предназначен для базовой системы, вы должны добавить значение по умолчанию для флага в /etc/defaults/rc.conf и задокументировать его в rc.conf(5). В противном случае ваш скрипт должен предоставить значение по умолчанию для флага. Канонический подход для последнего случая показан в примере.

➍ Теперь сообщение, отображаемое при загрузке, больше не жестко закодировано в скрипте. Оно задается переменной dummy_msg в rc.conf(5). Это простой пример того, как переменные rc.conf(5) могут управлять скриптом в rc.d.

➎ Здесь мы используем dummy_msg для фактического управления нашим скриптом, т.е., для выдачи переменного сообщения. Использование shell-функции здесь избыточно, так как она выполняет только одну команду; равнозначной альтернативой является:

Мы ранее говорили, что rc.subr(8) может предоставлять методы по умолчанию. Очевидно, что такие методы не могут быть слишком общими. Они подходят для стандартного случая запуска и остановки простого демона. Предположим, что нам нужно написать скрипт rc.d для такого демона с именем mumbled. Вот он:

Приятно просто, не так ли? Давайте рассмотрим наш небольшой скрипт. Единственное новое, на что стоит обратить внимание, это следующее:

➊ Переменная command имеет значение для rc.subr(8). Если она установлена, rc.subr(8) будет действовать по сценарию обслуживания обычного демона. В частности, будут предоставлены стандартные методы для таких аргументов: start, stop, restart, poll и status.

Демон будет запущен выполнением $command с флагами командной строки, указанными в $mumbled_flags. Таким образом, все входные данные для метода start по умолчанию доступны в переменных, установленных нашим скриптом. В отличие от start, другие методы могут требовать дополнительной информации о запущенном процессе. Например, stop должен знать PID процесса, чтобы завершить его. В данном случае, rc.subr(8) будет просматривать список всех процессов, ища процесс с именем, равным procname. Последний является ещё одной значимой переменной для rc.subr(8), и её значение по умолчанию совпадает со значением command. Другими словами, когда мы устанавливаем command, procname фактически устанавливается в то же значение. Это позволяет нашему скрипту завершить демон и проверить, запущен ли он вообще.

Для получения более подробной информации о стандартных методах обратитесь к rc.subr(8).

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

➊ Дополнительные аргументы для $command могут быть переданы в command_args. Они будут добавлены в командную строку после $mumbled_flags. Поскольку итоговая командная строка передаётся в eval для фактического выполнения, перенаправления ввода и вывода могут быть указаны в command_args.

➋ Вежливый демон должен создавать pidfile, чтобы его процесс можно было найти проще и надежнее. Переменная pidfile, если она установлена, указывает rc.subr(8), где можно найти pidfile для использования его стандартными методами.

➌ Если демон не может работать без определённых файлов, просто укажите их в required_files, и rc.subr(8) проверит их наличие перед запуском демона. Также существуют required_dirs и required_vars для каталогов и переменных окружения соответственно. Все они подробно описаны в rc.subr(8).

➍ Мы можем настроить сигналы, отправляемые демону, если они отличаются от общеизвестных. В частности, sig_reload указывает сигнал, который заставляет демона перезагрузить свою конфигурацию; по умолчанию это SIGHUP. Другой сигнал отправляется для остановки процесса демона; по умолчанию используется SIGTERM, но это можно изменить, установив sig_stop соответствующим образом.

➎➏ Выполнение дополнительных задач до или после стандартных методов — это просто. Для каждого аргумента команды, поддерживаемого нашим скриптом, мы можем определить argument_precmd и argument_postcmd. Эти команды sh(1) вызываются до и после соответствующего метода, что очевидно из их названий.

➐ Если мы хотим реализовать пользовательские аргументы, которые также можно рассматривать как команды для нашего скрипта, необходимо перечислить их в extra_commands и предоставить методы для их обработки.

➑⓮ Наш скрипт поддерживает две нестандартные команды: plugh и xyzzy. Мы видели их в списке extra_commands, и теперь пришло время реализовать методы для них. Метод для xyzzy просто встроен в код, а для plugh он реализован как функция mumbled_plugh.

Нестандартные команды не вызываются во время запуска или завершения работы. Обычно они предназначены для удобства системного администратора. Они также могут использоваться другими подсистемами, например, devd(8), если указаны в devd.conf(5).

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

⓭ Скрипт может вызывать свои собственные стандартные или нестандартные команды, если это необходимо. Это может выглядеть похоже на вызов функций, но мы знаем, что команды и функции оболочки не всегда одно и то же. Например, xyzzy не реализован как функция в данном случае. Кроме того, могут существовать пред-команда и пост-команда, которые должны вызываться в определённом порядке. Поэтому правильный способ для скрипта выполнить свою собственную команду — с помощью rc.subr(8), как показано в примере.

➒ Полезная функция checkyesno предоставляется rc.subr(8). Она принимает имя переменной в качестве аргумента и возвращает нулевой код выхода только если переменная установлена в YES, TRUE, ON или 1, без учёта регистра; в противном случае возвращается ненулевой код выхода. В последнем случае функция проверяет, установлена ли переменная в NO, FALSE, OFF или 0, также без учёта регистра; если переменная содержит что-то иное (т.е. мусор), функция выводит предупреждение.

Имейте в виду, что для sh(1) нулевой код возврата означает истину, а ненулевой код возврата означает ложь.

➓ Мы можем влиять на флаги, передаваемые команде $command, изменяя rc_flags в $start_precmd.

⓫ В некоторых случаях может потребоваться вывести важное сообщение, которое также должно попасть в syslog. Это можно легко сделать с помощью следующих функций rc.subr(8): debug, info, warn и err. Последняя функция завершает выполнение скрипта с указанным кодом.

⓬ Коды выхода из методов и их предварительных команд не просто игнорируются по умолчанию. Если argument_precmd возвращает ненулевой код выхода, основной метод не будет выполнен. В свою очередь, argument_postcmd не будет вызван, если основной метод возвращает ненулевой код выхода.

После написания скрипта его необходимо интегрировать в rc.d. Ключевой шаг — установка скрипта в /etc/rc.d (для базовой системы) или /usr/local/etc/rc.d (для портов). И bsd.prog.mk, и bsd.port.mk предоставляют удобные механизмы для этого, и обычно вам не нужно беспокоиться о правильных правах доступа и режиме. Системные скрипты должны устанавливаться из src/libexec/rc/rc.d через Makefile, находящийся там. Скрипты портов можно установить с помощью USE_RC_SUBR, как описано в Руководстве FreeBSD по созданию портов.

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

Мы уже упоминали rcorder(8). Теперь пришло время рассмотреть его подробнее. В двух словах, rcorder(8) принимает набор файлов, анализирует их содержимое и выводит на stdout список этих файлов, упорядоченный по зависимостям. Главная идея заключается в том, чтобы хранить информацию о зависимостях внутри файлов, чтобы каждый файл мог описывать только себя. Файл может содержать следующую информацию:

Неудивительно, что rcorder(8) может обрабатывать только текстовые файлы с синтаксисом, близким к sh(1). То есть специальные строки, понимаемые rcorder(8), выглядят как комментарии в sh(1). Синтаксис таких специальных строк довольно жёсткий, чтобы упростить их обработку. Подробности см. в rcorder(8).

Помимо использования специальных строк rcorder(8), скрипт может настаивать на своей зависимости от другой службы, просто принудительно запуская её. Это может быть необходимо, когда другая служба является опциональной и не запускается самостоятельно, потому что системный администратор ошибочно отключил её в rc.conf(5).

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

Как и ранее, следует детальный анализ:

➊ Эта строка объявляет названия "условий", которые предоставляет наш скрипт. Теперь другие скрипты могут указывать зависимость от нашего скрипта по этим именам.

➋➌ Таким образом, наш скрипт указывает, от каких "условий", предоставляемых другими скриптами, он зависит. Согласно строкам, наш скрипт просит rcorder(8) разместить его после скрипта(ов), предоставляющих DAEMON и cleanvar, но перед тем, который предоставляет LOGIN.

➍ Как мы помним из текста выше, ключевые слова rcorder(8) могут использоваться для выбора или исключения некоторых скриптов. А именно, любой потребитель rcorder(8) может указать с помощью опций -k и -s, какие ключевые слова находятся в "списке сохранения" и "списке пропуска" соответственно. Из всех файлов, подлежащих сортировке по зависимостям, rcorder(8) выберет только те, которые имеют ключевое слово из списка сохранения (если он не пуст) и не имеют ключевого слова из списка пропуска.

В FreeBSD, rcorder(8) используется /etc/rc и /etc/rc.shutdown. Эти два скрипта определяют стандартный список ключевых слов rc.d FreeBSD и их значения следующим образом:

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

Если вам всё ещё не обойтись без force_depend, в примере показано, как вызвать его условно. В примере наш демон mumbled требует, чтобы другой демон, frotz, был запущен заранее. Однако frotz также является опциональным, и rcorder(8) ничего не знает о таких деталях. К счастью, наш скрипт имеет доступ ко всем переменным rc.conf(5). Если frotz_enable имеет значение true, мы надеемся на лучшее и полагаемся на rc.d, что frotz был запущен. В противном случае мы принудительно проверяем статус frotz. Наконец, мы принудительно устанавливаем зависимость от frotz, если обнаруживаем, что он не запущен. force_depend выдаст предупреждение, так как его следует вызывать только в случае обнаружения неправильной конфигурации.

При вызове во время запуска или завершения работы скрипт rc.d должен воздействовать на всю подсистему, за которую он отвечает. Например, /etc/rc.d/netif должен запускать или останавливать все сетевые интерфейсы, описанные в rc.conf(5). Любая из этих задач может быть однозначно указана единственным аргументом команды, таким как start или stop. Между запуском и завершением работы скрипты rc.d помогают администратору управлять работающей системой, и именно тогда возникает потребность в большей гибкости и точности. Например, администратор может добавить настройки нового сетевого интерфейса в rc.conf(5), а затем запустить его, не затрагивая работу существующих интерфейсов. В следующий раз администратору может потребоваться остановить отдельный сетевой интерфейс. В духе командной строки, соответствующий скрипт rc.d требует дополнительного аргумента — имени интерфейса.

К счастью, rc.subr(8) позволяет передавать любое количество аргументов (в пределах системных ограничений) методам скрипта. Благодаря этому изменения в самом скрипте могут быть минимальными.

Как rc.subr(8) может получить доступ к дополнительным аргументам командной строки. Должен ли он просто захватывать их напрямую? Ни в коем случае. Во-первых, функция sh(1) не имеет доступа к позиционным параметрам своего вызывающего объекта, но rc.subr(8) — это просто набор таких функций. Во-вторых, хороший стиль rc.d предписывает, что именно главный скрипт должен решать, какие аргументы передавать его методам.

Итак, подход, принятый в rc.subr(8), следующий: run_rc_command передаёт все свои аргументы, кроме первого, в соответствующий метод в неизменном виде. Первый, опущенный аргумент — это имя самого метода: start, stop и т.д. Он будет удалён с помощью shift в run_rc_command, так что то, что было $2 в оригинальной командной строке, будет представлено как $1 в методе, и так далее.

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

Какие основные изменения мы можем заметить в скрипте?

➊ Все аргументы, которые вы вводите после start, могут стать позиционными параметрами для соответствующего метода. Мы можем использовать их любым способом в соответствии с нашей задачей, навыками и предпочтениями. В текущем примере мы просто передаем все их в echo(1) как одну строку в следующей строке — обратите внимание на $* в двойных кавычках. Вот как теперь можно вызывать этот скрипт:

➋ То же самое относится к любому методу, который предоставляет наш скрипт, не только к стандартному. Мы добавили пользовательский метод с именем kiss, и он может использовать дополнительные аргументы не меньше, чем start. Например:

➌ Если мы хотим просто передать все дополнительные аргументы любому методу, мы можем просто заменить "$@" на "$1" в последней строке нашего скрипта, где мы вызываем run_rc_command.

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

Некоторые примеры скриптов, которые не подходят для запуска в сервисной клетке:

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

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

По умолчанию только части start и stop скрипта выполняются внутри сервисной клетки, остальное выполняется вне клетки. Таким образом, любые настройки, используемые в частях start/stop скрипта, не могут быть заданы, например, из precommand.

Чтобы сделать скрипт готовым к использованию с Сервисными Клетками, необходимо добавить всего одну строку конфигурации:

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

Строго говоря, пустая конфигурация не обязательна, но она явно указывает, что скрипт готов к работе с сервисными клетками и не требует дополнительных разрешений для клеток. Поэтому настоятельно рекомендуется добавить такую пустую конфигурацию в таком случае. Наиболее распространённая опция — "net_basic", которая позволяет использовать IPv4 и IPv6 адреса хоста. Все возможные опции описаны в rc.conf(5).

Если настройка запуска/остановки зависит от переменных из rc-фреймворка (например, заданных в rc.conf(5)), это должно обрабатываться с помощью load_rc_config и run_rc_command, а не внутри precommand.

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

➊ Отключение должно происходить после вызова load_rc_config, иначе параметр из rc.conf(5) может переопределить его.

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

Вот пример rc-скрипта, который поддерживает это:

➊ и ➋ убедитесь, что переменная name установлена в значение basename(1) имени скрипта. Если имя файла — /usr/local/etc/rc.d/dummy, то name будет установлено в dummy. Таким образом, изменение имени rc-скрипта автоматически изменит содержимое переменной name.

➌ указывает имя переменной, которая используется в rc.conf для включения этой службы на основе имени файла этого скрипта. В данном примере это преобразуется в dummy_enable.

➍ убеждается, что значение по умолчанию для переменной _enable установлено в NO.

➎ Вот пример установки некоторых значений по умолчанию для переменных фреймворка, специфичных для службы, в данном случае — опций клетки службы.

➏ и ➐ устанавливают переменные, внутренние для скрипта (обратите внимание на подчёркивание в начале _dummy_user, чтобы отличать её от dummy_user, которая может быть задана в rc.conf).

Часть в ➎ предназначена для переменных, которые не используются внутри самого скрипта, но используются в рамках rc. Все переменные, которые используются как параметры в скрипте, присваиваются общей переменной, как в ➐, чтобы упростить их использование (нет необходимости выполнять eval при каждом обращении).

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

Вышеприведенное создает экземпляр службы dummy с именем dummy_foo. Он использует не файл конфигурации /usr/local/etc/dummy.cfg, а файл конфигурации /usr/local/etc/dummy_foo.cfg (➐), и использует PID-файл /var/run/dummy/dummy_foo.pid вместо /var/run/dummy/dummy.pid.

Сервисы dummy и dummy_foo могут управляться независимо друг от друга, при этом скрипт запуска обновляется автоматически при обновлении пакета (благодаря символьной ссылке). Это не обновляет строку REQUIRE, поэтому нет простого способа зависеть от конкретного экземпляра. Чтобы зависеть от конкретного экземпляра в порядке запуска, необходимо создать копию вместо использования символьной ссылки. Это предотвращает автоматическое применение изменений в скрипте запуска при установке обновления.

Оригинальная статья Люка Мьюберна предлагает общий обзор rc.d и подробное обоснование принятых при его проектировании решений. В ней представлено понимание всего фреймворка rc.d и его места в современной BSD-системе.

Руководства rc(8), rc.subr(8) и rcorder(8) подробно описывают компоненты rc.d. Без изучения этих руководств и обращения к ним при написании собственных скриптов невозможно в полной мере использовать возможности rc.d.

Основным источником рабочих, жизненных примеров является /etc/rc.d в работающей системе. Его содержимое легко и приятно читать, поскольку большинство сложных моментов скрыто глубоко в rc.subr(8). Однако помните, что скрипты в /etc/rc.d были написаны не ангелами, поэтому они могут содержать ошибки и неоптимальные решения. Теперь вы можете их улучшить!