LINUX.ORG.RU

systemd 214

 ,


1

4

11 июня был представлен очередной релиз системного менеджера systemd, совмещающего в себе функции системы инициализации, обратно совместимой с SysV и LSB, ведения журнала и управления сессиями пользователей. systemd основан на модели зависимостей (в противовес событийной модели), производит отслеживание процессов запущенных сервисов при помощи механизма cgroups ядра Linux, поддерживает механизмы сокет- и dbus-активации и предоставляет удобный декларативный синтаксис unit-файлов для описания демонов и других сущностей, что позволяет производить агрессивную параллелизацию при запуске и остановке сервисов.

В рамках проекта также разрабатывается ряд легковесных приложений и демонов, выполняющих второстепенные, но распространённые задачи по управлению системой — от настройки подсистемы VT (systemd-vconsole-setup) до управления сетью (systemd-networkd) и профилирования загрузки (systemd-bootchart).

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

  • Демоны systemd-networkd, systemd-resolved и systemd-bus-proxyd теперь запускаются не от имени root'а и сбрасывают максимум привилегий.
  • Файл resolv.conf, генерируемый systemd-resolved, теперь находится в /run/systemd/resolve.
  • Убрана зависимость от библиотеки libattr, поскольку требуемый функционал уже значительное время предоставляется библиотекой glibc.
  • Код совместимости с System V init и LSB был вынесен из PID 1 в отдельный генератор unit-файлов.
  • Обнаружение виртуализации (systemd-detect-virt) теперь работает без CAP_SYS_PTRACE.
  • systemd-networkd теперь поддерживает создание виртуальных Ethernet-интерфейсов (veth), а также GRE- и VTI-туннелей.
  • systemd-networkd больше не пытается подгрузить модули, требуемые для некоторых типов туннелей, если ядро не делает этого автоматически.
    Если в вашем случае это так (ядро недостаточно новое), предлагается использовать /etc/modules-load.d для принудительной загрузки этих модулей.
  • В секции [Service] юнит-файлов добавлены опции ProtectedHome= и ProtectedSystem=, позволяющие запретить процессам сервиса запись в /home и / соответственно.
  • В секции [Socket] юнит-файлов добавлены опции SocketUser=, SocketGroup=, RemoveOnStop= и Symlinks=, предназначение которых очевидно из названия.
  • Для опции Restart= в секции [Service] добавлено новое значение on-abnormal, инструктирующее systemd перезапускать сервис только в случаях падения, таймаута запуска или срабатывания сторожевого таймера, но не в случае завершения с ненулевым кодом возврата.
    Рекомендуется использовать Restart=on-abnormal или Restart=on-failure для всех долгоживущих сервисов.
  • В systemd-tmpfiles было добавлено действие C (копирование файлов или директорий), а действие m (установка прав доступа и владения) теперь эквивалентно действию z (установка прав доступа, владения и контекста SELinux с поддержкой выбора файлов по маске).
  • Добавлена первичная поддержка перестроения /var при запуске системы, что в конечном итоге должно позволить запускать контейнеры, имея только немодифицируемый образ /usr и tmpfs в качестве корневой ФС (т. н. stateless system).
    Сопутствующий функционал добавлен в systemd-nspawn (ключ --tmpfs=<путь>) и systemd-tmpfiles (уже упомянутое действие C).

Изменения, касающиеся udev:

  • Во время выполнения действий, касающихся файлов блочных устройств, udev теперь блокирует эти файлы при помощи flock(LOCK_SH|LOCK_NB).
  • Пока файл блочного устройства заблокирован, например, с помощью flock(LOCK_EX), udev будет игнорировать все события для этого устройства — предполагается, что этот механизм будет задействован приложениями разметки дисков.
  • Если файл блочного устройства был открыт для записи, его закрытие вызовет повторное сканирование таблицы разделов и (при необходимости) генерацию событий класса change для файлов устройства и всех его разделов.
  • Файлы устройств /dev/fd* теперь принадлежат группе disk, а не floppy.

>>> Объявление о релизе

★★★★★

Проверено: fallout4all ()
Последнее исправление: fallout4all (всего исправлений: 3)

Что-то выдыхаются неосиляторы, сдают... раньше, бывалоча, срача под 8 страниц минимум накладывали - а теперь только АХ привычно бзднёт, да нубы петросянят офигенно свежими шутками про добавление в $subj ядра и графического сервера.

А между тем у авторов-то энергия не иссякаема - релиз-за-релиз ведут они GNU/Linux в мир светлого будущего.

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

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

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

ну а сколько можно сраться изза инит-системы?

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

такой экземпляр мне повcтречалcя в 2007 году

Да они и сейчас встречаются, чего уж там...

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

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

а так понятно, что я могу установить пакетный менеджер deb или того же арча pacman. Но их наличие не улучшит ничего для меня.

A. Если прога использует разделяемые библиотеки то ты никак не можешь её запустить без их присудствия - это зависимость. Вряд ли у тебя в системе совпадут необходимые версии и опции сборки всех библиотек.

B. От сюда следует два вывода:

1. Можешь в своей системе собрать с исходников нужную тебе прогу. configere, make install... Но самый правильный путь это собрать установочный пакет недостающей проги и установить его штатными средствами! Потом этот пакет можно продвинуть в сам дистр.

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

C. Для лентяев и тех кто не хочет заморачиватся есть gentoo-prefix

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

В толксах уже обсудили.

В толксах было слишком мало боли.
А автору новости большая благодарность.

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

A. Если прога использует разделяемые библиотеки то ты никак не можешь её запустить без их присудствия - это зависимость. Вряд ли у тебя в системе совпадут необходимые версии и опции сборки всех библиотек.

Открываю зависимость systemd и вижу что он требует libblkid.so.1()(64bit). Это значит что должна быть библиотека /usr/lib64/libblkid.so.1. Если нет привязки к названию конкретного пакета, то очень даже может совпасть. Весь вопрос в каком формате хранятся зависимости. Если бы была спецификация регулирующая это, то запросто можно сопоставить разные пакеты с разных репозитариев дистрибутивов.

1. Можешь в своей системе собрать с исходников нужную тебе прогу. configere, make install... Но самый правильный путь это собрать установочный пакет недостающей проги и установить его штатными средствами! Потом этот пакет можно продвинуть в сам дистр.

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

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

Ну этим точно никто страдать не будет))

C. Для лентяев и тех кто не хочет заморачиватся есть gentoo-prefix

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

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

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

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

Как и было сказано, весь этот systemd это просто vendor lock, состоящий из НЕХ, знакомой только посвящённым 5-й ступени. Прям очень похоже на Oracle Database.

Lothlorien ★★★
()
Последнее исправление: Lothlorien (всего исправлений: 1)

обновил, полёт нормальный

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

Социальные сети (тупо удобнее чем e-mail и newsgroups)

Монструозные жабаскриптовые страницы, неадекватный поиск по постам, не-древовидные комментарии, да и вообще интерфейсы, побуждающие к написанию короткого и малоосмысленного… и это всё удобнее? Поржал, спасибо.

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

да, утёнок, это всё удобнее имэйла и новостных групп

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

Только слепой не видел этого. Но всем же положить ради светлого будущего.

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

Моя аватарка показывает лишь сарказм-отношение к себе самому.

deep-purple ★★★★★
()

systemd 387

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

  • Загрузка с /var на отдельном разделе больше не поддерживается.
  • Улучшена производительность CSS-селекторов в systemd-bootloader.
  • Текстовый редактор обновлён до версии 26.4, включена поддержка сценариев на языке Scheme (Guile)
anonymous
()
Ответ на: systemd 387 от anonymous

Текстовый редактор обновлён до версии 26.4, включена поддержка сценариев на языке JavaScript

/fixed

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

Очень мало боли в комментариях =(

Сделай себе больно и выплесни свою боль сюда.

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

Это детали реализации. Поведение udev здесь точно правильное — почему бы и не пропатчить другой проект, уточнив семантику его действий?

В конце концов, util-linux не болваны поддерживают, так что костыльный фикс туда запихнуть точно не удалось бы.

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

Unix-way в большинстве проявлений уже умер. И да, корректное разграничение такого вот минимального init'а и менеджера сервисов (как systemd, но не в PID 1) можно провести либо в ущерб функциональности, либо в ущерб надёжности. Соответствующий линк я, увы, где-то просрал.

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

Мне вот интересно, когда же на ЛОРе новости о релизах будут вызывать обсуждение фич и изменений конкретного релиза, а не представлять из себя вечный срач между нужнистами и ненужнистами?

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

Не будем показывать пальцем, но в Windows так и сделано. Ничего, живут.

Тут ещё вопрос, насколько такая функциональность необходима.

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

Я уже задавал вопрос, где про это почитать системно и подробно, с архитектурной точки зрения. Restart=on-failure включает поведение, предусмотренное опцией on-abnormal, или нет?

Если в системе два resolv.conf (один в /etc), какой будет использоваться по умолчанию? И будет ли системдшный resolv.conf перетекать в /etc при остановке systemd-resolved?

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

Конкретно на эти два вопроса ответ ищется в манах. man 5 systemd.service (искать Restart=) и man 8 systemd-resolved.

На первый вопрос — да, on-failure является надмножеством on-abnormal.

На второй вопрос — нет, resolv.conf, генерируемый systemd-resolved, затем и генерируется не в /etc, а хрен пойми где, чтобы админ сам мог решить, делать ему симлинк или, например, скармливать этот файл какому-нибудь dnsmasq'у. По умолчанию этот файл вообще ни на что не влияет. И да, это всё сказано в манах.

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

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

На правах траллинга

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

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

Что примечательно, ссылка на этот док есть на офф. сайте systemd.

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

Видимо, настолько, что число пользователей API systemd стабильно увеличивается (как здесь говорят, «всё больше проектов прибивают гвоздями к»).

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

Не надо идти по пути BSD и устраивать всякие /usr/etc, /usr/share/etc, /usr/local/etc

А что там не так? Всё логично. По крайней мере во FreeBSD. То, что лежит в корне - это world. Всё, что в /usr/local - то, что понаставил пользователь. Структура та же, что в корне. Снеси /usr/local и получишь kernel и world.

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

Слишком «академическая» иерархия, имхо. На словах выглядит красиво и логично, а по факту наверняка есть куча случаев, которые в эту иерархию не вписываются.

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

Такой формат называется rpm. Прописан в стандарте. Но даже дистры с rpm несовместимы между собой. А тут еще мганга с дебом вылезла и стала самой распространенной.

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

ёлы-палы, каждый чих поттеринга теперь будет освещаться? «поттеринг поел», «поттеринг сходил по большому»...

Дак тут как раз и обсуждают

system-Д == поттеринг сходил по большому

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

Нет таких случаев. Сносишь /usr/local и начинаешь новую жизнь с базовой системой, если необходимо.

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

Это почему же? Если ты сам софт поставил, то ищи в /usr/local/etc, если софт системный, то в /etc. Других вариантов нет.

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

Как минимум, это показатель нужности. А по моему субъективному мнению — да, это хорошо. Ещё один уровень абстракции (над разными системами инициализации) будет излишним.

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

А если это BSD, то ещё и в /usr/local/share/etc и в прочих интересных местах. Я, правда, BSD давно не использую, но тогда это было так (даже не порты ставил, а просто пакеты).

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

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

Впрочем, /usr/local/etc это не хорошо и не плохо, это просто так построено. В опёнке всё в /etc кладут и пока никому от этого хуже не стало.

Lothlorien ★★★
()
Ответ на: На правах траллинга от EvilFox

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

От авахи избавились, пульсаудио успешно выпилили, так же найдем способ обойтись и без системд

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

Когда Вы говорите, Иван Васильевич, впечатление такое, что Вы бредите.

А что, вас уже выпустили из сумасшедшего дома?

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

и в конце концов тихо сгниёте в своём уютненьком болотце, лол

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