Если вы зашли на эту статью, то, вероятно, хотите узнать об использовании системы инициализации OpenRC. Она довольно широко используется во многих дистрибутивах, таких как Gentoo, Artix, Devuan и некоторых других. В данном материале я попробую просто и понятно показать базовое использование OpenRC. Начнем!
Runlevel или "Уровни запуска"
Думаю, название говорит само за себя: Уровень выполнения (Runlevel) представляет собой уровень запуска процессов при инициализации системы. Всего существует 7 стандартных уровней, однако скорее всего вы будете использовать только 3: sysinit, boot, default.
Чем же отличаются эти "runlevels"?
sysinit - инициализирует систему и базовые компоненты. Например: cgroups, devfs, sysfs, udev.
boot - запускает все процессы, необходимые для работы операционной системы или других процессов. Например: bootmisc, hwclock, modules, swap, root.
default - запускает уже "кастомные" процессы пользователя. Например: dbus, cupsd, elogind, ntpd и иные.
В большинстве случаев вам хватит использования уровня "default", поэтому давайте посмотрим, как добавить нужный демон в автозагрузку:
# rc-update add имясервиса default
Чтобы удалить сервис, напишем следующее:
# rc-update del имясервиса default
Управление состоянием сервиса
Для старта демона напишем:
# rc-service имясервиса start
Чтобы перезагрузить:
# rc-service имясервиса restart
Для завершения процесса используем:
# rc-service имясервиса stop
Листинг доступных сервисов и их уровень запуска
# rc-update show -v
Ваши собственные "демоны", или скрипты запуска команд при старте
Все сервисы располагаются в директории /etc/init.d. Соответственно, перейдем туда:
cd /etc/init.d
Предположим, мы хотим скачивать главную страницу pingvinus.ru на наш компьютер локально в директорию /home/user/webpages. Для этого создадим файл (название может быть любым) и напишем туда следующее содержание:
#!/sbin/openrc-run
depend () {
need networking
after bootmisc
}
start() {
wget -P /home/user/webpages pingvinus.ru
}
Поясню по содержанию файла. Функция depend отвечает за требования, которые должны быть выполнены перед запуском нашей команды. В данном случае мы требуем наличие выхода в Интернет и запуск процесса после старта bootmisc (полная базовая инициализация). Если вашему софту, например, нужен D-Bus для работы, то обязательно укажите его после after, а иначе процесс может не запуститься или работать некорректно.
После всех изменений мы сохраняем файл и даем ему разрешение на запуск с помощью следующей команды:
# chmod +x pingvinus
Далее добавим его в автозагрузку:
# rc-update add pingvinus default
Браво! Мы написали простейший сервис для OpenRC!
Отслеживание состояния сервисов
Состояние всех сервисов:
# rc-status --servicelist
Состояние одного конкретного демона:
# rc-service имясервиса status
Свои уровни запуска и как это может помочь
Смоделируем ситуацию: вы хотите проксировать ваш трафик в некую страну N. И вы хотите, чтобы это было на самом низком уровне. Для этого вы можете создать новый уровень запуска и создать там кастомные скрипты для проксирования. Такой подход исключает возможность конфликта сервисов и делает управление всей этой системой более удобным и логичным.
Для того чтобы создать новый runlevel напишем следующее:
# install -d /etc/runlevels/название
Далее просто добавьте нужные сервисы через rc-update и наслаждайтесь жизнью.
Контроль над упавшими сервисами
По умолчанию OpenRC будет пытаться запустить их снова, однако в некоторых случаях это может привести к еще более нежелательным последствиям.
Поэтому вы можете настроить правило поведения при сбое сервиса в /etc/rc.conf:
....
rc_crashed_stop=YES/NO # останавливать или НЕ останавливать упавший сервис
rc_crashed_start=YES/NO # запускать или НЕ запускать сломавшийся процесс
На этом я завершаю эту заметку и говорю "спасибо" за прочтение! Приятного дня.
Комментарии
08:36
+
Спасибо.
09:33
В моем случае даже весьма своевременная, так как в процессе работы с OpenRC.
Большое человеческое спасибо и жирнющее "Мне нравится"! :D
10:27
С одним моментом. Runlevel - это не "уровень запуска процессов", а уровень работы системы. Так будет более понятен механизм работы. Система может переходить с одного уровня на другой, но в каждый момент времени работает на одном уровне. И на каждом есть сервисы, выполняющиеся только тогда, когда система переходит на соответствующий уровень.
Посему, уровни по тексту "sysinit boot default" - это немного не верно.
10:30
# rc-update — таблица загруженных служб с уровнями запуска (или rc-update --all)
Команда вывода служб по уровню запуска, например default и boot
# rc-update show default
# rc-update show boot
Команда вывода состояния (started или stoped) служб с сортировкой по уровням запуска
# rc-status --all
Команда вывода списка служб и их состояния (started или stoped)
# rc-status --servicelist
Команда вывода списка действующих уровней запуска
# rc-status --list
sysinit
shutdown
nonetwork
default
boot
Но вот про создание собственных ещё не встречал (не искал и не было нужды). Спасибо
10:42
# rc-update add -s default мойуровень
И потом любой сервис можно удалить из уровня default и запускать его под уровнем "мойуровень". Не забыть добавить в /etc/inittab:
::once:/sbin/openrc мойуровень
Это может быть полезно, если какой-то сервис тормозит запуск окна входа в систему, например chronyd
11:06
11:46
16:58
18:52
Сам небольшой поклонник openrc, т.к. использовал его на Alpine
19:39
19:46
20:09
20:38
Void, Gentoo, Slackware - вот наверное топ-3, который не подводит. С девуаном у меня вообще как то дела не очень, хотя наверное я просто криворукий, не знаю.
20:46
21:05
21:19
21:27
Но мне проще переустановить, делается это быстро, чего не скажешь про установщик Devuan, где надо всё по шагам, а потом ещё и докачивать половину пакетов. Я вообще там с установочными iso не сильно разобрался, уже на этом этапе проблемы были. Тут же всё в графике и по шагам, освоился быстро. Скачал последний срез, быстро установил, перенёс конфиги забэкапленные и дальше пользуюсь.
06:40
После eclean-dist загляните и почистите:
/usr/src/*
/lib/modules/*
rm -rf /var/tmp/portage/[a-z]*
А вообще полезно посмотреть, где "пухнет":
du --max-depth=1 -lh /
и далее разворачивая путь.
14:18
Для контроля / у меня конки на раб столе показывают занятое место (но туда не всегда обращаю внимание) + программа QDirStat, предустановленная в Xfce.
Я сам добавил в закладки Thunar директорию /var/calculate/distfiles/, периодически 'sudo rm *' там. Как я понял, там остаются исходники и архивы, которые emerge загружает, но не удаляет потом (после установки), поэтому со временем папка пухнет.
А вот в системные каталоги лезть боюсь, вдруг чего удалю и сломаю что-то … Те строки выше себе схоронил.
06:19
20:53
22:03
При правильном обновлении ничего не ломается.
Вот арч, нужно обновлять постоянно, пару-тройку дней не зайдешь - лови десятка два-три обновлений. За Калькой такого не замечено. Манжара вообще смотрю плавно переходит к стабильному варианту, обновления стали выкатывать раз в 2-3 месяца.
22:25
22:33
Почему нет? Подключаете ветку unstable (ACCEPT_KEYWORDS="~amd64") и в бой :) Всё официально.
22:56
в debian stable можно подключить репы sid, и после этого он прекратит быть таким, как его задумали разработчики.
абсолютно точно так же и в calculate: подключая нестабильные ветки Вы превращаете прекрасный и стабильный calculate в собственное поле экспериментов. Но дистром, как его задумали разрабы он быть перестаёт.
22:50
Скорее всего ваш опыт - это два-три года назад или даже больше. У меня более свежий опыт - всё стало получше. Parabola (да, не арч) обновилась за 4,5 года, EOS (не арч) за год, Calculate за 10 месяцев, Sid за 6 месяцев.
06:18
13:17
В том смысле, например, что версия Винды обновляется вообще раз в несколько лет и официально может не поддерживать свои же старые сервисы и утилиты...
Как, в этой связи, мы можем требовать от Линуксов (мега)стабильности?
P.S. Чем ближе к K.I.S.S., тем стабильнее. Но доступнее ли от этого (разнообразный и полезный) софт?
P.P.S. Непреодолимая делемма, имхо...
15:27
20:39
стабильные (пакеты, ядра) - хорошо протестированные и документированные, требующие обновления только в случае фиксов безопасности (не обязательно в них, в используемых библиотеках и т. д.) либо обновления функционала.
нестабильные - самые свежие, собранные мэйнтэйнерами (не обязательно самые свежие вообще, тут тоже много "но", начиная от количества мэйнтейнеров, заканчивая тщательностью тестирования: в принципе нерабочий пакет нечасто попадает в sid, но нередко в arch).
между ними тестируемые - попадающие по строгим внутренним критериям из нестабильных, предназначенные для следующей стабильной версии.
это всё термины debian, а не мои представления, в других дистрах критерии могут несколько отличаться, но принципиально сути это не меняет.
Соответственно, роллинг дистры бывают стабильные и нестабильные по набору своих пакетов исходя из критериев выше, первые трудно сломать, вторые трудно не сломать.
Оптимальной для обычного пользователя мне видится testing-ветка у debian (убунта LTS болтается где-то около), хотя я сижу на unstable (void и devuan, последнее время в основном void).
00:09
00:05
20:28
20:59
00:06
22:16
23:29
https://github.com/systemd/systemd/releases/tag/v256-rc1
13:35
03:25
А может лучше всем вернуться в лоно природы и сделать opendoas стандартом?
11:20