LINUX.ORG.RU

Выпуск systemd 213

 ,


0

4

systemd — система инициализации и менеджер служб для Linux, совместимые со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации, использует сокеты и активацию D-Bus для запускаемых служб, предлагает запуск демонов по необходимости, отслеживает процессы при помощи контрольных групп Linux, поддерживает мгновенные снимки и восстановление состояния системы, монтирование и точки монтирования, а также внедряет основанную на зависимостях логику контроля процессов сложных транзакций.

Основные изменения:

  • Новый демон «systemd-timesyncd» для синхронизации времени по сети. С целью упрощения реализованы лишь возможности SNTP-клиента, код не перегружен излишней серверной функциональностью. Демон запускается с минимумом привилегий и умеет взаимодействовать с networkd, чтобы работать только при наличии подключения к сети. Кроме того, он умеет периодически сохранять текущее время на жестком диске и при следующей загрузке сразу восстанавливает его, не дожидаясь начала очередной синхронизации. Это полезно для устройств, в которых отсутствуют часы реального времени (Raspberry Pi, встраиваемые устройства). Восстановленное при загрузке время будет не самым точным, но это лучше, чем ничего. При этом, требуется создание в системе отдельного пользователя и группы «systemd-timesync».
  • Отключена поддержка «seqnum» в libudev, поскольку, если устройства находятся в различных пространствах имён, их номера не будут последовательны.
  • Для «systemctl list-timers» и «systemctl list-sockets» добавлен ключ --recursive, отображающий юниты указанного типа для всех локальных контейнеров.
  • Служебные юниты получили новую директиву RebootArgument=, с помощью которой можно передать ядру аргументы для следующей перезагрузки, если перезагрузка осуществляется через использование StartLimitAction=.
  • Кроме того, этим же юнитам добавлена директива FailureAction=, через которую можно указать, какие операции будут выполнены в случае сбоя сервиса. Все это работает аналогично директиве StartLimitAction=, но в данном случае, указанные операции будут выполнены немедленно после первого же сбоя, а не после нескольких попыток перезапуска проблемного сервиса.
  • Утилита hostnamed теперь может работать с информацией об имени ядра, релизе и версии.
  • На графики, создаваемые утилитой bootchart, добавлены сведения cgroup.
  • Сервисы получили поддержку опции CPUQuota=, с помощью которой можно жестко ограничить в процентах потребление сервисом процессорного времени. Это значение не будет превышено, даже если процессор простаивает.
  • systemd-networkd обучен поддержке IPIP и SIT-туннелей.
  • Скриптам инициализации LSB добавлена зависимость от network-online.target, вместо network.target. За счёт этого, их поведение становится более похожим на то, каким оно было в SysV.
  • Добавлена поддержка опции ядра fsck.repair=, которая определяет, что fsck сделает при загрузке с некорректно отмонтированными файловыми системами.
  • Парсер конфигов (.ini) теперь игнорирует разделы, имена которых начинаются с «X-». Это открывает дорогу к созданию в конфигах специфичных разделов для нужд других приложений.
  • machined получил новый API для запроса IP-адресов зарегистрированных контейнеров.
  • Добавлен новый вызов call sd_uid_get_display(), позволяющий запросить информацию об основной сессии пользователя. Основная сессия выбирается из числа всех сессий. Например, графическая сессия будет предпочтена текстовой.
  • У systemd-networkd появился компаньон — крохотный демон systemd-resolved, который вносит изменения в resolv.conf, основываясь на конфигурации DNS для сетевых интерфейсов. В будущем, сюда добавят локальный кэш DNS и mDNS с поддержкой DNSSEC.
  • Включена по умолчанию утилита systemd-networkd-wait-online, которая вносит задержку в network-online.target до того момента, пока не будет настроено подключение к сети.
  • Две новых опции: StartupCPUShares= и StartupBlockIOWeight=. Они работают аналогично CPUShares= и BlockIOWeight=, но только при загрузке системы.
  • hostnamed теперь предпочитает брать имя хоста из /etc/hostname, если оно там указано, а не через DHCP. В systemd, параметры, определённые локальным администратором, традиционно имеют больший приоритет, чем любые другие.

>>> Подробности

anonymous

Проверено: fallout4all ()
Последнее исправление: ymn (всего исправлений: 2)
Ответ на: комментарий от vitalikp

системдэ - это и есть альтернатива стабильно работающим сегодня инитам. Поэтому, да, альтернатив нормальных нет.

Deleted
()
Ответ на: комментарий от vitalikp

даже примитивного roadmap'а нет

роадмап понять несложно - systemd пытается заместить собой протухшие части Линукс-экосистемы

anonymous
()
Ответ на: комментарий от jackill

Заметим, что чем сложнее система

Заметим, что сложная система не обязательно означает большая система.

anonymous
()

А, опять systemd. За шесть страниц хейтеры уже обосновали свою позицию «не unix-way — не нужно»?

anonymous
()
Ответ на: комментарий от vitalikp

мотив и цель - приблизить инфраструктуру Линукса к современному уровню, превратить груду разнобойных архаичных костылей в гладкую систему

методы можно лицезреть на практике

anonymous
()
Ответ на: комментарий от anonymous

Так можно описать большинство програм — мир во всем мире:) Только одни преследуют один цели и мотивы, остальные — другие. И еще куда более важно чего это будет стоить?

vitalikp
()
Ответ на: комментарий от quantum-troll

Концентрация, надо полагать, осталась прежней.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

vitalikp
()
Ответ на: комментарий от vitalikp

Да делится она на компоненты. «Склеены вместе» там только systemd (собственно инит), journald (логгер) и logind (сеансы пользователей), да и то последнюю можно при сборке отключить.

Всё остальное — тупо отдельные демоны для часто встречающихся задач, код которых положили в один репозиторий. И даже если они напишут по одному такому демону для всего, что сегодня встречается в GNU/Linux, никто не будет заставлять использовать именно их.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

«Склеены вместе»

угу, это и смущает. без вменяемого API заменить их будет не просто.

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

vitalikp
()
Ответ на: комментарий от vitalikp

Сделать другой можно. Выпилить нельзя, потому что он является частью основного функционала (вынесен в отдельный процесс ради уменьшения attack surface и уменьшения количества критического кода).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от vitalikp

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

Но нет, так никто не говорит, потому что внутреннее устройство кода драйверов сильно зависит от устройства кода самого ядра, и отвязывать их будет себе дороже. Монолитное ядро банально производительнее и надёжнее микроядра при прочих равных (нет, не надо приводить в пример QNX, оно писалось специально для реал-тайма).

Тем не менее, вон BSD-шники взяли из ядра код i915, потрахались с ним, вычистили от Linux-специфичных деталей и взяли себе. И почему-то не вопят, что Линус ни хрена не понимает в проектировании. Примерно так же и здесь: если кому-то позарез надо будет взять journald (именно journald) и запустить без systemd, ему придётся немного поработать.

intelfx ★★★★★
()
Ответ на: комментарий от vitalikp

уже вышла версия 214,

Ага, «портянки» больше не поддерживаются, сервис, отложивший корку тут же запускается вновь. Сбылась мечта недоодминов - упал демон, тут же сам перезапустился. А зачем разбираться, почему упал демон - это занятие для ретроградов... Упал-запустился, упал-запустился... романтика!

anonymous
()
Ответ на: комментарий от intelfx

Ну он же не собирается одним бинарником. И вполне может зависить от systemd и быть отдельной программой. Как и почти любой компонент. От того что не будет компонента логгера система не перестанет загружатся. Я здесь всматриваю не желание разрабатывать понятный API, который позволял реализовывать независимые компоненты. Я согласен что есть критические компоненты systemd, которые должны быть его неотемлимой частью. Но не все же! Каждый день плодят непонятные компоненты, которые в определенный момент может нести угрозу безопасности системы. Так как один из компонентов станет троянским конем, который превратит систему, которая будет управлятся из вне на свое усмотрение(!)

vitalikp
()

ЕГО УЖЕ НЕ ОСТАНОВИТЬ! ПОКАЙТЕСЬ ИБО ГРЯДЕТ!

dismal_faun ★★
()
Ответ на: комментарий от vitalikp

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

Каким образом? Все новые демоны вроде networkd и resolved — это отдельные бинарники, которые сами не запускаются. И, я бы сказал, доверия к апстриму systemd у меня больше (как минимум за счёт того, что о нём известно большему числу разработчиков), чем к гипотетическому условному «отдельному» микродемону для управления сетью.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

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

Но нет, так никто не говорит, потому что внутреннее устройство кода драйверов сильно зависит от устройства кода самого ядра, и отвязывать их будет себе дороже. Монолитное ядро банально производительнее и надёжнее микроядра при прочих равных (нет, не надо приводить в пример QNX, оно писалось специально для реал-тайма).

согласен.

Тем не менее, вон BSD-шники взяли из ядра код i915, потрахались с ним, вычистили от Linux-специфичных деталей и взяли себе. И почему-то не вопят, что Линус ни хрена не понимает в проектировании.

С BSD-шниками не дружу, ничего о них сказать не могу.

Примерно так же и здесь: если кому-то позарез надо будет взять journald (именно journald) и запустить без systemd, ему придётся немного поработать.

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

vitalikp
()
Ответ на: комментарий от intelfx

Каким образом? Все новые демоны вроде networkd и resolved — это отдельные бинарники, которые сами не запускаются. И, я бы сказал, доверия к апстриму systemd у меня больше (как минимум за счёт того, что о нём известно большему числу разработчиков), чем к гипотетическому условному «отдельному» микродемону для управления сетью.

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

vitalikp
()
Ответ на: комментарий от intelfx

И почему-то не вопят, что Линус ни хрена не понимает в проектировании.

Ну вот один товарищ вопил, что монолитное ядро — жирная ненужность, только микроядра и только хардкор. Тут то же самое в принципе — популярность побеждает архитектурную правильность.

vurdalak ★★★★★
()
Ответ на: комментарий от quantum-troll

Там все ответы — придирки к словам и аргументы в стиле «рабочих реализаций нет — значит плохая идея». Это ничего не значит.

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

«рабочих реализаций нет — значит плохая идея». Это ничего не значит

для эльфов, живущих в мире розовых единорогов, это действительно ничего не значит

anonymous
()
Ответ на: комментарий от vurdalak

популярность побеждает архитектурную правильность

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

anonymous
()
Ответ на: комментарий от intelfx

откуда мне знать что она делает?

ну пускай будет nonamectl. откуда мне знать, что она не несет потенциальную угрозу безопасности всей системы? что бы узнать, надо изучить ее получше. Но в состав она уже включена.

vitalikp
()
Ответ на: комментарий от anonymous

Ещё раз. Архитектура и популярность вещи не всегда связанные. Нет ничего плохого в желании сделать хорошую архитектуру.

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

ты какой-то тугой, тебе говорят о том, что следование красивым идеалам в ущерб практичности приводит к эльфийским поделкам, которые фейлят в условиях реального использования

anonymous
()
Ответ на: комментарий от anonymous

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

Красивые идеалы делают не для реального использования, а для проверки эффективности теорий и их развития

ты бредишь, проверить теорию можно _только_ практикой, а не фантазиями

anonymous
()
Ответ на: комментарий от anonymous

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

идеалы редко пригодны к применению из коробки

точнее, практически никогда

поэтому их сначала делают а потом понемногу внедряют в существующие решения

ну и?

anonymous
()
Ответ на: комментарий от anonymous

ну и?

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

vurdalak ★★★★★
()
Ответ на: комментарий от anonymous

Я не знаю, какой из предыдущих ораторов ты. Начиналось всё с утверждения, что «идею никто не реализовал» => «идея плохая». Так вот, это не так.

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

началось всё с микроядер, так вот, микроядерных ОС целую пачку уже написали, и все они, за исключением QNX, сфейлились, да и QNX - это не ОС общего назначения, а узко специализированная вещь

«идею никто не реализовал» => «идея плохая»

нет, не так

если идею несколько раз пытались реализовать, но постоянно получалось какое-то говно, то идее самое место на помойке

anonymous
()
Ответ на: комментарий от anonymous

если идею несколько раз пытались реализовать, но постоянно получалось какое-то говно, то идее самое место на помойке

Из чего это следует?

vurdalak ★★★★★
()

А почему бы все эти logind, journald, networkd etc не сделать отдельными программами (пакетами)? Получилось бы вполне разумно, логично, надёжно и юниксвейно.

bluesman
()
Ответ на: комментарий от bluesman

разумно, логично

такая же малоосмысленная чушь, как и «юниксвейно»

надёжно

а какие проблемы с надёжностью у systemd в настоящий момент?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.