После трёх месяцев разработки опубликован релиз системного менеджера systemd 260. Это крупное обновление, в котором не только добавлены новые возможности, но и окончательно прекращена поддержка ряда устаревших механизмов.
Главное изменение: отказ от скриптов SysV
Одним из самых принципиальных решений в systemd 260 стало окончательное прекращение поддержки сервисных скриптов в формате System V. Поддержка классических `/etc/init.d/*` много лет считалась временным "мостом" для старого софта, и теперь этот мост демонтирован.
Это означает:
- сервисы должны описываться через unit-файлы systemd (`.service`, `.socket`, `.timer` и т.д.);
- устаревшие скрипты SysV больше не запускаются и не рассматриваются как валидный способ описания служб;
- дистрибутивам и администраторам, которые до сих пор полагались на старые init-скрипты, придётся мигрировать на нативные юниты systemd.
Фактически разработчики зафиксировали давно назревшую реальность: подавляющее большинство активно поддерживаемого софта уже имеет юниты systemd, а "зоопарк" старых скриптов создавал лишнюю нагрузку и усложнял сопровождение.
Новый механизм mstack: многослойные иерархии монтирования
Одно из наиболее технически интересных новшеств - механизм `mstack`, предназначенный для компоновки многослойных иерархий монтирования. Он позволяет гибко описывать сложные файловые окружения, в частности на базе `overlayfs`.
Пример конфигурации `foobar.mstack/`:
- объявляется overlayfs с двумя базовыми слоями в режиме "только чтение";
- в качестве источников следует указать дисковые образы `base.raw` и `app.raw`, представленные в системе через символические ссылки;
- поверх этих слоёв добавляется каталог `rw`, который монтируется с возможностью записи.
Таким образом администратор получает удобный способ собрать из нескольких образов и слоёв единое файловое пространство: базовая система, слой приложения и отдельный слой для записываемых данных. Это особенно полезно для контейнеров, изолированных окружений, тестовых стендов и переносимых сервисов.
Утилита systemd-report
В состав релиза вошла новая утилита `systemd-report`. Она предназначена для:
- сбора диагностической информации о системе и службах;
- формирования отчётов, которые можно использовать при отладке, анализе сбоев и обращениях к разработчикам или мейнтейнерам;
- стандартизированного представления сведений о версиях компонентов, конфигурации и состоянии служб.
Тем самым закрывается частая практическая проблема: каждый администратор по-своему "допрашивает" систему набором разрозненных команд. `systemd-report` унифицирует этот процесс и уменьшает риск того, что важные детали будут упущены.
Интеграция systemd-networkd с ModemManager
В systemd 260 расширены сетевые возможности: `systemd-networkd` научился интегрироваться с ModemManager. Это даёт:
- более удобную работу с мобильными модемами и сотовыми подключениями;
- возможность использовать единый стек управления сетью через systemd, не раскладывая логику по нескольким несовязанным инструментам;
- лучшую автоматизацию сценариев, где задействованы мобильные каналы связи (резервирование, временные каналы, удалённый доступ).
Для систем, которые активно используют LTE/5G-модемы, это уменьшает сложность настройки и упрощает сопровождение.
Пользовательские переносимые сервисы
Ещё одно направление развития - поддержка пользовательских переносимых сервисов (portable services) не только на системном, но и на пользовательском уровне.
Теперь:
- переносимый сервис можно запускать не только от имени root, но и в контексте конкретного пользователя;
- появляются дополнительные сценарии: изолированные пользовательские приложения, тестовые окружения разработчика, единые образы сервисов, не привязанные жёстко к конкретной машине;
- администраторы и разработчики получают более гибкий механизм развёртывания: образ сервиса можно переносить между машинами, сохраняя предсказуемое окружение и поведение.
Это логичное развитие концепции "сервис как артефакт", где всё, что нужно для работы, упаковано и готово к развёртыванию без ручной сборки окружения.
Концепция "xaccess" в systemd-logind и systemd-udevd
В системе управления сессиями и устройствами появились новые элементы - концепция "xaccess" в `systemd-logind` и `systemd-udevd`.
Она направлена на более тонкий контроль доступа и взаимодействия:
- можно точнее регулировать, какие процессы и пользователи имеют доступ к тем или иным устройствам и ресурсам;
- усиливается безопасность многопользовательских систем;
- поведение становится более предсказуемым: меньше "магии", когда доступ даётся или отбирается неявно.
Для администраторов это означает дополнительный уровень настроек, позволяющий сделать систему строже без глобальных ограничений для всех.
Не просто init: почему вокруг systemd так много споров
Контекст релиза - не только технический, но и идеологический. Systemd изначально позиционируется не как "ещё один init", а как полноценный System and Service Manager, который берет на себя:
- управление сервисами с учётом зависимостей, параллельный старт, рестарт, контроль состояний;
- централизованный сбор и управление логами;
- управление сетью, временными зонами, устройствами, сессиями пользователей;
- поддержку cgroups, изоляцию, ресурсы, лимиты и политики.
Сторонники классических init-систем утверждают, что "всё и так работает, быстро и стабильно, как 10-20 лет назад". Но при этом, чтобы добиться сопоставимого набора функций, приходится собирать набор разнородных инструментов, каждый со своим конфигом, логикой и интеграцией. Именно это часто превращается в тот самый "зоопарк", который тяжело поддерживать.
Цена обратной совместимости и "вечной поддержки"
Один из самых болезненных аспектов - отказ от старых механизмов, вроде SysV-скриптов. Часть пользователей реагирует на такие решения крайне эмоционально, требуя "поддерживать всё, как было, бесконечно".
Но у любой поддержки есть цена:
- разработчикам свободного ПО приходится тратить значительное время на сопровождение устаревших интерфейсов;
- каждая дополнительная "ветка совместимости" усложняет код, увеличивает число багов и делает развитие медленнее;
- мейнтейнерам дистрибутивов становится сложнее собирать и тестировать пакеты, которые должны одинаково работать и с новыми механизмами, и со старыми.
В итоге встаёт вопрос: кто реально готов брать на себя труд поддержки "зоопарка"? Если у проекта нет ресурсов или желания продолжать тянуть устаревшие решения, логично, что приоритет отдаётся новым возможностям и упрощению архитектуры. Пользовательский выбор здесь прост: либо идти вместе с эволюцией, либо брать на себя ответственность за самостоятельное сопровождение старых схем.
Логирование и отладка: когда "всё само по себе" - это проблема
Ещё один предмет споров - централизованное логирование через systemd. Критики предпочитают "простые текстовые логи" и собственные схемы ротации. Но у такой модели есть свои подводные камни:
- если один "шумный" сервис из-за атаки или ошибок генерирует гигантский объём логов, он может незаметно "съесть" всё свободное место;
- без единого механизма ограничений и ротации трудно задать и контролировать политику для всех служб сразу;
- отладка усложняется, когда у каждой службы свои методы логирования, форматы и пути хранения.
Systemd предлагает:
- централизованный сбор логов с возможностью задавать индивидуальные и общие лимиты по объёму и времени хранения;
- единый интерфейс для просмотра и фильтрации;
- предсказуемое поведение при нехватке места и при перегрузке логами.
Да, это требует изучения новых инструментов, но значительно уменьшает число "граблей" в эксплуатации.
Аргумент "ничего не хочу изучать заново"
Часть критики systemd сводится к отказу от обучения: "работало и 20 лет назад - пусть так и работает". На практике это приводит к тому, что:
- администраторы игнорируют современные механизмы, которые экономят время и повышают надёжность;
- технический долг копится, инфраструктура устаревает, её становится страшно трогать;
- при смене персонала или расширении команды новая кровь вынуждена поддерживать архаичные решения, вместо того чтобы работать с более понятными и стандартизованными инструментами.
Разработчики systemd сознательно двигают экосистему вперёд: вводят новые механизмы, убирают старые, интегрируют функции, которые раньше предоставлялись десятком разрозненных проектов. Это болезненно для тех, кто привык к старому, но даёт выигрыш в долгосрочной перспективе: меньше несостыкованных компонентов, меньше ручных "костылей", больше единообразия.
Что даёт переход на systemd 260 администраторам и пользователям
Для тех, кто планирует обновление до systemd 260, ключевые практические эффекты можно обобщить так:
- более чистая архитектура без устаревшей прослойки SysV;
- новые возможности для построения сложных, многослойных файловых окружений через `mstack` и overlayfs;
- упрощение диагностики через `systemd-report`;
- улучшенная работа с мобильными сетевыми интерфейсами благодаря интеграции `systemd-networkd` с ModemManager;
- расширенные сценарии развёртывания переносимых сервисов, в том числе на уровне обычных пользователей;
- более тонкие механизмы контроля доступа и безопасности через новую концепцию "xaccess".
При этом обновление - хороший повод провести ревизию:
- перевести оставшиеся init-скрипты в нативные юниты;
- привести к единому стилю управление сервисами и логами;
- задokumentировать новые процессы и обучить команду работе с современными возможностями systemd.
Systemd 260 продолжает линию эволюции: меньше "наследия прошлого", больше интеграции и инструментов для предсказуемого управления системой. Выбор между "как раньше" и "как сейчас" остаётся за администратором, но с каждым таким релизом становиться очевиднее, куда движется основная часть экосистемы GNU/Linux.
