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)

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

Да при чем тут PID 1? Система инициализации вообще не должна иметь доступ к сети, ни по каким предлогом. Иначе это потенциальная дыра.

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

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

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

При том, что это не система инициализации. Это обычный демон.

допиши: это обычный демон инициализации :D

А то как дети малые))

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

Понимаешь, ничто не отличает systemd-networkd от NetworkManager или wicd.

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

Ты вообще умеешь читать? systemd — это как coreutils. Там есть init и параллельно с ним много минималистичных демонов на все случаи жизни. Вот эти «много демонов» вообще никак не связаны с init'ом, за исключением того, что собираются из одного репозитория.

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

Ты вообще умеешь читать?

иначе мы б не общались.

systemd — это как coreutils

systemd нуждается в coreutils чтоб хотя бы собраться) И я не представляю себе mkdir без rmdir. А вот systemd без доброй половины примочек - представляю. Да даже всю систему без системде.

Вот эти «много демонов» вообще никак не связаны с init'ом

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

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

Только такой демон связан с системой инициализации и, очевидно, непосредственно взаимодействует с ней. Иначе какой смысл его вообще добавлять в systemd?! Что, соответственно, сразу ставит два вопроса: 1. Как будет разграничены права во взаимодействии с системой инициализации такого абстрактного демона? 2. И зачем вообще нужно городить подобный огород, если он предполагает дополнительный слой абстракции между системой инициализации и демонами?

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

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

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

И я не представляю себе mkdir без rmdir

А я вот представляю. Это два разных бинарника. О чём ты вообще?

а еще их нельзя отключить

Что, правда? А я-то и не знал. Чой-то у меня на ноуте systemd-networkd не запущен, а на домашнем сервере запущен?

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

Иначе какой смысл его вообще добавлять в systemd?!

Спроси у bsd-шников, зачем они держат весь core userspace в одном репозитории. Для простоты обслуживания, очевидно.

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

Потому что так проще обслуживать. У них много общего кода (вспомогательные библиотеки).

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

А я вот представляю. Это два разных бинарника. О чём ты вообще?

о предназначенности. mkdir без rmdir, это иначе, чем удав без хттп сервера, или система без системде.

Чой-то у меня на ноуте systemd-networkd не запущен, а на домашнем сервере запущен?

потому что ты не запустил, наверное. А попробуй исключить это в процессе компиляции. Оставь только инит например, или только журнал, или замени журнал на свой. Я ведь могу только mkdir в системе держать, без rmdir :-D

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

Журнал — плохой пример. Он обеспечивает часть функционала systemd, поэтому его не выпилить (хотя можно попросить не хранить логи самостоятельно, а отдавать syslog'у).

Но он вынесен в отдельный демон, специально, чтобы уменьшить attack surface и увеличить стабильность: падение журнала не вызовет падения системы. Кстати, эти вещи очень хорошо продуманы, так что остаётся только смеяться над заявлениями о некомпетентности команды разработчиков systemd.

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

Журнал — плохой пример.

зачем он вообще нужен, этот плохой пример, понимаешь? ;) Ведь до этого был хороший пример. Не учиться на хороших примерах и выступать при этом за их замену - неадекватно.

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

он вынесен в отдельный демон, специально, чтобы уменьшить attack surface и увеличить стабильность: падение журнала не вызовет падения системы. Кстати, эти вещи очень хорошо продуманы,

Гиганты системного проектирования - догадались вынести автономную функциональность в автономного демона.

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

зачем он вообще нужен, этот плохой пример, понимаешь? ;) Ведь до этого был хороший пример. Не учиться на хороших примерах и выступать при этом за их замену - неадекватно.

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

Журнал в качестве примера плох именно потому, что если его попытаться заменить старыми логами, откроешь все старые дыры и кривости.

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

Перечисли-ка фичи, которые есть в smf, но нет в systemd.

Конфиги сервисов в xml, например.

<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="manifest" name="memcached">
    <service name="site/memcached" type="service" version="1">
        <dependency name="network" grouping="require_all" restart_on="error" type="service">
            <service_fmri value="svc:/milestone/network:default"/>
        </dependency>
        <instance name="default" enabled="false">
            <method_context>
                <method_credential user="webservd" group="webservd"/>
            </method_context>
            <exec_method type="method" name="start" exec="/opt/memcached/bin/memcached -d" timeout_seconds="60"/>
            <exec_method type="method" name="stop" exec=":kill" timeout_seconds="60"/>
            <property_group name="startd" type="framework">
                <propval name="duration" type="astring" value="contract"/>
                <propval name="ignore_error" type="astring" value="core,signal"/>
            </property_group>
            <property_group name="application" type="application">
            </property_group>
        </instance>
        <stability value="Evolving"/>
        <template>
            <common_name>
                <loctext xml:lang="C">
                    Memcached
                </loctext>
            </common_name>
        </template>
    </service>
</service_bundle>

Ну разве не прелесть X_X.

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

Тогда зачем его добавлять в systemd? Что-то я перестал понимать их логику...

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

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

Конфиги сервисов в xml

И вправду восхитительно. А чем эти простыни в соплярисе правили интересно? Ну не вручную же в самом деле - это всё-таки не unit из systemd в котором только совсем болван разобраться не сможет.

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

Круто. А заявление вида «настройку systemd теперь рекомендуется проводить через GUI» вызвало бы здесь такой поток ненависти, что и представить страшно.

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

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

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

Да он уже есть, целых два (официальный на Gtk и kcm-модуль для KDE). Но тем не менее документация systemd — одна из самых лучших и полных среди всего open source.

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

Обожемой! Неужели великие гуру администрирования сопляриса были сплошь мышевозниками? Как страшно жить :-D

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

заявление вида «настройку systemd теперь рекомендуется проводить через GUI» вызвало бы здесь такой поток ненависти, что и представить страшно.

И правильно.

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

Когда уже появится LennartOS, что бы все наконец вздохнули свободно?

Что в зобу дыханье спёрло, бедненький? А ты голову из задницы попробуй вынуть - авось и полегчает.

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

Или ты думаешь, что udev под WTFPL распространяется?

Ладно, под чем праспостраняется udev, под чем раньше распостранялся eudev, под чем распостраняется в данный момент и какие именно условия лицензии былы нарушены?

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

Какие то из лицензий bsd запрещают. Может не все, но такое было и в одно время доходило до маразма.

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

вот это вот init(8), а что пилят RadHat я своим умом постичь не могу.

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

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

под чем праспостраняется udev

может тебе ещё и сопли вытереть?

и какие именно условия лицензии былы нарушены?

ты что - совсем дебил? Взяли чужой код, удалили имя автора, написали вместо этого своё - и вправду, нужно срочно найти буковку, которая это запрещает...

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

Не мог бы Господин Анонимный Эксперт по лицензированию привести конкретный пример?

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

Перечисли-ка фичи, которые есть в smf, но нет в systemd.

не бинарные логи, хотя бы. как там с делегацией прав на операции с определёнными или вообще одним сервисом без костылей аля судо?

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

она копирует ядро, msdos.sys, шел на C:

это как debian netinst :)
Не напрягай народ. Это замечательная прога которая, как сказать, копировала lilo без выбора :)

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

скрин в галерею выложи :)
Я линк уже дал. Можно посмотреть и понять.

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

Он обеспечивает часть функционала systemd, поэтому его не выпилить (хотя можно попросить не хранить логи самостоятельно, а отдавать syslog'у).
Но он вынесен в отдельный демон, специально, чтобы уменьшить attack surface и увеличить стабильность: падение журнала не вызовет падения системы.

Да, его падение не уронит всю систему. Зато легко нагугливаются жалобы и багрепорты на безнадёжную порчу логов journald (бинарный формат передаёт привет) при аварийном завершении работы системы (пример, зависания (примеры 1 и 2) и прочие «радости жизни с systemd».

anonymous
()

Странно. Ядро еще не заменил. А я все жду со дня на день.

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

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

Вот, ну наконец-то ты указал реальную причину ненависти к systemd

У меня это не ненависть, у меня это откровенное недоумение. А ссылку привёл, как пример KISS, про который Лёня похоже не слышал. Да и как ему слышать, если он пишет быстрее, чем другие читают?

Я, например могу прочесть и понять, что делает приведённый моной вариант init. А можешь ли ты, дорогой анонимус, разобраться в спагетти systemd? Боюсь что нет. Как и почти каждый, кроме самого Лёни.

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

вау, ты такой оригинальный, так нестандартно мыслишь.... ты наверное очень индивидуален?

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

Да и как ему слышать, если он пишет быстрее, чем другие читают?

Ага, у нас тоже в классе один такой был - читал медленнее, чем мы писали. А потом его в спецшколу перевили. Ты тоже в такой учился?

Боюсь что нет.

Не ссы. С такой великолепной документацией, как у systemd любой разберётся. Ну кроме таких вот ребят из спецшколы.

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

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

anonymous
()

systemd что-то сильно зачастил.

уже вышла версия 214, не знаю как остальных, но меня эта тенденция пугает. так как архитектурные решения принимает ограниченый круг лиц и не понятно в каком направлении двигается эта махина — даже примитивного roadmap'а нет. и альтернатив, к сожалению, тоже нет(.

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