Спор о системах инициализации обычно начинается с эмоций и заканчивается одинаково: на сервере стоит то, что пришло с дистрибутивом. Между тем systemd и OpenRC решают разные задачи разными средствами, и понимание этой разницы помогает не спорить, а выбирать. Ниже — сравнение по архитектуре, управлению сервисами, зависимостям, логам и ресурсам, с командами для обеих систем.

Архитектура: один демон против набора скриптов

systemd — это единый процесс с PID 1, который управляет юнитами, монтированиями, сокетами, таймерами и сессиями. Юнит описывается декларативно: вы говорите, что запустить и от чего это зависит, а порядок и параллельность система вычисляет сама. Состояние хранится в cgroups, поэтому systemd точно знает, какие процессы принадлежат сервису, даже если демон форкнулся.

OpenRC — набор shell-скриптов и небольших утилит. PID 1 в этой модели — обычно busybox init или sysvinit, который вызывает OpenRC на нужных этапах. Сервис описывается императивным init-скриптом в /etc/init.d/, а зависимости — функцией depend(). Такой подход прозрачнее: любой скрипт можно прочитать и понять, что он делает.

Управление сервисами: команды рядом

Повседневные операции выглядят похоже, но синтаксис отличается. В systemd почти всё делает systemctl, в OpenRC — пара rc-service и rc-update.

systemctl status nginx
systemctl enable --now nginx
systemctl restart nginx
systemctl list-units --type=service --state=running
rc-service nginx status
rc-update add nginx default
rc-service nginx restart
rc-status --all

В OpenRC нет отдельной команды «включить и запустить»: rc-update add добавляет сервис в runlevel, а rc-service start запускает его сейчас. Runlevel — это именованный набор сервисов: sysinit, boot, default, shutdown. В systemd аналог цели — multi-user.target.

Зависимости и порядок запуска

В systemd зависимости описываются в секции [Unit]. After задаёт порядок, Requires — жёсткую связь, Wants — мягкую. Сокет-активация позволяет запускать сервис по первому подключению, а таймеры заменяют cron.

[Unit]
Description=My API
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/myapi --port 8080
Restart=on-failure
User=myapi

[Install]
WantedBy=multi-user.target

В OpenRC зависимости задаются в скрипте. Ключевые слова need, use, after и before читаются как обычный текст, а не как декларация.

#!/sbin/openrc-run
name="myapi"
command="/usr/local/bin/myapi"
command_args="--port 8080"
command_user="myapi"
depend() {
    need net
    after firewall
}

Разница в том, кто отвечает за порядок. systemd строит граф зависимостей и запускает независимые юниты параллельно. OpenRC тоже умеет параллельный старт, если включить rc_parallel="YES" в /etc/rc.conf, но по умолчанию он более последовательный.

Логи и диагностика

systemd пишет вывод сервисов в journald. Логи индексируются по юниту, загрузке и приоритету, поэтому journalctl быстро отвечает на вопрос «что случилось при старте».

journalctl -u nginx -b --no-pager
journalctl -p err -b
systemd-analyze blame
systemd-analyze critical-chain

OpenRC не перехватывает stdout сам по себе. Сервисы пишут в свои файлы, в syslog или в stdout, который уходит в консоль. Включается общий журнал через rc_logger="YES", тогда действия OpenRC попадают в /var/log/rc.log. Для отладки конкретного сервиса смотрят rc-service nginx status и его собственный лог.

При разборе загрузки полезно смотреть не только ошибки, но и время. В systemd systemd-analyze показывает общее время и вклад каждого юнита, включая firmware и загрузчик. В OpenRC время старта видно в /var/log/rc.log, если включён логгер, а также по меткам в dmesg. Сравнивать системы по одной цифре бессмысленно: на ноутбуке с NVMe разница может быть незаметна, а на слабой виртуалке — достигать нескольких секунд.

Скорость, ресурсы и безопасность

На ноутбуке или минимальной виртуалке разница в потреблении заметна: systemd тянет journald, logind и десяток вспомогательных служб, OpenRC обходится меньшим числом процессов. Зато systemd даёт cgroups «из коробки»: можно ограничить память, CPU и число процессов для сервиса.

  • systemd: MemoryMax, CPUQuota, TasksMax прямо в юните;
  • systemd: песочница через ProtectSystem, PrivateTmp, NoNewPrivileges;
  • OpenRC: базовая поддержка cgroups есть, но настраивается скромнее;
  • OpenRC: изоляция держится на правах файлов и отдельном пользователе сервиса.

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

Где что используется

systemd — стандарт в Debian, Ubuntu, Fedora, RHEL, Arch и openSUSE. OpenRC по умолчанию стоит в Alpine Linux и Gentoo, доступен в Artix и Devuan как альтернатива. Отсюда практическое правило: если вы администрируете обычные серверы, учите systemd; если работаете с контейнерами на Alpine, минимальными образами и встраиваемыми системами, без OpenRC не обойтись.

В контейнерах systemd требует привилегий и дополнительных настроек, поэтому в лёгких образах чаще оставляют OpenRC или вообще один процесс. Это не идеология, а вопрос цены: каждый лишний слой нужно обновлять и защищать.

Отдельный сценарий — миграция. Переносить сервисы между системами лучше по одному: сначала опишите юнит или init-скрипт, затем проверьте автозапуск, логи и зависимости. Не копируйте старые sysv-скрипты в systemd через обёртки без необходимости — теряются преимущества обоих подходов. В systemd изменения удобно хранить в drop-in файлах через systemctl edit, чтобы не править пакетный юнит.

Что выбрать

  • нужны таймеры, сокет-активация и единые логи — systemd;
  • важны минимальный размер и читаемые shell-скрипты — OpenRC;
  • много legacy-сервисов и старые инструкции — скорее OpenRC или sysvinit;
  • настольный компьютер с GNOME или KDE — systemd;
  • контейнеры и embedded — OpenRC;
  • смешанный парк — не пытайтесь унифицировать любой ценой.

Итог

systemd и OpenRC решают одну задачу разными способами: первый даёт больше возможностей и интеграции ценой сложности, второй — прозрачность и малый вес ценой ручной работы. Выбор определяется дистрибутивом и сценарием, а не спором в интернете. Освойте оба набора команд — это занимает вечер и снимает половину проблем при переходе между системами.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте