Система инициализации: почему systemd победила, но до сих пор всех бесит? (Взгляд из 2026)

[pisula]

Привет всем, кто когда-либо правил конфиги в /etc/rc.d/ и с ностальгией вспоминает простоту скриптов в /etc/init.d/.

Если вы в последние лет десять заходили в любой линуксовый чат и роняли фразу «systemd», можно было сразу надеть каску — начнется холивар. В 2026 году уже очевидно, что systemd окончательно и бесповоротно победила. Её нет разве что в специфичных дистрибутивах для энтузиастов, на роутерах и на старых серверах, которые «работают — и не трогай». Но споры не утихают. Давайте попробуем разобраться почему, без фанатизма и с долей самоиронии.

Краткая история войны: от простого к сложному​

Раньше (во времена SysV init) всё было понятно, как кирпич:

• init — процесс №1.
• Запускает скрипты из /etc/rc.d/ по алфавиту.
• Скрипты — это просто bash-файлы, которые можно открыть, прочитать и, при должной сноровке, починить.
• Параллельный запуск? Что это? Мы запускаем всё последовательно, как боги завещали.

Проблема была в том, что с ростом сложности систем этот подход начал трещать по швам. Загрузка занимала вечность, зависимости между сервисами приходилось прописывать вручную в костыльных костылях, а стандартного способа управлять сокетами или юнитами просто не существовало.

И тут появилась systemd со своим лозунгом «давайте приведем всё к единому стандарту и сделаем это быстро».

Чем systemd всех покорила (даже тех, кто этого не признает)​

Несмотря на всю критику, она принесла реальные и осязаемые плюсы, которые оценили даже в консервативных серверных дистрибутивах вроде RHEL:

1. Скорость загрузки. Параллельный запуск сервисов с учетом зависимостей — это не маркетинг. Это реально работает. Система грузится заметно быстрее.
2. Единая конфигурация. Вмере кучи bash-скриптов разного качества — единые .service и .socket файлы в одном стиле. Научился работать с одним — разберешься и с другими.
3. Встроенный супервизор процессов. Раньше для того, чтобы сервис автоматически перезапускался при падении, приходилось ставить supervisord или monit. Теперь это нативно прописывается парой строк в юните. Мелочь, а приятно.
4. Централизованное управление логами через journalctl. Возможность в реальном времени следить за логами всех сервисов, фильтровать по времени, юниту или уровню ошибки — мощнейший инструмент для диагностики.
5. Контроль за ресурсами (cgroups). Systemd с самого начала тесно интегрирована с контрольными группами ядра. Это позволяет легко ограничивать сервисы по памяти, CPU и дисковому вводу-выводу прямо в конфиге сервиса.

А что же всех так бесит? Причины ненависти​

Ладно, плюсы ясны. Но почему же столько людей до сих пор говорят о ней с раздражением? Причины — не только технические.

1. Нарушение философии Unix. Классический принцип «делай одну вещь и делай её хорошо» systemd нарушает с размахом. Это не просто система инициализации. Это и менеджер логов, и менеджер сетей (networkd), и планировщик заданий (timers), и даже инструмент для приветствия пользователя (getty). Монолит в мире микросервисов. Многих это отталкивает принципиально.
2. Сложность и «магия». Раньше, чтобы понять, почему не стартует сервис, ты открывал bash-скрипт и шагал по строчкам. Теперь же приходится разбираться в собственном языке конфигурации, смотреть зависимости через systemctl list-dependencies, копаться в journalctl. Прозрачность уменьшилась, порог входа вырос.
3. Жесткая привязка к Linux. Хотите портировать свою систему на *BSD или какой-нибудь Hurd? Со systemd это практически невозможно. Это сознательный выбор разработчиков, но он лишает сообщество гибкости.
4. «Баг или фича?» Нетривиальное поведение. Например, известная история с TimeoutStopSec, когда сервис при остановке не убивается жестко, а уходит в особое состояние, или сложности с запуском в собственных namespace. Порой поведение systemd неочевидно даже для опытных админов.

Что в 2026? Альтернативы живы, но в нишах​

Да, война проиграна. Но альтернативы не умерли — они ушли в экосистемы, где их принципы востребованы:

• OpenRC — царь в мире Gentoo и Alpine Linux. Легковесная, модульная, следует философии Unix. Идеально для систем, где контроль и простота важнее скорости.
• runit — минималистичный и надежный демон-супервизор. Его до сих пор обожают за простоту в некоторых минималистичных дистрибутивах и Docker-образах.
• s6 — сложная, но невероятно мощная иерархическая система инициализации для тех, кто готов разобраться. Культовый статус в нишевых сообществах.

Вывод из 2026 года:
Systemd — это как современный автомобиль с кучей электроники. Его нельзя починить в поле с помощью гаечного ключа и изоленты, зато он предлагает невиданный ранее комфорт, безопасность и функциональность. И да, время от времени он будет глючить так, что дилерский сервис разведет руками.

Но если вам нужен надежный трактор для определенной задачи, вы все еще можете купить карбюраторный экземпляр с простой механической начинкой (читай: OpenRC). Просто не ждите от него функций автопилота и парковочных ассистентов.

Жду ваших воинственных и не очень историй. Особенно про те случаи, когда systemctl restart спасал (или губил) ваш день.