Основы написания rc.d скриптов в BSD

1 Вступление

Когда-то BSD имела монолитный скрипт запуска /etc/rc. Его вызывал init(8) во время загрузки системы, и этот скрипт выполнял все задачи в пространстве пользователя (userspace), необходимые для многопользовательских операций: проверку и монтирование файловых систем, настройку сети, запуск демонов и тому подобное. Но список таких задач не одинаков в разных системах, администраторам необходима более тонкая настройка. За исключением отдельных моментов, /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. Ее признанными родителями стали Люк Мьюберн (Luke Mewburn) и сообщество 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. Обратите внимание, что этот документ не является пошаговым описанием (''HOWTO''), поскольку мы не ставим задачу дать готовые рецепты на все случаи жизни. Нашей задачей является дать вам точку входа для самостоятельного творчества в системе запуска rc.d. Так же, эта статья не в коей мере не является заменой страницам справочника. Не ленитесь заглядывать в них для более точной и полной информации во время чтения этой статьи.

Есть несколько требований для полного понимания изложенного материала. Во первых, вы должны быть знакомы с программированием на скриптовом языке sh(1). Во вторых, вы должны понимать как система осуществляет стартовые и завершающие действия пространства пользователя, которые описаны в rc(8).

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

2 Обозначение задачи

Маленькое замечание перед началом. Не бойтесь переменной окружения $EDITOR.

Для того, чтобы писать качественные rc.d скрипты для системных сервисов нам нужно ответить на следующие вопросы:

• Этот сервис обязательный или нет?

• Будет скрипт обслуживать только одну программу (т.е. демон) или будет выполнять более комплексные задачи?

• От каких сервисов будет зависеть этот сервис и какие будут зависеть от него?

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

3 Простейший скрипт

Этот скрипт просто выдает сообщение при каждом старте системы:

#!/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"

Здесь:

4 Настраиваемый простейший скрипт

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

#!/bin/sh

. /etc/rc.subr

name="dummy"
rcvar=`set_rcvar`
start_cmd="${name}_start"
stop_cmd=":"

load_rc_config $name
eval "${rcvar}=\${${rcvar}:-'NO'}"
dummy_msg=${dummy_msg:-"Nothing started."}

dummy_start()
{
    echo "$dummy_msg"
}

run_rc_command "$1"

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

5 Запуск и остановка простого демона

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

#!/bin/sh

. /etc/rc.subr

name="mumbled"
rcvar=`set_rcvar`
command="/usr/sbin/${name}"

load_rc_config $name
run_rc_command "$1"

Необычайно просто, не так ли? Давайте посмотрим на него немного внимательнее. Отметить нужно следующее:

6 Запуск более сложного демона

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

#!/bin/sh

. /etc/rc.subr

name="mumbled"
rcvar=`set_rcvar`

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"

7 Присоединение rc.d скрипта к инфраструктуре

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

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

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

• названия ''условий'' (в нашем случае - сервисов), которые наш скрипт предоставляет;

• названия ''условий'', которые необходимы скрипту для запуска;

• названия ''условий'', которые должны быть выполнены до запуска нашего сервиса;

• дополнительные ключевые слова (keywords), чтобы выделить группу файлов из всего набора. (можно дать команду rcorder(8) игнорировать или использовать только те файлы, в которых есть определенное ключевое слово.)

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

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

Обладая этими знаниями, давайте улучшим наш скрипт для запуска простого демона, добавив в него зависимости:

#!/bin/sh

# PROVIDE: mumbled oldmumble 
# REQUIRE: DAEMON cleanvar frotz
# BEFORE:  LOGIN
# KEYWORD: nojail shutdown

. /etc/rc.subr

name="mumbled"
rcvar=`set_rcvar`
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"

А теперь, как и прежде, проведем детальный анализ изменений:

8 Создание более гибких rc.d скриптов

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

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

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

В rc.subr(8) используется следующее решение: функции run_rc_command передаются все аргументы командной строки, при этом подразумевается, что первым из этих аргументов является имя запускаемого метода - start, stop и т.д. Эти аргументы сдвигаются внутри функции run_rc_command c помощью оператора sh(1) shift. Таким образом, переменная $2 в изначальной командной строке передается методу как $1, и так далее.

So the approach adopted by rc.subr(8) is as follows:

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

#!/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 "$@"

Какие значимые изменения были сделаны в этом файле?