4.B. Работаем с rc-update

Что такое rc-update?

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

С помощью rc-update вы можете добавлять и удалять инициализационные скрипты к уровню доступа. Программа rc-update затем автоматически попросит depscan.sh перестроить дерево зависимостей.

Добавляем и удаляем сервисы

Вы уже добавляли инициализационные скрипты к уровню запуска «default» в течение установки Gentoo. В то время вы, наверное, не знали, что означает «default», но теперь вы знаете. Скрипт rc-update требует второй аргумент, который определяет действие — add, del или show.

Чтобы добавить или удалить инициализационный скрипт, просто дайте rc-update аргумент add или del, за которым идет имя инициализационного скрипта и уровень запуска. Например:

Код 2.1: Удаляем Postfix с уровня запуска Default

# rc-update del postfix default

Команда rc-update -v show покажет все существующие инициализационные скрипты, и список, на каких уровнях запуска они будут выполнены:

Код 2.2: Получаем информацию об инициализационных скриптах

# rc-update -v show

Вы также можете запустить rc-update show (без -v) чтобы просто просмотреть включенные инициализационные скрипты и их уровни запуска.

4.C. Конфигурирование сервисов

Зачем нужна дополнительная конфигурация?

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

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

Каталог /etc/conf.d

Gentoo дает легкий способ для конфигурации сервиса: каждый инициализационный скрипт, который может быть сконфигурирован, имеет файл в /etc/conf.d. Например, инициализационный скрипт apache2 (называемый /etc/init.d/apache2) имеет конфигурационный файл, называемый /etc/conf.d/apache2, который может содержать опции, которые вы хотите передать серверу Apache2 при запуске:

Код 3.1: Переменная, определенная в /etc/conf.d/apache2

APACHE2_OPTS="-D PHP5"

Такой конфигурационный файл содержит только переменные (почти как /etc/make.conf), что делает очень простым занятием конфигурирование сервисов. Он также позволяет дать больше информации о переменных (как комментарии).

4.D. Пишем инициализационные скрипты

А мне нужно?

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

Не используйте инициализационный скрипт, который идет с сервисом, если он не написан специально для Gentoo: инициализационные скрипты Gentoo не совместимы с инициализационными скриптами, используемыми другими дистрибутивами!

Структура

Базовая структура инициализационного скрипта показана ниже:\

Код 4.1: Базовая структура инициализационного скрипта

#!/sbin/runscript depend() { (Информация о зависимостях) } start() { (Команды, необходимые для запуска сервиса) } stop() { (Команды, необходимые для остановки сервиса) }

Любой инициализационный скрипт требует определения функции start(). Все остальные секции являются опциональными.

Зависимости

Существует две настройки, работающие с зависимостями, которые вы можете определить, и они будут влиять на порядок запуска инициализационных скриптов: use и need. Кроме этих двух, существует также еще два влияющих на порядок загрузки метода, называющиеся before и after. Последние два, в общем, определяют даже и не зависимости, они не заставят выдать ошибку скрипт, если тот скрипт, что в них описан вообще не должен запуститься (или не запустится).

• Настройка use информирует систему init, что данный скрипт использует функциональность некоторого скрипта, но не строго от него зависит. Хорошим примером будет use logger или use dns. Если эти сервисы есть, они будут хорошо использоваться, но если у вас нет логгера, или DNS-сервера, сервисы все равно будут работать. Если сервисы существуют, они будут запущены до того, как запустится скрипт, использующий их.

• Настройка need это жесткая зависимость. Она означает, что скрипт, которому нужен другой скрипт, не запустится, пока другой скрипт не запустится успешно. Также, если другой скрипт будет перезапущен, то этот тоже будет перезапущен.

• При использовании before, данный скрипт запускается до некоторого скрипта, если выбранный скрипт это часть того же уровня. Так, инициализационный скрипт xdm, который определен до alsasound будет запущен до скрипта alsasound, но только если alsasound запланирован запуститься на том же уровне. Если alsasound не запланирована запуститься, то эта конкретная настройка не будет иметь эффекта, и xdm запустится в тот момент времени, который система init посчитает лучшим вариантом.

• Похожим образом, after информирует систему init, что данный скрипт нужно запустить после некоторого скрипта, если выбранный скрипт является частью того же уровня. Если нет, то настройка не имеет эффпекта, и скрипт будет запущен системой init в момент времени, который, как она посчитает, будет наилучшим.

Из вышенаписанного должно быть ясно, что need это единственная «действительная» настройка о зависимостях, так как она влияет на то, будет ли запущен скрипт или нет. Все остальные являются больше указателями системе init, говорящими в каком порядке скрипты могут (или должны) запускаться.

Теперь, если вы посмотрите на многие из существующих инициализационных скриптов Gentoo, вы заметите, что некоторые из них имеют зависимости от вещей, которые не являются инициализационными скриптами. Эти «вещи» мы называем виртуалами.

Виртуальная зависимость это зависимость, которую дает сервис, но она не дается только этим сервисом. Ваш инициализационный скрипт может зависеть от системного логгера, но существует много системных логгеров (metalogd, syslog-ng, sysklogd, …). Так как вы не можете хотеть какой-то один из них (ни одна система не имеет все эти логгеры установленными и запущенными), мы удостоверились, что все эти сервисы дают виртуальную зависимость.

Давайте посмотрим на информацию о зависиости для сервиса postfix:

Код 4.2: Информация о зависимостях для Postfix

depend() { need net use logger dns provide mta }

Как вы можете видеть, сервис postfix:

• Требует (виртуальную) зависимость net (которую дает, например, /etc/init.d/net.eth0)

• Использует (виртуальную) зависимость logger (которую дает, например, /etc/init.d/syslog-ng)

• Использует (виртуальную) зависимость dns (которую дает, например, /etc/init.d/named)

• Дает (виртуальную) зависимость mta (которая является общей для всех почтовых серверов)

Контроль порядка загрузки

Как мы описали в предыдущем разделе, вы можете сказать системе init, в каком порядке она должна запускать (или останавливать) скрипты. Этот порядок поддерживается как через настройки зависимостей use и need, так и через настройки порядка before и after. Так как мы описали их ранее, давайте посмотрим на сервис Portmap как на пример такого инициализационного скрипта.

Код 4.3: Функция depend() в сервисе Portmap

depend() { need net before inetd before xinetd }

Вы также можете использовать «*». Это будет означать все сервисы на том же уровне запуска, хотя это и не рекомендуется.

Код 4.4: Запускаем инициализационный скрипт как первый скрипт на уровне запуска

depend() { before * }

Если ваш сервис должен писать на локальные диски, он должен потребовать localmount. Если он что-либо поместит в /var/run, например пид-файл, тогда он должен запускаться после bootmisc:

Код 4.5: Пример функции depend()

depend() { need localmount after bootmisc }

Стандартные функции

Кроме функции depend() вам нужно также определить функцию start(). Она будет содержать все команды, необходимые для инициализации вашего сервиса. Рекомендуется использовать функции ebegin и eend, чтобы проинформировать пользователя о том, что происходит.

Код 4.6: Пример функции start()

start() { if [ "${RC_CMD}" = "restart" ]; then # Do something in case a restart requires more than stop, start fi ebegin "Starting my_service" start-stop-daemon --start --exec /path/to/my_service \ --pidfile /path/to/my_pidfile eend $? }

Как --exec, так и --pidfile должны использоваться в функциях start и stop. Если сервис не создает пид-файл, тогда используйте --make-pidfile, если возможно, хотя вы должны протестировать это, чтобы быть уверенным. Иначе, не используйте пид-файлы. Вы также можете добавить --quiet к опциям start-stop-daemon, но это не рекомендуется, если только сервис не очень многословный. Использование --quiet может скрыть информацию если сервис не сможет запуститься.

Другой интересной настройкой, используемой в вышеприведенном примере является проверка содержимого переменной RC_CMD. В отличие от предыдущей инициализационной системы, новая система openrc не поддерживает отдельную функциональность restart для каждого скрипта. Вместо этого, скрипт должен проверить содержимое переменной RC_CMD, чтобы проверить, вызывается ли функция (как start(), так и stop()) как часть restart, или нет.

Заметка: Удостоверьтесь, что --exec действительно вызывает сервис, а не шелл-скрипт, который запускает сервисы и выходит — это должен делать сам инициализационный скрипт.

Если вам нужно больше примеров функции start(), пожалуйста, прочитайте исходный код существующих инициализационных скриптов в вашей директории /etc/init.d.

Другой функцией, которую вы можете определить, является stop(). Вы не обязаны определять эту функцию! Наша система инициализации достаточно умна, чтобы заполнить эту функцию сама, если вы использовали start-stop-daemon.

Вот пример функции stop():

Код 4.7: Пример функции stop()

stop() { ebegin "Stopping my_service" start-stop-daemon --stop --exec /path/to/my_service \ --pidfile /path/to/my_pidfile eend $? }

Если ваш сервис запускает некоторый другой скрипт (например, на bash, python или perl), и этот скрипт позднее изменяет имя (например, с foo.py на foo), тогда вам нужно добавить --name к start-stop-daemon. Вы должны определить имя, на которое имя файла изменится. В приведенном примере, сервис запускает foo.py, а потом это имя меняется на foo:

Код 4.8: Сервис, который запускает скрипт foo

start() { ebegin "Starting my_script" start-stop-daemon --start --exec /path/to/my_script \ --pidfile /path/to/my_pidfile --name foo eend $? }

start-stop-daemon имеет отличную man-страницу, которую вы можете посмотреть, если вам нужна дополнительная информация.

Код 4.9: Получаем man-страницу для start-stop-daemon

$ man start-stop-daemon

Синтаксис инициализационных скриптов Gentoo основан на Bourne Again Shell (bash), так что вы вольны использовать bash-совместимые конструкции в вашем инициализационном скрипте. Однако вы можете захотеть написать ваши инициализационные скрипты, чтобы они были POSIX-совместимыми. Будущие системы инициализационных скриптов могут позволить изменить символическую ссылку /bin/sh, чтобы она указывала на другие шеллы, кроме bash. Инициализационные скрипты, которые основаны на возможностях только bash на таких конфигурациях могут отказаться работать.

Добавляем дополнительные опции

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

Код 4.10: Поддержка опции restartdelay

extra_commands="restartdelay" restartdelay() { stop sleep 3 # Wait 3 seconds before starting again start }

Важно: Функция restart() не может быть переназначена в openrc!

Переменные конфигурирования сервиса

Вам не нужно ничего делать, чтобы появилась поддержка файла конфигурации в /etc/conf.d: если ваш инициализационный скрипт выполняется, следующие файлы автоматически подключаются (то есть, переменные становятся возможными для использования):

• /etc/conf.d/<ваш_инициализационный_скрипт>

• /etc/conf.d/basic

• /etc/rc.conf

Кроме того, если ваш инициализационный скрипт имеет виртуальную зависимость (такую как net), то файл, ассоциированный с этой зависимостью (такой, как /etc/conf.d/net) тоже можно будет использовать.