Команда rc-service nginx start возвращает ошибку «command not found», а привычный systemctl restart nginx не работает — это первый признак того, что перед вами система с другой системой инициализации, чем ожидалось. Разница между systemd и OpenRC проявляется не в теории, а в конкретных командах, расположении юнитов и логике запуска сервисов. Именно поэтому выбор между ними стоит делать осознанно, понимая последствия для администрирования.
В этой статье разберём, чем отличаются две самые обсуждаемые системы инициализации Linux, какие дистрибутивы их используют, как выполнять типовые задачи в каждой из них и в каких сценариях одна предпочтительнее другой.
Что такое система инициализации и почему выбор важен
Система инициализации — это первый процесс, который запускает ядро Linux после загрузки (PID 1). Она отвечает за старт всех остальных служб: сети, дисплейного менеджера, демонов баз данных, планировщика задач. От её архитектуры зависит скорость загрузки, способ логирования, поведение при падении сервисов и даже то, как вы будете читать логи.
systemd — это целый набор компонентов: помимо PID 1 он включает журналирование (journald), управление сетью (systemd-networkd), планировщик по таймерам, обработку устройств и многое другое. OpenRC, напротив, придерживается Unix-философии «одна программа — одна задача»: это менеджер сервисов, который опирается на классический sysvinit в качестве PID 1 (хотя может работать и с другими init).
Практическая разница заметна сразу: в systemd конфигурация сервиса описывается декларативным юнит-файлом, а в OpenRC — исполняемым shell-скриптом в /etc/init.d/. Это влияет на стиль администрирования, отладку и переносимость наработок между системами.
Архитектура: монолит против модульности
Главное идейное различие — подход к границам ответственности. systemd интегрирует множество функций в единую экосистему, что даёт согласованные инструменты, но увеличивает объём кода, работающего с высокими привилегиями. OpenRC ограничивается запуском и контролем сервисов, передавая остальное отдельным утилитам.
- 🔧 systemd: юниты описываются в INI-подобном формате, зависимости заявляются явно через
After=иWants=. - 📜 OpenRC: скрипты пишутся на POSIX shell, зависимости указываются в функциях
depend()внутри самого скрипта. - 📦 systemd включает journald, logind, resolved и другие компоненты «из коробки».
- 🧩 OpenRC позволяет выбрать систему логирования (syslog-ng, rsyslog, metalog) и cron-реализацию независимо.
- ⚡ Обе системы поддерживают параллельный запуск сервисов, но реализуют его по-разному.
Для администратора это означает следующее: в systemd вы получаете предсказуемый стандартный набор инструментов почти в любом дистрибутиве, а в OpenRC — свободу собирать систему из независимых компонентов, заменяя любой из них без пересборки всего стека.
Сравнение команд управления сервисами
Повседневная работа с сервисами сводится к нескольким операциям: запуск, остановка, автозагрузка, просмотр статуса и логов. Ниже — таблица эквивалентов, которая поможет при переходе между системами.
| Задача | systemd | OpenRC |
|---|---|---|
| Запустить сервис | systemctl start nginx | rc-service nginx start |
| Включить автозагрузку | systemctl enable nginx | rc-update add nginx default |
| Проверить статус | systemctl status nginx | rc-service nginx status |
| Список всех сервисов | systemctl list-units --type=service | rc-status --all |
| Просмотр логов | journalctl -u nginx | файлы в /var/log/ через syslog |
Обратите внимание на концепцию уровней запуска (runlevels) в OpenRC: вместо таргетов systemd здесь используются именованные уровни — default, boot, sysinit. Сервис добавляется в конкретный уровень, и это даёт гибкость: можно создать собственный уровень, например для работы от батареи или для режима обслуживания.
В systemd аналогичную роль играют таргеты (multi-user.target, graphical.target), а зависимости разрешаются автоматически на основе декларативных описаний. Оба подхода рабочие, но ментальная модель различается: в OpenRC вы явно складываете сервисы в уровни, в systemd — описываете связи, а итоговый граф строится сам.
Скорость загрузки и потребление ресурсов
Вопрос «что быстрее» не имеет однозначного ответа: результат сильно зависит от конфигурации, набора сервисов и оборудования. systemd активно использует параллелизацию и активацию по сокетам, что на сложных конфигурациях даёт хорошее время до готовности системы. OpenRC тоже поддерживает параллельный запуск (опция rc_parallel="YES" в /etc/rc.conf), и на лёгких системах с небольшим числом сервисов загрузка может быть очень быстрой.
По потреблению памяти разница заметнее: набор компонентов systemd (journald, logind и др.) обычно занимает больше оперативной памяти, чем минимальная связка sysvinit + OpenRC. Для современного десктопа это некритично, но на встраиваемых устройствах, старых машинах или в минимальных контейнерах экономия ресурсов может быть аргументом.
Для измерения реальной скорости загрузки в systemd есть встроенный инструмент:
systemd-analyze
systemd-analyze blame
Первая команда покажет общее время, вторая — какие юниты стартовали дольше всего. В OpenRC подобного штатного анализатора нет — оценку делают по логам загрузки или сторонними средствами.
Дистрибутивы и экосистема
Выбор системы инициализации чаще всего определяется дистрибутивом. Подавляющее большинство мейнстрим-систем — Debian, Ubuntu, Fedora, openSUSE, Arch Linux — используют systemd по умолчанию. Это значит, что документация, пакеты и готовые юниты в первую очередь пишутся под systemd.
- 🏔️ Alpine Linux — популярный минималистичный дистрибутив на OpenRC, широко применяется в контейнерах.
- 🎩 Gentoo — поддерживает оба варианта, OpenRC остаётся классическим выбором.
- 😈 Devuan — форк Debian без systemd, предлагает OpenRC среди альтернатив.
- 🗡️ Artix — вариант Arch с OpenRC, runit или s6.
- 🌌 Void Linux — использует runit, но часто упоминается в тех же дискуссиях.
⚠️ Внимание: смена системы инициализации в уже установленном дистрибутиве — рискованная операция. Некоторые пакеты (например, окружения рабочего стола) жёстко завязаны на компоненты systemd, и их удаление может нарушить работу системы. Если нужен другой init, надёжнее установить дистрибутив, который поддерживает его штатно.
Ещё один практический момент — совместимость ПО. Часть серверного и десктопного софта рассчитывает на наличие systemd-интерфейсов: logind для управления сеансами, юниты для автозапуска. В системах без systemd эти функции закрывают альтернативы вроде elogind (отделённый logind, применяется в Gentoo и Artix), но полную совместимость гарантировать нельзя — конкретное поведение стоит проверять для вашего набора пакетов.
Почему systemd вызывает столько споров
Критика systemd строится на трёх аргументах: нарушение Unix-философии из-за объединения множества функций в один проект, бинарный формат журналов journald (их нельзя читать обычным текстовым редактором) и фактическая монополизация — крупные дистрибутивы завязаны на systemd, что сужает выбор. Сторонники отвечают: унификация упростила сопровождение дистрибутивов, декларативные юниты удобнее shell-скриптов, а journalctl предоставляет мощный поиск по логам. Обе позиции имеют рациональное зерно.
Как выбрать: практические критерии
Единственно верного ответа нет — есть набор критериев, по которым вы сопоставляете систему со своей задачей. Пройдитесь по чек-листу ниже.
☑️ Чек-лист выбора системы инициализации
Для корпоративного сервера, где важны стандартизация, обширная документация и предсказуемость при найме администраторов, systemd — разумный дефолт: с ним знакомо большинство специалистов, а инструменты вроде journalctl и systemd-analyze ускоряют диагностику.
Для контейнеров, встраиваемых систем, минималистичных установок и ситуаций, где вы хотите полностью понимать и контролировать каждый запускаемый компонент, OpenRC (в составе Alpine или Gentoo) даёт прозрачность и малый расход ресурсов. Shell-скрипты инициализации можно прочитать и отладить обычным текстовым редактором, не изучая отдельный формат юнитов.
⚠️ Внимание: не переносите юниты systemd в OpenRC «как есть» и наоборот. Директивы вроде
Restart=alwaysили зависимостейRequires=не имеют прямых текстовых аналогов в rc-скриптах — логику перезапуска и зависимостей нужно переписывать вручную с учётом синтаксисаsupervise/depend()конкретной системы.
Если вы только изучаете Linux, начните с systemd — это стандарт индустрии, и навыки будут востребованы. К OpenRC имеет смысл переходить осознанно, когда появляются конкретные требования: минимализм, аудит каждого компонента или работа в дистрибутиве вроде Alpine.
Миграция и тестирование
Безопасный путь оценки альтернативной системы инициализации — виртуальная машина или контейнер. Установите, например, Alpine Linux в VirtualBox или QEMU и повторите там свои типовые задачи: разверните веб-сервер, настройте автозагрузку, посмотрите логи. Так вы получите практическое представление без риска для рабочей системы.
Для проверки, какая система инициализации используется в текущей установке, выполните:
ps -p 1 -o comm=Вывод systemd или init (при OpenRC PID 1 обычно занимает sysvinit) сразу прояснит ситуацию. Это полезно и при подключении к чужому серверу, и при работе внутри контейнера, где init может отсутствовать вовсе.
При полноценной миграции сервера на другой init заранее составьте список всех работающих сервисов (systemctl list-units --type=service --state=running), экспортируйте их конфигурации и подготовьте эквивалентные rc-скрипты. Обязательно проверьте загрузку системы после смены init в тестовой среде — ошибка в критичном сервисе может оставить машину без сети или возможности входа.
Часто задаваемые вопросы
Можно ли удалить systemd из Ubuntu или Debian и поставить OpenRC?
Технически попытки существуют, но штатно это не поддерживается: многие пакеты зависят от systemd-компонентов, и система может стать неработоспособной. Если нужен OpenRC, корректный путь — установить дистрибутив, где он поддерживается официально: Devuan, Artix, Gentoo или Alpine.
Правда ли, что OpenRC быстрее systemd?
Однозначного ответа нет. На минимальных конфигурациях OpenRC часто показывает меньшее потребление памяти и быстрый старт, но systemd эффективнее параллелит запуск большого числа сервисов. Результат зависит от конкретной системы — измеряйте на своём железе, а не полагайтесь на чужие бенчмарки.
Работает ли OpenRC без sysvinit?
Да. OpenRC — это менеджер сервисов, а не PID 1. По умолчанию он использует sysvinit в роли первого процесса, но может работать и с альтернативами, например с openrc-init или в связке с другими init-системами. Конкретную комбинацию стоит проверять в документации вашего дистрибутива.
Что делать с логами в OpenRC, если нет journald?
В OpenRC логирование выполняет отдельный syslog-демон: syslog-ng, rsyslog или metalog — его нужно установить и добавить в уровень запуска командой rc-update add syslog-ng default (имя пакета зависит от дистрибутива). Логи хранятся в текстовых файлах в /var/log/ и читаются любыми стандартными инструментами.
Поддерживает ли OpenRC пользовательские сервисы, как systemd --user?
Штатного эквивалента systemctl --user с полноценными пользовательскими сессиями в OpenRC исторически не было; функциональность в этой области развивается и зависит от версии и дистрибутива. Если пользовательские юниты критичны, проверьте актуальную документацию OpenRC и вашего дистрибутива перед миграцией.