Выбор между runit и OpenRC встаёт перед пользователем уже на этапе установки дистрибутива вроде Artix или Void Linux, и ошибка здесь оборачивается либо ручным прописыванием зависимостей сервисов, либо борьбой с незнакомыми командами управления демонами. Обе системы позиционируются как легковесная альтернатива systemd, но построены на совершенно разных принципах: runit реализует парадигму «надзора» (supervision), а OpenRC — классическую модель SysV-совместимых скриптов с зависимостями.
Чтобы выбрать осознанно, недостаточно знать, что «обе быстрые». Нужно понимать, как каждая система стартует сервисы, как следит за их состоянием, как обрабатывает падения демонов и какой объём ручной настройки потребуется. Ниже — детальное сравнение по всем практически значимым критериям.
Архитектура и философия проектов
runit — это набор утилит, построенный по принципам daemontools. Система состоит из трёх стадий: инициализация, запуск и остановка. Ключевая особенность — supervision: каждый сервис работает под контролем процесса-надзирателя, который автоматически перезапускает упавший демон. Схема сервиса предельно проста — каталог со скриптом run, который запускает процесс на переднем плане.
OpenRC развивается проектом Gentoo и представляет собой надстройку над SysV init (или другим PID 1). Сервисы описываются shell-скриптами с явным указанием зависимостей через директивы depend(). OpenRC умеет параллельный запуск, runlevel-ы и интеграцию с cgroups, но не занимается надзором за процессами «из коробки» — для этого подключаются внешние средства.
Философская разница фундаментальна: runit требует, чтобы демон не форкался в фон, а OpenRC традиционно работает с демонами, которые сами уходят в background. Это влияет на то, как пишутся и отлаживаются сервисные скрипты.
Скорость загрузки и потребление ресурсов
Обе системы заметно легче systemd по объёму кода и потреблению памяти, и точные цифры сильно зависят от конкретной конфигурации, набора сервисов и оборудования — универсальных бенчмарков здесь нет. Тем не менее, общие закономерности прослеживаются.
- ⚡ runit имеет минимальный PID 1 и запускает сервисы почти мгновенно за счёт простой структуры каталогов
/etc/runit/runsvdir/. - 🚀 OpenRC поддерживает параллельный старт сервисов с учётом графа зависимостей, что ускоряет загрузку при большом числе демонов.
- 💾 Обе системы потребляют минимум оперативной памяти в простое — разница на практике неощутима.
- 🔧 В OpenRC разрешение зависимостей добавляет небольшие накладные расходы при старте каждого сервиса.
На практике разница во времени загрузки между runit и OpenRC измеряется долями секунды и редко является решающим фактором. Куда важнее поведение системы после старта.
Управление сервисами: команды и повседневная работа
В runit сервис активируется созданием символической ссылки из каталога определения сервиса в каталог активных сервисов. Управление выполняется командой sv:
ln -s /etc/sv/sshd /var/service/
sv status sshd
sv restart sshd
В OpenRC используется команда rc-service и управление runlevel-ами через rc-update:
rc-update add sshd default
rc-service sshd start
rc-service sshd status
Разница в подходе ощутима ежедневно. В runit перезапуск упавшего сервиса происходит автоматически надзирателем — вмешательство не требуется. В OpenRC по умолчанию упавший демон останется остановленным, пока вы не перезапустите его вручную или не настроите дополнительный механизм надзора.
Сравнительная таблица
| Критерий | runit | OpenRC |
|---|---|---|
| Модель работы | Supervision (надзор за процессами) | Скрипты инициализации с зависимостями |
| Автоперезапуск упавших сервисов | Встроен, работает по умолчанию | Требует внешних средств (например, supervise-daemon) |
| Управление зависимостями | Ручное, внутри скриптов run | Автоматическое через depend() в скриптах |
| Активация сервиса | Символическая ссылка в /var/service/ | rc-update add в нужный runlevel |
| Дистрибутивы по умолчанию | Void Linux, опционально Artix | Alpine Linux, Gentoo, опционально Artix |
Написание собственных сервисов
Создать сервис для runit проще: нужен каталог с исполняемым файлом run, который запускает программу на переднем плане. Для логирования рядом кладётся подкаталог log со своим скриптом run, связанным через пайп. Минимальный сервис умещается в несколько строк.
В OpenRC сервисный скрипт пишется на POSIX shell с использованием библиотеки openrc-run. Необходимо объявить функцию depend(), где указываются зависимости вида need net или after firewall. Это даёт более строгий контроль порядка запуска, но требует понимания уровней зависимостей.
☑️ Создание сервиса для runit
⚠️ Внимание: если демон в runit-сервисе сам уходит в фон (форкается), надзиратель будет считать его завершившимся и начнёт бесконечно перезапускать. Проверьте документацию программы на предмет опции запуска на переднем плане (часто это флаги вроде-D,-fили--foreground) — точный флаг зависит от конкретного демона.
Зависимости и сложные сценарии загрузки
Главное преимущество OpenRC — декларативное управление зависимостями. Если сервису нужна сеть, достаточно указать need net, и система сама выстроит порядок запуска. Для машин с множеством взаимосвязанных демонов (СУБД, веб-серверы, очереди сообщений) это заметно упрощает поддержку.
В runit зависимости приходится обрабатывать вручную. Типовой приём — проверка доступности нужного сервиса внутри скрипта run через sv check с циклом ожидания:
#!/bin/sh
sv check postgresql || exit 1
exec my_daemon --foreground
Такой подход работает надёжно, но при большом числе сервисов превращается в рутину. Кроме того, логика ожидания размазывается по множеству скриптов, что усложняет аудит.
Что такое runlevel в OpenRC и зачем он нужен
Runlevel — это именованный набор сервисов, запускаемых на определённом этапе работы системы. По умолчанию используются уровни sysinit, boot, default и другие. Командой rc-update add сервис уровень сервис привязывается к нужному уровню, а переход между уровнями выполняется командой openrc имя_уровня. Это позволяет, например, иметь отдельный уровень для серверного и десктопного профиля на одной машине.
Логирование и диагностика
runit предлагает встроенное решение: демон svlogd пишет логи в каталог сервиса с автоматической ротацией по размеру. Конфигурация ротации задаётся файлом config рядом с логами. Логи каждого сервиса изолированы, что удобно при разборе инцидентов.
OpenRC сам по себе логированием не занимается — вывод сервисов обычно направляется в системный syslog-демон (rsyslog, syslog-ng и т.п.) или в файл, указанный в скрипте. Это даёт гибкость, но требует отдельной настройки.
Когда выбрать runit, а когда OpenRC
Однозначного победителя нет — выбор определяется задачами. Сводные рекомендации выглядят так:
- 🖥️ Для десктопа или личного сервера с небольшим числом демонов runit даёт минимальную сложность и надёжный автоперезапуск.
- 🗄️ Для сервера с множеством взаимозависимых сервисов OpenRC удобнее за счёт декларативных зависимостей и runlevel-ов.
- 📦 Если важна экосистема пакетов, ориентируйтесь на дистрибутив: Void тесно интегрирован с runit, Alpine и Gentoo — с OpenRC.
- 🧰 Если нужен надзор за процессами, но нравится OpenRC, посмотрите на встроенный
supervise-daemon— он частично закрывает этот пробел.
⚠️ Внимание: смена системы инициализации на уже установленной системе — рискованная операция, которая может оставить машину без возможности загрузки. Перед экспериментами сделайте резервную копию и подготовьте Live-носитель для восстановления. Безопаснее ставить дистрибутив с нужным init сразу.
Часто задаваемые вопросы
Можно ли использовать OpenRC без systemd?
Да, именно так OpenRC и применяется чаще всего — например, в Alpine Linux и Gentoo он работает поверх классического SysV init или собственного openrc-init, полностью заменяя systemd.
Перезапустит ли runit сервис, если тот упал из-за ошибки в конфигурации?
Да, надзиратель будет перезапускать процесс, но при постоянной ошибке это превратится в цикл падений. Поэтому перед включением сервиса проверяйте конфигурацию демона и смотрите логи через svlogd.
Сложно ли перейти с systemd на runit или OpenRC?
Сам переход технически выполним в дистрибутивах, которые это поддерживают (например, Artix предлагает готовые варианты), но потребуется заменить все unit-файлы на сервисные скрипты новой системы. Для продуктивной машины надёжнее чистая установка.
Какая из систем быстрее загружает компьютер?
Обе заметно легче systemd, а разница между ними в типовой конфигурации составляет доли секунды и зависит от набора сервисов и диска. Скорость не должна быть главным критерием выбора.
Поддерживает ли OpenRC параллельный запуск сервисов?
Да, параллельный старт включается в конфигурации OpenRC (параметр rc_parallel в /etc/rc.conf) и выполняется с учётом графа зависимостей, что ускоряет загрузку при большом количестве демонов.