[Перевод] Трагедия systemd
Согласно Википедии, трагедия — это «форма драмы, основанная на человеческих страданиях, которая вызывает в аудитории сопутствующий катарсис или удовольствие». Из этого определения почерпнул вдохновение Бенно Райс в своём выступлении на конференции 2019 linux.conf.au. Его доклад посвящён истории systemd, в которой немало страданий. А аудитория точно получила удовольствие, так что всё сходится. В целом, это сочувственный и тонкий взгляд на одну бурную главу в истории системы Linux.
Райса также вдохновила статья Ауринна Шоу о так называемой «культуре презрения». По словам Шоу, люди проявляют презрение (например, к разработчикам, которые используют другой язык программирования) в качестве социального знака, способа показать, что они принадлежат к правильной группе.
Безусловно, в этой истории есть такая культура: большие группы сообща проявляют общее презрения к systemd и к тем, кто использует эту систему. Отсюда вытекает концепция изменения или сопротивления. Да, знакомые вещи удобны. Но они не обязательно хороши, особенно если ничего не меняется уже много лет.
По словам Райса, происхождение systemd связано с корнями самой системы Unix, которая была «счастливой случайностью» — реакцией на внешнюю сложность прежних систем. Unix был кардинально упрощён во всех отношениях, включая загрузку пользовательского пространства. Подсистема init заведовала всем «хозяйством», включая монтирование файловых систем и запуск демонов. Хотя это совершенно разные задачи, но их объединили в один процесс.
В те дни важных демонов было мало: cron, update (чья работа заключалась в том, чтобы иногда выписывать суперблоки файловой системы), и сам процесс init. К моменту выхода 4BSD у Unix и появился правильный демон getty, сетевые демоны вроде routed и telnetd, а также «супердемон» inetd. Именно здесь ситуация начала становиться интересной, но некоторое время всё это работало достаточно хорошо.
А потом случился Интернет. Хотя inetd нормально справлялся с небольшими объёмами трафика, но не мог создавать новый процесс на каждое входящее соединение. Тем временем веб-сайты обзавелись базами данных и другими системами с сохранением состояния между соединениями. Представление о демоне сместилось в сторону «сервиса», а это совсем другой зверь. Старый init мог только запустить сервис, но после этого становился практически бесполезен.
Частично проблема заключалась в объединении сервисов и конфигурации. Такие задачи, как монтирование файловых систем, относятся к последней разновидности; они обычно выполняются один раз во время загрузки, после чего забываются. Но такого подхода недостаточно для автоматизированного управления сервисами, которое требует постоянного внимания. Вот так на свет появились сервис-ориентированные системы, такие как Upstart и systemd. Здесь Unix пошла по пути, проторенному другими ОС. По словам Райса, у Windows NT с самого начала была сильная сервисная модель, а у Mac OS она до сих пор работает в виде launchd. Другим системам приходилось догонять.
Apple выпустила launchd в версии Tiger, где он заменил целую серию демонов обработки событий, включая init, cron и inetd. Таким образом, systemd стал попыткой позаимствовать хорошие идеи, реализованные в launchd. Когда Леннарт Пёттеринг начал решать эту проблему, он сначала посмотрел в сторону Upstart — системы, основанной на событиях. Она ещё работала на скриптах, но Пёттеринг пришёл к выводу, что сможет сделать лучше. В своей статье Rethinking PID 1 он называет launchd одним из образцов для работы. Он думал о повышении скорости загрузки и необходимости настройки системы инициализации на аппаратные и программные изменения в работающей системе. Во время создания init системы были статичными, но современная среда гораздо динамичнее, чем тогда.
Классические Unix-подобные системы делятся на два основных компонента: ядро и пользовательское пространство. Но ядра со временем стали более динамичными и изменчивыми, подстраиваясь под оборудование, на котором они работают. Это привело к необходимости создания нового «сервисного слоя» (service layer) между ядром и пользовательским пространством. Этот слой включает в себя компоненты вроде udev и Network Manager, но systemd стремится обеспечить комплексный сервисный уровень; именно поэтому со временем он вбирал в себя функциональность таких компонентов как udev. Процесс шёл довольно успешно и был принят большинством (но не всеми) дистрибутивами Linux, хотя часто сопровождался язвительностью со стороны сообщества.
Против демона systemd часто звучат одни и те же аргументы: например, что он нарушает философию Unix. Райс предполагает, что этот аргумент основан на понятии, что systemd представляет собой единый монолитный двоичный файл. На самом деле systemd структурирован иначе: это много отдельных двоичных файлов, поддерживаемых в рамках одного проекта. Как «человек BSD» (он входил в число основных разработчиков FreeBSD), Райс находит смысл в таком объединении смежных концепций. Systemd — вовсе не раздутая и монолитная система, как считают некоторые критики.
Говорят, что в systemd много багов. «Это же софт», конечно, в нём будут баги, сказал Райс. Представление о том, что в отличие от любой другой системы systemd должен быть совершенным, поднимает планку слишком высоко. По крайней мере, у systemd практически всегда разумный режим работы при отказе, сказал он.
В той или иной форме часто повторяется одна жалоба, которую можно сформулировать так: «Не выношу Леннарта Пёттеринга». Райс отказалась защищать стиль общения Пёттеринга, но сказал, что нельзя не восхититься силой воли и решимостью Пёттеринга. Не каждый сможет пройти через всё это.
Systemd не стремится к портируемости на системы, отличные от Linux, что приводит к отдельному классу жалоб. Если systemd станет стандартом, существует риск того, что операционные системы за пределами Linux станут ещё более изолированными. Многие хотят, чтобы systemd придерживался стандартных для Unix интерфейсов, но у Райса для них простой ответ: «Unix мёртв». Когда-то Unix был упражнением в предельной переносимости и имел реальный успех. Но теперь мы живём «в мире Linux с небольшими ошибками округления» (что человеку от FreeBSD больно говорить), и нет смысла придерживаться классических интерфейсов Unix. Нынешняя ситуация является «патологической монокультурой», где Linux может диктовать условия.
Systemd много выиграл в такой ситуации. Например, контрольные группы — высокоэффективный и интересный механизм управления процессами, без них было бы гораздо труднее решать эти задачи. Они гораздо более мощные и детальные, чем джейлы FreeBSD. Разработчики систем типа FreeBSD могут видеть угрозу в непереносимости systemd. Но эта ситуация также даёт им возможность свободно работать и искать собственные решения этих проблем.
Райс говорит, что миссия systemd сводится к большим разрушительным изменениям — вот где начинается трагедия. У нас нердов сложное отношение к изменениям. Да, это потрясающе, когда мы сами их создаём, но изменениям нельзя доверять, если они приходят извне. Systemd представляет тот вид внешне навязанных изменений, который люди находят угрожающим. Люди противятся таким изменениям даже от приятных разработчиков, не говоря уже о Пёттеринге, который не особо сочувствует окружающим. Это приводит к рефлекторным реакциям. Но людям нужно отступить и подумать, что они делают. «Никто не должен угрожать Леннарту смертью из-за какого-то программного обеспечения», — говорит Райс. Презрение — это не круто.
Вместо этого стоит подумать: почему вообще появился systemd и почему это важно? Какую проблему он решает? Для критиков одним из решением может быть попытка создать собственную альтернативу: они поймут, насколько весёлая эта задача. Кроме всего прочего, эта история показывает разницу в мышлении у нового поколения, которое рассуждает о системах больше с точки зрения API и контейнеров, например.
Итак, какие выводы можно сделать из истории systemd? Один из выводов: нельзя недооценивать транспорт сообщений. Systemd интенсивно использует шину D-Bus, которая во многом обеспечивает его гибкость. Райс не сторонник D-Bus, но большой сторонник шин для обмена сообщениями между процессами. В своё время он лоббировал создание такой нативной шины в BSD-системах, желательно встроенной в ядро и с лучшей безопасностью, чем у D-Bus. Поверх неё можно сделать надлежащую систему удалённого вызова процедур, где компоненты ядра и пользовательское пространство будут работать на одном уровне. В правильно спроектированной системе процесс просто отправит запрос API, не беспокоясь о том, где и как этот запрос будет обработан.
Среди прочих уроков — важность поддержки надлежащего жизненного цикла службы без необходимости установки дополнительных систем управления службами. Важно наладить автоматизацию обслуживания через API; и systemd обеспечивает многое из этого. Поддержка контейнеров также важна: это полезный способ инкапсуляции приложений.
Итак, в современных Linux-системах systemd выполняет роль сервисного слоя. Это хорошая платформа для управления службами, но она не должна быть единственной альтернативой. В systemd есть ряд полезных функций, включая удобные пользовательские юниты, последовательное именование устройств и даже хорошую модель журналирования, сказал Райс. Двоичные журналы — неплохая вещь, пока у вас есть инструменты, чтобы вытащить оттуда информацию. И systemd предоставляет новую модель приложения. Вместо одного двоичного файла приложение становится кучей модулей в одном контейнере.
Мир вокруг нас меняется, сказал Райс. Мы можем либо отдаться течению, либо сопротивляться ему. В первом случае, вероятно, плыть будет проще, чем во втором. Райс предложил всем, кто критикует systemd, более пристально изучить эту систему и попытался найти в ней хорошие вещи. Возможно, тогда завершится фаза катарсиса нашей трагедии — и мы сможем двигаться дальше.
Видеозапись выступления опубликована на YouTube.
