Что такое systemd в линукс

systemd (Русский)

systemd — набор базовых строительных кирпичиков Linux-системы. Представляет собой менеджер системы и служб, который выполняется как процесс с PID 1 и запускает остальную часть системы. systemd обеспечивает возможности агрессивной параллелизации, сокетную и D-Bus активацию для запуска служб, запуск демонов по запросу, отслеживание процессов с помощью контрольных групп Linux, обслуживание точек (авто)монтирования, а также предлагает развитую транзакционную логику управления службами на основе зависимостей. systemd поддерживает сценарии инициализации SysV и LSB и работает как замена sysvinit. Среди прочих элементов и функций — демон журнала, утилиты управления базовой конфигурацией системы (имя хоста, дата, языковой стандарт), ведение списков вошедших в систему пользователей, запущенных контейнеров, виртуальных машин, системных учётных записей, каталогов и настроек времени выполнения, а также демоны для управления несложными сетевыми конфигурациями, синхронизации времени по сети, пересылки журналов и разрешения имён.

Contents

Основы использования systemctl

Использование юнитов

Юнитами могут быть, например, службы (.service), точки монтирования (.mount), устройства (.device) или сокеты (.socket).

Управление питанием

Для управления питанием от имени непривилегированного пользователя необходим polkit. Если вы находитесь в локальном пользовательском сеансе systemd-logind и нет других активных сеансов, приведенные ниже команды сработают, даже если будут выполнены не от root. В противном случае (например, другой пользователь вошел в систему через tty) systemd автоматически запросит у вас пароль суперпользователя.

Написание файлов юнитов

Обработка зависимостей

Зависимости обычно указываются для служб, но не для целей. Так, цель network.target будет «подтянута» ещё на этапе настройки сетевых интерфейсов одной из соответствующих служб, и можно спокойно указывать эту цель как зависимость в пользовательской службе, поскольку network.target будет запущена в любом случае.

Типы служб

Службы различаются по типу запуска, и это следует учитывать при написании юнитов. Тип определяется параметром Type= в разделе [Service] :

Редактирование файлов юнитов

Замещение файла юнита

Эта команда откроет файл /etc/systemd/system/юнит в текстовом редакторе (если файл ещё не существует, будет скопирован оригинал) и автоматически перезагрузит юнит после завершения редактирования.

Drop-in файлы

Самый простой способ — использовать команду:

Команда откроет /etc/systemd/system/юнит.d/override.conf в текстовом редакторе (файл будет создан, если его ещё нет) и автоматически перезапустит юнит после завершения редактирования.

Откат изменений

Примеры

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

Другой пример: для замены ExecStart в юните (кроме типа oneshot ) создайте следующий файл:

Обратите внимание, что ExecStart необходимо очистить перед присвоением нового значения [1]. Это относится ко всем параметрам, которые позволяют прописать несколько значений, вроде OnCalendar в таймерах.

Пример настройки автоматического перезапуска службы:

Получение информации о текущих целях

В systemd для этого предназначена следующая команда (заменяющая runlevel ):

Создание пользовательской цели

Соответствие уровней SysV целям systemd

Изменение текущей цели

В systemd цели доступны посредством целевых юнитов. Вы можете переключать их такой командой:

Изменение цели загрузки по умолчанию

Узнать текущую цель можно так:

Альтернативный способ — добавить один из следующих параметров ядра в загрузчик:

Порядок выбора цели по умолчанию

systemd выбирает default.target в следующем порядке :

Компоненты systemd

Некоторые (не все) составные части systemd:

systemd.mount — монтирование

Примером этих опций может быть т.н. автомонтирование (здесь имеется в виду не автоматическое монтирование во время загрузки, а монтирование при появлении запроса от устройства). Подробнее смотрите fstab#Автоматическое монтирование с systemd.

Автомонтирование GPT-раздела

На UEFI-системах systemd-gpt-auto-generator(8) автоматически монтирует GPT-разделы в соответствии с Discoverable Partitions Specification, поэтому их можно не указывать в файле fstab.

Для автомонтирования раздела /var его PARTUUID должен совпадать с хэш-суммой SHA256 HMAC, вычисленной на основании UUID типа раздела. В качестве ключа хэша используется machine ID. Необходимый PARTUUID можно получить командой:

systemd-sysvcompat

systemd-tmpfiles — временные файлы

Советы и рекомендации

Программы настройки с графическим интерфейсом

Запуск сервисов после подключения к сети

Чтобы запустить сервис только после подключения к сети, добавьте такие зависимости в .service файле:

Также должна быть включена служба ожидания сети того приложения, которое управляет сетью; только тогда network-online.target будет соответствовать состоянию сети.

Подробнее можно почитать в systemd wiki: Running services after the network is up.

Если служба отправляет DNS-запросы, она должна запускаться также после nss-lookup.target :

Чтобы цель nss-lookup.target работала как положено, должна быть служба, которая запускает её параметром Wants=nss-lookup.target и размещает себя перед ней ( Before=nss-lookup.target ). Обычно это выполняет локальный DNS-распознаватель.

Включение установленных юнитов по умолчанию

This article or section needs expansion.

Песочница для приложений

Рекомендации по созданию песочницы с помощью systemd:

Уведомление о неработающих службах

Создайте drop-in верхнего уровня:

Это добавит строку OnFailure=failure-notification@%n в файл каждой службы. Если какой-то_юнит завершится с ошибкой, запустится экземпляр службы failure-notification@какой-то_юнит для создания уведомления (или любой другой задачи, которая была назначена).

Создайте юнит-шаблон failure-notification@ :

Решение проблем

Неудачно запущенные службы

Следующая команда найдёт все службы, которые не смогли выполнить запуск:

Чтобы определить причину, по которой служба не запустилась, необходимо изучить записи её логов. Подробнее см. systemd/Журнал#Фильтрация вывода.

Диагностика загрузки системы

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

Диагностика службы

Добавьте drop-in файл для службы:

Или, как вариант, пропишите переменную окружения вручную:

Выключение/перезагрузка происходят ужасно долго

Если процесс выключения занимает очень долгое время (или выглядит зависшим), то, вероятно, виновата служба, которая не может завершить свою работу. Systemd ожидает некоторое время, пока каждая служба прекратит работу самостоятельно, и только потом пробует завершить её принудительно. Если вы столкнулись с такой проблемой, обратитесь к Shutdown completes eventually в systemd-вики.

По-видимому, процессы с кратким сроком жизни не оставляют записей в логах

Время загрузки системы увеличивается с течением времени

После использования systemd-analyze некоторые пользователи заметили, что время загрузки системы значительно увеличилось. После использования systemd-analyze blame NetworkManager запускался необычно долго.

systemd-tmpfiles-setup.service не запускается во время загрузки

Начиная с версии Systemd 219, /usr/lib/tmpfiles.d/systemd.conf определяет ACL-атрибуты для каталогов в /var/log/journal и, следовательно, требует включённой поддержки ACL для той файловой системы, в которой находится журнал.

Отключение emergency mode на удалённой машине

Вам может понадобиться отключить emergency mode на удалённой машине, например на виртуальных машинах Azure или Google Cloud. Это связано с тем, что в случае ухода системы в emergency mode она отключится от сети и лишит вас возможности подключения к ней.

Источник

Systemd за пять минут

Наша компания занимается администрированием веб-серверов на базе CentOS. Довольно часто наши клиенты используют веб-приложения на базе python, ruby или java. Для автозапуска подобных приложений есть готовые шаблоны для написания стартап-скриптов. Но прогресс не стоит на месте, вышел уже второй релиз CentOS 7 и, следуя старой традиции «не ставить dot-zero релизы на продакшен», мы начинаем предлагать клиентам сервера на базе CentOS 7.1 (1503).

В CentOS7, так же как и в его родителе RHEL7, используется systemd — менеджер системы и служб для Linux, совместимый со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации и много всего прочего.

Огромный монстр с множеством возможностей, гибкими настройками и мегабайтами документации…

Но что делать, если стоит задача быстро-быстро, вот прямо вчера, сделать автозапуск некоего сервиса?
Давайте выжмем из документации минимально необходимый набор информации для создания простых старт-стоп скриптов.

Systemd запускает сервисы описанные в его конфигурации.
Конфигурация состоит из множества файлов, которые по-модному называют юнитами.

Все эти юниты разложены в трех каталогах:

/usr/lib/systemd/system/ – юниты из установленных пакетов RPM — всякие nginx, apache, mysql и прочее
/run/systemd/system/ — юниты, созданные в рантайме — тоже, наверное, нужная штука
/etc/systemd/system/ — юниты, созданные системным администратором — а вот сюда мы и положим свой юнит.

[Название секции в квадратных скобках]
имя_переменной = значение

Для создания простейшего юнита надо описать три секции: [Unit], [Service], [Install]

В секции Unit описываем, что это за юнит:
Названия переменных достаточно говорящие:

Далее следует блок переменных, которые влияют на порядок загрузки сервисов:

Запускать юнит после какого-либо сервиса или группы сервисов (например network.target):

After=syslog.target
After=network.target
After=nginx.service
After=mysql.service

В итоге переменная Wants получается чисто описательной.
Если сервис есть в Requires, но нет в After, то наш сервис будет запущен параллельно с требуемым сервисом, а не после успешной загрузки требуемого сервиса

В секции Service указываем какими командами и под каким пользователем надо запускать сервис:

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

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

Также следует определить PIDFile=, чтобы systemd могла отслеживать основной процесс:

Команды на старт/стоп и релоад сервиса

Тут есть тонкость — systemd настаивает, чтобы команда указывала на конкретный исполняемый файл. Надо указывать полный путь.

Таймаут в секундах, сколько ждать system отработки старт/стоп команд.

Попросим systemd автоматически рестартовать наш сервис, если он вдруг перестанет работать.
Контроль ведется по наличию процесса из PID файла

В секции [Install] опишем, в каком уровне запуска должен стартовать сервис

multi-user.target или runlevel3.target соответствует нашему привычному runlevel=3 «Многопользовательский режим без графики. Пользователи, как правило, входят в систему при помощи множества консолей или через сеть»

Вот и готов простейший стартап скрипт, он же unit для systemd:
myunit.service

Кладем этот файл в каталог /etc/systemd/system/

Смотрим его статус systemctl status myunit

Если нет никаких ошибок в юните — то вывод будет вот такой:

Источник

systemd десять лет спустя. Историческая и техническая ретроспектива

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

Это пост не совсем о том, как пользоваться systemd. Тут, скорее, будет говориться об истории его возникновения, о его компонентах в целом, и о том, как понять систему, которая начиналось как просто PID 1 и стала тем, что я бы назвал middleware современного дистрибутива Linux.

А может, это просто набор крайне вольных переводов различных материалов с блогов, каналов и статей на Arch wiki. Вам решать.

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

Но прежде чем начать речь о systemd, хочу рассказать об init.

В седьмом издании UNIX (1979) задача init — это выполнить при старте /etc/rc и создавать процессы инициализации терминала (getty) и логина (login).

Затем постепенно добавлялись новые задачи. Например, перехват ничейных процессов. Или очистка каталога /tmp. Или монтирование файловых систем.

Так, сегодня основная задача init — привести систему из состояния «ядро запущено» к «система готова к работе». Запустить userspace, другими словами.

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

И /etc/rc со скриптами, конечно, могут запустить всё, что нужно, но что, если, скажем, надо просто перезапустить какой-то демон? Вышедший в 1983-м UNIX System V, который ввёл понятие runlevel, или уровень выполнения, частично решал эту проблему и позволял таким образом управлять целыми группами демонов.

Linux перенял у UNIX интерфейс инициализации (sysvinit), и в целом, всех всё устраивало, но тем не менее, были пользователи, которых sysvinit стеснял. Так, Matthias S. Brinkmann однажды написал в своём блоге заметку «Почему sysvinit — отстой». Оригинал удалён, поскольку, по мнению Матьяса «sysvinit уже мёртв», но вольно переведу вкратце найденную в интернете перепечатку:

Подытоживая, sysvinit был разработан больше 30 лет назад со старыми концепциями, которые уже не решали задачи XXI века. Мало того, система не развивалась и не вводила новые идеи.

В атмосфере беспорядочного хаоса было предприняты несколько попыток решить проблемы sysvinit:

Upstart

Часть проблем sysvinit вызвался решить Upstart (также известный как ReplacementInit), альтернативная система инициализации, выпущенная в 2006-м году Canonical, разработчиками Ubuntu. Его главная концепция — event-driven подход. Запуск системы — это событие, новое устройство — событие, запуск демона — событие. Процессы могли подписываться на события и запускаться только при явной необходимости.

Upstart совместим с sysvinit-скриптами, благодаря этому он был быстро интегрирован во многие дистрибутивы Linux. Тем не менее, после того, как большинство дистрибутивов Linux по тем или иным причинам перешли на systemd, разработка сошла на нет: последний релиз был в 2014-м году, и сегодня Upstart используется только в Chrome OS.

Новый init

«we are experimenting with a new init system and it is fun»

Весной 2010 года в блоге Леннарта Поттеринга вышел материал Rethinking PID 1, в которой он описал своё видение эффективной системы инициализации.

По его мнению, эффективный init должен обладать следующими характеристиками:

Другая идея, которую можно почерпнуть из процесса загрузки macOS: shell-скрипты — это зло. Их легко написать, но трудно поддерживать, и они медленно выполняются: каждый вызов grep/awk/sed/cut в одном скрипте — это запуск процесса, подгрузка его библиотек, операции типа локализации вывода, и так далее. И так с каждым init-скриптом. В контексте запуска системы выполнение множества консольных команд тормозит весь процесс.

«Так давайте избавимся от shell-скриптов в загрузке!» — воскликнул Леннарт. «Большая часть init-скриптинга сводится к тривиальному запуску-остановке демонов, и эту логику можно переписать на C и поместить или в отдельные исполняемые файлы, или в сами демоны, или просто в init».

Другие возможности, которыми должен обладать хороший, по мнению Поттеринга, PID 1:

Почему бы просто не добавить всё это в Upstart, зачем изобретать по-новому? Или почему бы не портировать launchd? Ответ прост — на взгляд Леннарта, у Upstart, несмотря на event-driven подход, есть недостатки в архитектуре и дизайне. А launchd вряд ли хорошо прижился бы в Linux.

systemd

Анонсированный в Rethinking PID 1 прототип systemd, ранее известный как «BabyKit» (от process babysitter — нянька процессов), быстро получил доминирующий статус благодаря своей лёгкости.

Сегодня на странице проекта говорится уже не про PID 1, а про комплект базовых блоков для системы Linux.

Что под этим скрывается? systemd теперь называется конструктор из компонентов, каждый из которых отвечает за свою задачу, связанную с сервисами или системой в целом.

systemd — это система управления системой. Он берёт и объединяет в системный слой подсистемы, которые, с одной стороны, не забота ядра, а с другой — пользователю они редко интересны.

Восход к власти

Разработчики systemd не теряли времени на проповедование. Несмотря на пятна от помидоров в списке рассылки fedora-devel, systemd в июле 2010 года стал стандартом инициализации в Fedora Rawhide.

В обсуждениях разработки Fedora, связанных с systemd, Леннарт занимал боевую позицию, особенно в вопросах обратной совместимости: так, отвечая на беспокойства Мэтью Миллера касательно совместимости с inittab, он спрашивал: «Может, мы должны проверять ещё и AUTOEXEC.BAT?… Да, давайте снова вернёмся к теме inittab. Это было так весело!». Когда его спросили про необходимости исправлять пакеты из-за нововведений systemd, он ответил: «Круто, полагаю, теперь я стану разработчиком X (X-сервера).

Вероятно, если KMS сломан, мой долг — исправить это. Ура!»

Всё обсуждение демонстрировало в чём-то инфантильный недостаток внимания Леннарта к ситуации, в которой многие пакеты и подсистемы перед релизом Fedora 14 нужно было подготовить к работе с systemd. Естественно, эта мыльная опера появилась на LWN.

Как бы то ни было, амбиций у Леннарта было полно. В июле 2010 он был уверен, что дистрибутивы возьмут к себе systemd:

7) Перейдут ли другие дистрибутивы на systemd?
Ну, не так быстро, как Fedora, но похоже на то.

А в сентябре 2010 он чётко заявил кросс-дистрибутивную интеграцию как одну из целей systemd:

В августе 2012 года Arch Linux переключился на systemd, хоть и с небольшой драмой.

Немного позже, в октябре того же года, благодаря упорству Леннарта, GNOME перешёл на systemd-logind. В октябре 2019 вышел GNOME 3.34 полностью интегрированный с systemd.

На момент 2013 и 2014 годов Debian и Ubuntu были последними, среди ведущих дистрибутивов, не принявших systemd.

Josselin Mouette в октябре 2013, будучи мейнтейнером пакета GNOME в Debian, заявил в списке рассылки Debian следующее:

systemd становится де-факто стандартом в дистрибутивах Linux (по крайней мере в Fedora, SuSE и Arch) и получает превосходную поддержку во множестве пакетов. До сих пор только Gentoo использует OpenRC, и только Ubuntu использует Upstart. Поэтому использование OpenRC бы означало необходимость в поддержке множества собственных патчей, а использование Upstart бы значило, что мы становимся апстримом Ubuntu.

… Завершая, я скажу как мейнтейнер пакета GNOME. GNOME-у в Jessie понадобится systemd как система инициализации для работы всего функционала так же, как ему требуется NetworkManager для работы конфигурирования сети.

Более того, в декабре 2013, в изложении ситуации с init в Debian за авторством Расса Олбери, в разделе «3.1. Реальность экосистемы», сказал, что разговор идёт уже не о «systemd-против-альтернатив», а о «как-много-будет-systemd»:

Одним из опущенных в процессе обсуждения моментов, который было бы важно подчеркнуть, заключается в том, что все в целом согласны, что Debian примет части systemd. Systemd — это всеобъемлющий проект, включающий в себя множество компонентов, и некоторые из них более значимы, чем другие. Большинство этих частей явно превосходят всё, что мы имеем сейчас на платформе Linux, и они будут использоваться далее в дистрибутиве.

Другими словами, это дебат не о systemd против upstart в обычном смысле. Вопрос, скорее, в том, принимаем ли мы systemd со всеми его составляющими, включая систему инициализации, или же мы берём его подсистемы, но в качестве системы инициализации выбираем upstart. В любом случае, будет работать udev, logind, timedated и другие службы.

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

Это и произошло. Debian Jessie вышла с systemd в качестве менеджера системы, и вслед за Debian systemd был включён в Ubuntu 15.04.

По правда говоря, это пост не о войнах systemd. Если хотите почитать ещё, но лень копаться в списках рассылки, то держите чей-то материал, который отчасти вдохновил меня на этот пост.

Компоненты systemd

System manager

systemd как менеджер системы вводит в систему множество концепций, и основная — это юнит. Юнит является абстрактной сущностью, которая содержит имя, описание и те или иные завимости.

На момент systemd 234 юниты делятся на 13 типов, вкратце:

journald

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

История journald: syslog

Долгое время важным компонентом любого дистрибутива Linux был демон syslog. На протяжении истории было сделано множество реализаций интерфейса syslog, но в целом они были реализованы схожим образом и использовали почти один формат данных на файловой системе.

Целью демона syslog является, как понятно из названия, логирование процессов системы. Демон получает от приложений и сервисов сообщения в относительно свободной форме и сохраняет их на диске. Как правило, единственные метаданные сообщения — это facility (примеры: ядро, почта, сеть, и т.д.) и приоритет, а также timestamp, тег процесса и его PID. Большинство этих полей опционально, и точный синтаксис варьируется от реализации к реализации.

syslog не принуждает заполнять все поля, что делает его лёгким в использовании и в то же время мощным в плане расширяемости. В то же время, это его изъян — syslog имеет на руках некоторый беспорядок без строгого формата, и такой результат трудно парсить.

Система syslog уже 30 лет (на момент появления journald), благодаря своей простоте, является незаменимым инструментом администраторов. Однако число ограничений солидно, и со временем они стали заметными проблемами:

О journald

Базовая интеграция с journald элементарна: процессу достаточно писать в stdout/stderr, а дальше подсистема сама разберётся, какой это сервис, сессия пользователя, исполняемая команда и прочие атрибуты.

Для более тесной интеграции понадобится использовать библиотеки: так, например, для Python есть модуль pystemd.journal библиотеки pystemd.

Подробнее про то, как работать с journald, можно узнать из поста Selectel и в man journalctl.

Документ за авторством Леннарта с описанием journald и его тонкостей можно почитать тут.

machined

systemd-machined — часть systemd-nspawn, платформы контейнеров systemd. По концепции контейнеры systemd далеки от, скажем, Docker: когда как Docker — прежде всего, платформа stateless контейнеров, systemd-nspawn является просто способом запустить systemd в stateful контейнере. nspawn гораздо проще Docker: тут нет REST API, нет labels, нет управления сетями, volume и прочим. С одной стороны, это минус контейнеров systemd, с другой — они подойдут тем, кто привык настраивать сеть и окружение самостоятельно.

Главное преимущество systemd-nspawn — это тесная интеграция с экосистемой systemd. Для каждого контейнера создаётся слайс и сервис, ресурсы можно настроить через systemctl set-property, и внутри контейнера systemd работает без проблем.

Подробнее о systemd-nspawn можно почитать на Arch wiki или в посте Selectel.

Другие известные компоненты

Мифы о systemd

Если вы соберёте systemd, то получите на выходе 98 индивидуальных бинарных файлов (если не включать все конфигурационные опции). К примеру, systemd спроектирован со вниманием к безопасности, поэтому каждый из компонентов запускается с минимальными требуемыми правами и делает лишь свою задачу.

Комплект из почти сотни бинарников назвать монолитным непросто. Впрочем, все релизы systemd распространяются в едином tar-архиве и находятся в одном git-репозитории с единым циклом выпуска.

Нонсенс. Платформа systemd, на самом деле, гораздо проще традиционного Linux, потому что она объединяет системные объекты и их зависимости в юнитах с простым синтаксисом конфигурационных файлов. Также, у systemd есть вполне исчерпывающая документация о почти каждой детали systemd, в том числе и об API для разработчиков.

Конечно, у systemd есть кривая обучения. Она есть у любого софта. Но systemd всё равно остаётся проще больших shell-скриптов, да и проще синтаксиса shell в целом.

В целом, systemd, возможно, настолько прост, насколько системный менеджер может быть простым.

systemd — продукт синдрома «not invented here»

Это неправда. До того, как приступить к systemd, Поттеринг продвигал Upstart, впрочем, потом он пришёл к заключению, что дизайн Upstart неидеален: вместо того, чтобы самой решать проблему зависимостей, система оставляла это администратору. Но это лишь одна из причин.

systemd — это не UNIX

В этом есть некоторая правда: в исходных кодах systemd нет ни одной строки из UNIX. Но разработчики черпают вдохновение из UNIX, взгляните на те же десятки файлов, каждый из которых делает свою задачу. Кроме того, способ ведения проекта (т.е. развитие в одном git-репозитории) во многом похож на модель BSD (который настоящий UNIX, в отличии от Linux).

Вообще, UNIX для каждого значит своё. Для Леннарта Поттеринга и других разработчиков это источник вдохновения, а для кого-то это религия, и, как и у других мировых религий, есть разные трактовки и понимания UNIX: под ним можно понимать стиль кода, набор команд и API, а кто-то считает, что UNIX — это набор логик и поведений.

Конечно, сделать всех этих людей счастливыми просто невозможно.

systemd раздут, это зоопарк разных фич и изменения ради изменений.

systemd наверняка покрывает больше задач, чем должен был. Это давно не просто система инициализации, это система для построения операционной системы.

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

Таким образом, пользователи могут выбирать тот уровень «раздутости» и набор фич, который им необходим.

Кстати, собирается systemd на удивление быстро: на моём i7-8550U сборка ядра v245 заняла 43 секунды.

systemd нестабилен и забагован

Вовсе нет. Мейнтейнеры, по мнению Леннарта, внимательно относятся к issues на GitHub, мониторят багтрекеры дистрибутивов Linux и, надо сказать, число багов довольно мало для такого ключевого компонента ОС.

Разработчики вполне справляются с блокирующими разработку и использование багами, также помогает относительно быстрый цикл разработки с инкрементальными нововведениями с целью качества и стабильности.

Использование systemd dbus-а вместо сокетов делает его интерфейс непрозрачным

Это утверждение противоречит себе: dbus — это просто стандарт сериализации сообщений поверх обычных сокетов. Формат сообщений документирован и понятен, и к dbus есть множество библиотек для разных языков.

В отличии от различных классических UNIX-демонов, у каждого из которых свои протоколы и форматы.

Я перевёл лишь самую, на мой взгляд, интересную часть мифов. Остальные можете почитать здесь.

В заключение

Сегодня systemd — это больше, чем PID 1: это прослойка между kernel space и приложениями, которая обладает всем, что может понадобиться для работы дистрибутива Linux:

Источник