LINUX.ORG.RU

Релиз systemd 199

 


0

3

Леннарт Поттеринг выпустил релиз systemd 199.

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

  • Теперь systemd-python может быть использован для управления libsystemd-daemon.
  • Несколько переменных sysctl меняются при запуске (например, ставятся «безопасные» настройки sysrq).
  • Число рабочих процессов вычисляется исходя из числа CPU, а не памяти, как было ранее.
  • Journald теперь принудительно сбрасывает данные на диск спустя 5 минут после записи в журнал (т.е. данные на диске отстают не более чем на 5 минут).
  • Директории /tmp и /var/tmp теперь доступны для всех процессов сервиса.
  • Предсказуемые имена интерфейсов (вроде enp0s3) могут быть отключены через параметр ядра net.ifnames=0 (к самому ядру это не имеет отношения, параметр влияет только на systemd).
  • Количество рабочих процессов udev теперь зависит от количества процессоров в системе, а не от количества памяти.
  • В составе systemd появилась libsystemd-bus, которая, возможно, будет доступна и для обычных приложений.

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



Проверено: true_admin ()
Последнее исправление: Aceler (всего исправлений: 10)
Ответ на: комментарий от true_admin

можно пример «правильной» реализации init?

Slackware - c BSD-style init

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

Формат юнитов убог.

Субъективно. Не более убог, чем «параметры» start-stop-daemon, например

И для много чего они ещё не написаны/требуют доводки.

ты уверен что это аргумент? (=

Уровень «документации» тут уже много раз обсуждался. systemd'шные маны — это вообще нечто!

Не знаю. Может быть. Как справочник маны ок, как учебник - нет. Правда мне почему то кажется, что проект не такой сложный, что бы требовался целостный учебник

Монолитные комбайны с QR и веб-сервером — это плохо.

Чушь

Бинарные логи — это вдвойне плохо.

Опционально

За новые имена сетевых интерфейсов вообще надо отрывать руки.

Опционально

И вообще, даже если какая-то проблема будет только у 0,5% пользователей, Поццеринг обязательно решит её так, чтобы вызвать головную боль у всех 100%.

Например?

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

Просто для протокола: я не пользуюсь ни emacs, ни xsession.

ups, не там на «Ответить» жмакнул - все true_admin-ам адресовано

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

давай свои - чем лучше

  • Наличие API поверх вменяемых средств IPC для основных кирпичей системы
  • Активная модель — уведомление заинтересованных сторон о событии в момент его возникновения
  • Консистентное состояние контекста при старте сервисов
  • Уменьшенное количество требований к действиям демонизации
  • Акцент на максимальном использовании возможностей предоставляемых linux
  • Основный параметры в декларативном стиле
  • Многослойный подход к уточнению конфигурации

Это то что лично мне нравится

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

У убогих юнитов ведь нет даже простейших ветвлений и циклов

да, это фейл, я согласен.

Это разве правильно?

не, это плохо

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

и в названии функции static int systemd_fds

начало положено :). Ты уже его не соберёшь без systemd. Тупо нет мейкфайла. А может я что проглядел.

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

отвечу в твоем стиле

Наличие API поверх вменяемых средств IPC для основных кирпичей системы

ненужно

Активная модель — уведомление заинтересованных сторон о событии в момент его возникновения

было

Консистентное состояние контекста при старте сервисов

было

Уменьшенное количество требований к действиям демонизации

а это как?

Акцент на максимальном использовании возможностей предоставляемых linux

сильнее загрузить?

Основный параметры в декларативном стиле

более сложно?

Многослойный подход к уточнению конфигурации

еще сложнее?

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

У убогих юнитов ведь нет даже простейших ветвлений и циклов

И зачем они нужны?

а у инитскриптов бывают более сложные задачи, чем «запустить /usr/bin/xxx на старте, грохнуть при останове» (например, запустить fsck и по результатам либо вывести ошибку, либо продолжить загрузку)

Оформляется юнитом и зависимостями

есть куча дублирующихся конфигов (modprobe.d vs. modules-load.d

ето вообще-то разные вещи

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

арч, системгэ, апдейты... и без проблем, ага. Когда ты так очевидно врешь, то как тебе верить в чем-то менее очевидном? ;)

Я не вру :(

Этот монолиткомбайн с текущим стилем разработки не может быть использован в lts

утешай себя, до выхода новой шапки не так много осталось :)

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

утешай себя, до выхода новой шапки не так много осталось :)

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

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

А может я что проглядел.

проглядел. написать мейкфайл и свой можно. так-же как и использовать костыли a-la gentoo ebuild или вообще руками gcc blah-blah набрать. это всего-лишь лишние, и совершенно ненужные телодвижения, на которые поцтеринг и сиверс обрекли людей, не использующих systemd дерьмо.

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

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

Наличие API поверх вменяемых средств IPC для основных кирпичей системы

Не уверен, что DBus можно считать вменяемым средством, но в остальном - наверное, это хорошо. Единственная полезная вещь, сделанная systemd.

Основный параметры в декларативном стиле

Уе*щный ini с возможностью вкрячить скрипт стал «декларативным подходом»?

...

Было или баззворды.

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

Не более убог, чем «параметры» start-stop-daemon, например

Неверно. У нас есть полноценный скриптовый язык, на котором можно реализовать всё, что угодно, хоть управление через cgroups, хоть этот ваш start-stop-daemon (собственно, в арче так и сделано). Хотя, если честно, как арчевод я вообще не понимаю, зачем вам нужен start-stop-daemon. :)

ты уверен что это аргумент? (=

Да. Особенно в случае со static ethernet, юнит для которого уже сто лет написан, но его всё ещё надо выискивать и скачивать с форумов/вики. Через сеть. Которая ещё не поднята.

Чушь

Релиз systemd 199 (комментарий)

Опционально
Опционально

I like configure it, configure it!

Например?

Например, новые имена сетевых интерфейсов.

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

Уе*щный ini с возможностью вкрячить скрипт стал «декларативным подходом»?

А что, нет?

Было или баззворды.

Например?

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

Уе*щный ini с возможностью вкрячить скрипт стал «декларативным подходом»?

А что, нет?

Пока нет автоматической валидации всей конфигурации - нет.

Например?

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

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

Чушь

Релиз systemd 199 (комментарий)

 cat /var/db/pkg/sys-apps/systemd-9999/{IUSE,USE}
acl audit cryptsetup doc gcrypt gudev http introspection +kmod lzma pam python qrcode selinux static-libs tcpd vanilla xattr python_targets_python2_7 python_single_target_python2_7
acl amd64 audit cryptsetup elibc_glibc gudev introspection kernel_linux kmod lzma pam python python_single_target_python2_7 python_targets_python2_7 static-libs tcpd userland_GNU xattr

Неверно. У нас есть полноценный скриптовый язык, на котором можно реализовать всё, что угодно, хоть управление через cgroups, хоть этот ваш start-stop-daemon (собственно, в арче так и сделано). Хотя, если честно, как арчевод я вообще не понимаю, зачем вам нужен start-stop-daemon. :)

Ты не поверишь, но у тебя он и остался. Рассматривай юниты как «конфигурационные файлы» к start-stop-daemon, а не к тому, что его запускает.

зачем вам нужен start-stop-daemon

А как иначе?

Да. Особенно в случае со static ethernet, юнит для которого уже сто лет написан, но его всё ещё надо выискивать и скачивать с форумов/вики. Через сеть. Которая ещё не поднята.

Это проблема дистрибутива. Напомню, что в каждом дистрибутиве свой велосипед по поднятию сети. В обычной ситуации у юзера нетвёрк менеджер. В необычной — my-cool-network-bicycle-with-iptables-rules.sh

Например, новые имена сетевых интерфейсов.

Одно правило удев, наличие которого в поставке определяется политикой дистрибутива.

Ты как то зеленое с твердым мешаешь

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

было как мнимум в upstart

Ёпт, так мы не с «sysv» сравниваем? Консистентное состояние окружения при старте сервиса это по твоему баззвёрд? А FS неймспейсы у нас уже кто-нибудь подстраивает под сервис? Или там секкомп?

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

И зачем они нужны?

Я же привёл пример с fsck. А ещё, чтобы реализовать реакцию на первый запуск, чтобы компактно, в одном инитскрипте обрабатывать и dhcp, и static (уже приводил пример из арчевских инитскриптов?), чтобы не плодить всякие systemd-load-modules… Примеров тут можно привести вагон.

Оформляется юнитом и зависимостями

Да ну? Что же тогда Поттеринг аж целых полтыщи строк на Си накатал? :)

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

Ёпт, так мы не с «sysv» сравниваем?

Мы сравниваем со всем, что уже было и работало до systemd.

Консистентное состояние окружения при старте сервиса это по твоему баззвёрд?

Да.

А FS неймспейсы у нас уже кто-нибудь подстраивает под сервис?

В твоем списке этого не было. И в любом случае это не задача инита.

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

Консистентное состояние окружения при старте сервиса это по твоему баззвёрд?

Да.

Я вместе с auid, selinux context и мелочами типа энвайрмента с тобой не соглашусь, пожалуй

В твоем списке этого не было. И в любом случае это не задача инита.

Акцент на максимальном использовании возможностей предоставляемых linux

И в любом случае это не задача инита.

Да ну что ты. А чья же это задача?

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

Базовую муть типа циклических зависимостей можно выцепить с systemd --test. О какой именно неработоспособности речь?

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

Да ну? Что же тогда Поттеринг аж целых полтыщи строк на Си накатал? :)

It's all about ponies. Я не вижу особых проблем оформить это тупым юнитом.

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

cat /var/db/pkg/sys-apps/systemd-9999/{IUSE,USE}

От увеличения сложности и раздутости исходного кода это всё равно не спасёт (даже наоборот). И да, не вижу флагов для logind и journald. :)

Рассматривай юниты как «конфигурационные файлы» к start-stop-daemon, а не к тому, что его запускает.

Как я уже говорил, эти ваши конфигурационные файлы к start-stop-daemon годятся только для «запустить /usr/bin/xxx на старте, грохнуть при останове». Увы.

А как иначе?

В арче, например, есть только add_daemon, который создаёт /run/daemons/имя_демона, и rm_daemon, который его удаляет. Всё остальное делается ручками в самом инитскрипте (так, как удобнее автору данного конкретного скрипта).

Одно правило удев

Только вот не все читают ченджлоги systemd по утрам. А когда твоя сеть внезапно отвалилась, сделать это как-то особенно затруднительно, знаешь ли…

наличие которого в поставке определяется политикой дистрибутива

Точно, давайте свалим всё на мейнтейнеров! :)

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

Я не вижу особых проблем оформить это тупым юнитом.

Так и запишем: Поттеринг не осилил юниты.

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

От увеличения сложности и раздутости исходного кода это всё равно не спасёт (даже наоборот). И да, не вижу флагов для logind и journald. :)

QR/seal в ifdef, сервир в отдельной поделке. Ничего страшного там нет, можешь поверить :]

Всё остальное делается ручками в самом инитскрипте (так, как удобнее автору данного конкретного скрипта).

Что, все этапы демонизации для приложений которые этого не умеют делаются в скрипте? Правда чтоль?

Только вот не все читают ченджлоги systemd по утрам. А когда твоя сеть внезапно отвалилась, сделать это как-то особенно затруднительно, знаешь ли…

А когда твоя сеть внезапно отвалилась

Это значит ты используешь федору или арч. Вот и все.

Точно, давайте свалим всё на мейнтейнеров! :)

В данный момент даже политика старта и поддержка инит системы свалена на мантейнеров, внезапно.

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

Базовую муть типа циклических зависимостей можно выцепить с systemd --test

А не-базовую?

О какой именно неработоспособности речь?

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

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

не соглашусь, пожалуй

Никто и не ждал, что ты согласишься.

А чья же это задача?

Специальных утилит. Возможно, со своим языком описания.

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

Правда чтоль?

Yep.

Это значит ты используешь федору или арч. Вот и все.

Толсто. Ты ещё скажи, что с появлением глюкоNM пользователям вообще не нужно знать имена интерфейсов.

В данный момент даже политика старта и поддержка инит системы свалена на мантейнеров, внезапно.

Что ни сколько не избавляет разрабов от обязанности выбирать правильные дефолты (желательно, ничего не ломающие у тех, у кого до этого всё работало). Эх, не зря Торвальдс костерил Кея с Леннартушкой за непонимание этой простой вещи…

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

Ты ещё скажи, что с появлением глюкоNM пользователям вообще не нужно знать имена интерфейсов.

И какую именно информацию должен извлечь пользователь из этого сакрального знания? :-)

Таки да, большинству пользователей NM нет никакой нужды знать имена интерфейсов, ну а те, кому это всё-таки нужно теперь могут воспользоваться предсказуемыми именами интерфейсов благодаря замечательной фиче udev.

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

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

fixed

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

Сидит себе человек в районной сетке и nm еще нужен как собаке пятая нога :)

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

А не-базовую?

А я не знаю что это должно из себя представлять

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

не противоречит ли ему задание фрагментов скриптов в юнитах

«Фрагменты скриптов» в юнитах писать нельзя. Одними из возможных параметров являются программа+аргументы старта, останова, перезагрузки.

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

что делать, когда реализованной декларативности не хватает

Все как обычно. Или писать патчи, или писать костыли, или писать расширения. Система это не запрещает.

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

Правда чтоль?

Yep.

Не верю, но спорить буду когда проверю :]

Толсто. Ты ещё скажи, что с появлением глюкоNM пользователям вообще не нужно знать имена интерфейсов.

Не нужно. А зачем им их знать?

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

Это у тех, кто ставит с make ; make install? Обычно компетентность такой установки обеспечивают одноразово

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

Специальных утилит. Возможно, со своим языком описания.

Специальные утилиты обычно появляются вместе с фичами. Тем не менее, связывающую политику кто-то должен писать. Но этого не делают. Почему? Видимо потому что текущий убогий функционал существующих средств этого не позволяет. Проще написать на С/С++, как показывает практика.

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

А я не знаю что это должно из себя представлять

Наличие юнитов, на которые ссылаются Requires и подобные; существование программ, указанных в Exec*.

что делать, когда реализованной декларативности не хватает

Все как обычно. Или писать патчи, или писать костыли, или писать расширения

Т.е. декларативный язык нерасширяем. Отличная работа.

Специальные утилиты обычно появляются вместе с фичами. Тем не менее, связывающую политику кто-то должен писать. Но этого не делают. Почему? Видимо потому что текущий убогий функционал существующих средств этого не позволяет. Проще написать на С/С++,

...и вкрячить в systemd

P.S. от Condition* хочется плакать. Список виртуализаций из СonditionVirtualization - это хардкод в Си-коде?

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

Наличие юнитов, на которые ссылаются Requires и подобные; существование программ, указанных в Exec*.

Второго точно нет. Хорошая идея для запила

P.S. от Condition* хочется плакать. Список виртуализаций из СonditionVirtualization - это хардкод в Си-коде?

Да, почти. Там С бинарь юзается для проверки. Conditions это полный бред конечно. Надо взять и порешать этот вопрос с запиливанием ConditionExec, ящитаю.

vasily_pupkin ★★★★★
()

В Plan 9 настройки интерфейса привязаны к его mac-адресу, почему в линуксах не могли сделать так же?

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

Или писать патчи, или писать костыли, или писать расширения

Т.е. декларативный язык нерасширяем.

Это каким органом надо мыслить, чтобы из необходимости писать расширения (сюрприз! ни в одной расширяемой системе они сами себя не пишут) прийти к заключению о нерасширяемости? Зато теперь понятно откуда берутся дурацкие мифы о systemd.

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

ни в одной расширяемой системе они сами себя не пишут

Какой ты тупой. Почему ты еще не погиб от какого-нибудь несчастного случая?

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

А, то есть sysrq выпиливается нафиг, за исключением sync. Ну понятно, поттеринг дурак, ну, ничего нового )) чо сказать...

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

RTFM http://0pointer.de/blog/projects/the-biggest-myths.html myth #1
Когда ж ты уже догадаешься документацию-то почитать, а?

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

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

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

никакой из которых заменить невозможно

с хрена-ль собственно? иди и меняй если так приспичило - наказывать никто не будет :-D

и да, некропостеры не нужны.

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