OpenRC

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page OpenRC and the translation is 91% complete.
Outdated translations are marked like this.
Other languages:
Resources
Article status
This article has some todo items:
  • Рассмотреть и проверить на аккуратность.
  • Осветить большинство базового функционала на Gentoo.
  • Переработать для точности, читабельности, выразительности...
  • Раздел Интеграция с BusyBox требует тестирования и документирования (или удаления).

OpenRC — это система инициализации на основе зависимостей для Unix-подобных систем, которая совместима с системной программой для инициализации, обычно расположенной в /sbin/init. OpenRC является родной системой инициализации для Gentoo, хотя доступны и другие системы инициализации.

Система OpenRC запускает необходимые системные сервисы в определённом порядке при загрузке, управляет ими во время работы системы и останавливает их при завершении работы. Она может управлять демонами, установленными из Gentoo репозитория, опционально контролируя процессы, которые он запускает, и имеет возможность запускать процессы параллельно (когда это возможно) для сокращения времени загрузки.

OpenRC была разработана для Gentoo, однако она был спроектирована для использования и в других дистрибутивах Linux и системах BSD. По умолчанию, в Gentoo OpenRC вызывается программой sysvinit.

Демонам, установленным не из Gentoo репозитория (например, ПО, которое скачали в виде исходного кода и скомпилировали вручную), иногда может потребоваться адаптация для работы с OpenRC (что обычно проходит довольно легко).

Заметка
Смотрите раздел о документации OpenRC для ссылок на документацию от самого проекта OpenRC. Смотрите Руководство для получения информации о том, как OpenRC взаимодействует с программой для инициализации.

Реализация

OpenRC не требует больших или фундаментальных изменений для традиционных Unix-подобных систем. OpenRC интегрируется с другим системным программным обеспечением, как компонент модульной и гибкой системы. Он является быстрым, лёгким, настраиваемым и гибким компонентом. OpenRC имеет всего несколько зависимостей от основных компонентов системы.

Будучи современной системой инициализации, OpenRC предоставляет ряд полезных возможностей:

  • Поддержка контрольных групп (cgroups).
  • Управление процессом (process supervision).
  • Запуск с учётом зависимостей, с параллельной загрузкой сервисов.
  • Автоматическое разрешение и упорядочивание зависимостей.
  • Запуск сценариев инициализации аппаратным обеспечением.
  • Возможность выставить значения ulimit и nice для отдельных сервисов, через переменную rc_ulimit.
  • Поддержка комплексных сценариев инициализации, которые запускают множество компонентов.
  • Модульная архитектура, вписывающаяся в существующую систему.
  • OpenRC содержит собственную опциональную программу для инициализации openrc-init, см. статью OpenRC/openrc-init для подробностей.
  • OpenRC содержит собственный опциональный супервизор процессов (process supervisor), см. статью OpenRC/supervise-daemon для подробностей.

Для получения более подробной информации о системах инициализации посетите статью Сравнение систем инициализации.

Установка

Обычно программу OpenRC не требуется устанавливать вручную, так как она предоставляется «профилем с поддержкой OpenRC» во время установки. Она уже присутствует в архиве stage3 и обновляется как часть системы.

USE-флаги

USE flags for sys-apps/openrc OpenRC manages the services, startup and shutdown of a host

audit Enable support for Linux audit subsystem using sys-process/audit
bash enable the use of bash in service scripts (experimental)
debug Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
ncurses Add ncurses support (console display library)
netifrc enable Gentoo's network stack (net.* scripts)
newnet enable the new network stack (experimental)
pam Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip
s6 install s6-linux-init
selinux !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
sysv-utils Install sysvinit compatibility scripts for halt, init, poweroff, reboot and shutdown
sysvinit control the dependency on sysvinit (experimental)
unicode Add support for Unicode
Data provided by the Gentoo Package Database · Last update: 2024-04-01 19:35 More information about USE flags

Если USE-флаги были изменены, может потребоваться пересборка пакета для применения изменений. В профилях с поддержкой OpenRC sys-apps/openrc является зависимостью для virtual/service-manager, поэтому его не рекомендуется добавлять в набор selected-packages (выбранных пакетов) (файл /var/lib/portage/world). Параметр --oneshot option не даст добавить OpenRC в этот набор.

root #emerge --ask --oneshot sys-apps/openrc

Конфигурация

Файлы

/etc/rc.conf
Глобальный файл конфигурации OpenRC.
Содержит подробные комментарии, описывающие настройку OpenRC.
/etc/conf.d
Содержит файлы конфигурации для индивидуальных сценариев инициализации (initscripts).

Журналирование

По умолчанию OpenRC не журналирует ничего. Чтобы сохранить вывод OpenRC во время загрузки в журнал, необходимо раскомментировать и установить опцию rc_logger в /etc/rc.conf. По умолчанию журнал будет находиться в /var/log/rc.log.

ФАЙЛ /etc/rc.conf
rc_logger="YES"
#rc_log_path="/var/log/rc.log"

Управление сетью

OpenRC можно использовать с одним из нескольких менеджеров сети, или даже без него. По умолчанию, в Gentoo профилях OpenRC для управления подключениями к сети используются сценарии netifrc.

См. статью Менеджер сети для перечисления вариантов для управления сетью.

Разрешение зависимостей

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

Несколько сетевых интерфейсов (пример)

В этот примере сервис SSH-сервера должен запускаться вместе с интрасетью, к примеру, с eth0, но не wlan0.

Перезапишите зависимость "net" из /etc/init.d/sshd, и замените её на "net.eth0":

ФАЙЛ /etc/conf.d/sshd
rc_need="!net net.eth0"
Несколько сетевых интерфейсов в нескольких уровнях выполнения (пример)

В этом примере в уровне выполнения "default" сервис SSH-сервера должен запускаться вместе с eth0 (но не wlan0), а в уровне выполнения "office" наоборот (wlan0, но не eth0).

Оставьте значение по умолчанию:

ФАЙЛ /etc/rc.conf
#rc_depend_strict="YES"

Создайте дополнительный символьные ссылки на sshd с названиями сетевых интерфейсов:

root #ln -s sshd /etc/init.d/sshd.eth0
root #ln -s sshd /etc/init.d/sshd.wlan0

После следующей команды, конфигурация для них будет читаться из файлов /etc/conf.d/sshd.eth0 и /etc/conf.d/sshd.wlan0 соответственно:

root #cp /etc/conf.d/sshd /etc/conf.d/sshd.eth0
root #cp /etc/conf.d/sshd /etc/conf.d/sshd.wlan0

Добавьте зависимости:

root #echo 'rc_need="!net net.eth0"' >> /etc/conf.d/sshd.eth0
root #echo 'rc_need="!net net.wlan0"' >> /etc/conf.d/sshd.wlan0

В этом примере net.eth0 и net.wlan0 читают свою конфигурацию из файлов /etc/conf.d/net или /etc/conf.d/net.office, в зависимости от уровня выполнения. Добавьте эти сценарии инициализации на разные уровни:

root #rc-update add sshd.eth0 default
root #rc-update add sshd.wlan0 office
root #rc-update add net.eth0 default office
root #rc-update add net.wlan0 default office

Чтобы переключаться между уровнями выполнения "default" и "office" runlevel без перезагрузки компьютера, перейдите на уровень выполнения "nonetwork" между ними. Таким образом, сетевые интерфейсы буду остановлены, а специфичная для их уровня выполнения конфигурация перепрочитана. Лучше всего это работает, когда "nonetwork" является сложенным уровнем выполнения (анг. stacked runlevel), полученный путём сложения уровней выполнения "default" и "office", а графический менеджер и прочие не требущие сети сервисы находятся только на уровне выполнения "nonetwork". 

уровень выполнения default <---> уровень выполнения nonetwork <---> уровень выполнения office
root #rc nonetwork && rc office
root #rc nonetwork && rc default

Выбор конкретного уровня выполнения во время запуска системы

OpenRC прочитывает командную строку ядра (kernel command-line), используемую во время загрузки, и, если присутствует параметр softlevel, запускает указанный уровень выполнения. Если параметр softlevel не указан, используется уровень выполнения default (по умолчанию).

В следующем примере показана конфигурация grub, с помощью которой можно выбирать во время запуска системы, в какой уровень выполнения нужно загружаться (default или nonetwork):

ФАЙЛ /boot/grub/grub.confПример файла grub.conf (GRUB Legacy)
title=Обычный запуск
 
kernel (hd0,0)/boot/kernel-3.7.10-gentoo-r1 root=/dev/sda3
 
title=Запуск без поддержки сети
 
kernel (hd0,0)/boot/kernel-3.7.10-gentoo-r1 root=/dev/sda3 softlevel=nonetwork

Разделы ниже содержат информацию о создании дополнительных уровней выполнения.

Использование

Уровни выполнения

OpenRC может управляться и настраиваться через команды openrc, rc-update и rc-status.

К примеру, чтобы удалить сервис из уровня выполнения default (по умолчанию), где <сервис> — это название удаляемого сервиса:

root #rc-update delete <сервис> default

Отображение списка

Чтобы перечислить уровни выполнения и сервисы (сценарии инициализации) на этих уровнях, необязательно обладать правами суперпользователя.

Команда rc-update show -v перечислит все доступные сценарии инициализации (init scripts) и связанные с ними уровни выполнения (если они были установлены):

user $rc-update show -v

Запуск rc-update или rc-update show выведет только сценарии инициализации, которые были добавлены на какой-то уровень выполнения.

В качестве альтернативы можно использовать команду rc-status с опцией --servicelist (-s), чтобы просмотреть состояние всех сервисов:

user $rc-status --servicelist

Именованные уровни выполнения

Уровни выполнения в OpenRC реализованы в виде подкаталогов в /etc/runlevels. Чтобы создать дополнительный уровень выполнения (далее обозначен как <уровень>), выполните:

root #install -d /etc/runlevels/<уровень>

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

Сложенные уровни выполнения

Для управления вариантами можно использовать rc-update -s.

В статье OpenRC/Stacked runlevel можно найти пример использования сложенного уровня выполнения на ноутбуке для группировки сетевых сервисов в зависимости от расположения.

Prefix

Gentoo Prefix installs Gentoo within an offset, known as a prefix, allowing users to install Gentoo in another location in the filesystem hierarchy, hence avoiding conflicts. Next to this offset, Gentoo Prefix runs unprivileged, meaning no root user or rights are required to use it.

By using an offset (the "prefix" location), it is possible for many "alternative" user groups to benefit from a large part of the packages in the Gentoo Linux Portage tree. Currently users of the following systems successfully run Gentoo Prefix: Mac OS X on PPC and x86, Linux on x86, x86_64 and ia64, Solaris 10 on Sparc, Sparc/64, x86 and x86_64, FreeBSD on x86, AIX on PPC, Interix on x86, Windows on x86 (with the help of Interix), HP-UX on PARISC and ia64.

OpenRC runscript already support prefix-installed daemons, during the Summer of Code 2012 work will be done to implement full secondary/session daemon behavior to complete the overall feature set provided by Prefix.

OpenRC/Prefix, a tutorial for trying it out.

Горячее подключение (hotplug)

OpenRC может быть вызван в ответ на внешние события, например, «подключения нового устройства» от udev. Следующий конфигурационный файл содержит информацию о сервисах с горячим подключением (англ. hotplugged services):

ФАЙЛ /etc/rc.confrc_hotplug
# Переменная rc_hotplug контролирует, каким сервисам мы разрешаем горячее подключение.
# Сервис с горячим подключением вызывается динамическим менеджером устройств (dynamic dev manager),
# если найдено подходящее устройство.
# Сервисы с горячим подключением находятся на уровне выполнения "hotplugged".
# Если переменная rc_hotplug содержит любое значение, мы сравниваем название
# этого сервиса с каждым шаблоном в значении, слева направо, и,
# если один из шаблоном совпадает, мы разрешаем сервису горячее подключение.
# Шаблоны могут содержать символы подстановки для командной оболочки. 
# Чтобы предотвратить горячее подключение сервисов с таким паттерном, добавьте префикс "!".
# Если переменная rc_hotplug не выставлена или содержит пустое значение, горячее подключение отключается полностью.
# Пример - rc_hotplug="net.wlan !net.*"
# Этот шаблон разрешает сервису net.wlan и всем сервисам, не совпадающим с шаблоном net.* горячее подключение.
# Пример - rc_hotplug="!net.*"
# Этот шаблон разрешает всем сервисам, не совпадающим с шаблоном "net.*" горячее подключение.

Поддержка контрольных групп (CGroups)

Начиная с версии 0.12, OpenRC поддерживает расширенные контрольные группы. См. статью OpenRC/CGroups для получения более подробной информации. Начиная с OpenRC 0.51 unified cgroups (v2) включены по умолчанию.

Поддержка изолированного окружения (chroot)

root #mkdir -p /lib64/rc/init.d
root #ln -s /lib64/rc/init.d /run/openrc
root #touch /run/openrc/softlevel
root #emerge --oneshot sys-apps/openrc
ФАЙЛ /etc/rc.confКонфигурационный файл OpenRC
rc_sys="prefix"
rc_controller_cgroups="NO"
rc_depend_strict="NO"
rc_need="!net !dev !udev-mount !sysfs !checkfs !fsck !netmount !logger !clock !modules"

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

* WARNING: <сервис> is already starting

Это можно исправить, выполнив следующую команду:

root #rc-update --update

Интеграция с системой

Совместимость с systemd

logind

Некоторые установки требуют сервис systemd-logind. Elogind может быть подходящей заменой, как самостоятельный сервис logind, работающий с OpenRC.

tmpfiles.d

systemd имеет специальный синтаксис для файлов tmpfiles.d, управляющих вре́менными файлами. Пакет sys-apps/systemd-tmpfiles может самостоятельно предоставлять его для систем с OpenRC. Так же существует (объявленный как устаревший) пакет sys-apps/opentmpfiles, который (на данный момент) предоставляет tmpfiles.d интерпретатор для OpenRC.

Оба варианта можно также использовать для управления изменчивыми записями (volatile entries) в /sys или /proc.

udev и mdev

В Gentoo для управления подсистемой /dev доступны системы udev и mdev. Ранее также предоставлялся eudev, но он был удалён. sys-fs/udev является системой по умолчанию, однако OpenRC может работать с обоими в Gentoo.

Более старые установки Gentoo использовали систему udev как главный пакет, предоставляемый virtual/udev. Основываясь на обсуждении в bug #575718, этот пакет был заменён на eudev, но после обсуждения в bug #807193 его заменили обратно на udev. Однако rc-сервис и тогда, и сейчас находится по пути /etc/init.d/udev.

См. статью mdev для её возможного применения на, к примеру, встроенных системах (embedded systems).

Интеграция с BusyBox

Примечание: В этом разделе не хватает информации о том, как же всё-таки использовать BusyBox с OpenRC.

Please note that there are currently many BusyBox applets that are incompatible with OpenRC, see bug #529086 for details. Be warned that using OpenRC with BusyBox may require some work to set up. BusyBox is more adapted to embedded use, see previous section about mdev.

BusyBox can be used to replace most of the userspace utilities needed by OpenRC (init, shell, awk, and other POSIX tools), by using a complete BusyBox as the shell for OpenRC [1], all the calls that normally would cause a fork/exec would be spared, improving the overall speed.

The SysV-init /etc/inittab file provided by Gentoo is not compatible with the BusyBox init. Here is an example inittab compatible with BusyBox:

ФАЙЛ /etc/inittabExample inittab compatible with BusyBox init
::sysinit:/sbin/openrc sysinit
::wait:/sbin/openrc boot
::wait:/sbin/openrc

BusyBox provides a number of applets that could be used to replace third party software like acpid or dhcp/dhcpcd.

See the OpenRC documentation on using BusyBox with OpenRC.

Решение проблем

Перезапуск сервисов после сбоя

OpenRC умеет откатывать состояние сервисов до состояния «начало уровня выполнения» (англ. runlevel setting state), тем самым предоставляя сценарии инициализации с учётом состояния (англ. stateful init scripts) и автоматический перезапуск.

Чтобы перезапустить сервисы с уровнем выполнения по умолчанию после сбоя, запустите openrc: аварийно завершённые сервисы будут снова запущены, а запущенные вручную сервисы будут остановлены. Чтобы запущенные вручную сервисы продолжали работать, запустите openrc --no-stop (для краткости openrc -n)

По умолчанию openrc будет пытаться запускать аварийно завершённые сервисы, а не перезапускать их. Это поведение контролируется параметрами rc_crashed_stop (по умолчанию NO) и rc_crashed_start (по умолчанию YES) в файле /etc/rc.conf.

Ручной перезапуск сервисов после сбоя

Если при запуске процесса случается сбой, то при попытке запустить, остановить или показать статус сервиса будет выводиться предупреждение или сообщение об ошибке. Например, при использовании сервиса "docker":

root #rc-service docker status
 * status: crashed
root #rc-service docker start
 * WARNING: docker has already been started
root #rc-service docker stop
 * Caching service dependencies ...                                                                                                  [ ok ]
 * Stopping docker ...
 * Failed to stop docker                                                                                                             [ !! ]
 * ERROR: docker failed to stop

Чтобы исправить эту ситуацию, пометьте сервис как уже остановленный:

root #rc-service docker zap

См. также

Внешние ресурсы

Документация OpenRC

У OpenRC есть собственная полезная документация, которую поддерживают сами разработчики OpenRC. Имейте в виду, что Gentoo по умолчанию использует не все возможности OpenRC (ссылки на англ.):

Retrieved from "https://wiki.gentoo.org/index.php?title=OpenRC/ru&oldid=1287835"