LINUX.ORG.RU

systemd 198

 


0

3

Вышел очередной релиз systemd. Нововведения и улучшения:

  • Возможность уточнения отдельных параметров юнит файлов в локальной конфигурации без копирования и исправления оригинального юнита.
  • Для systemctl добавлено новое поведение и параметры:
    • list-dependencies — рекурсивный вывод текущих зависимостей юнита;
    • poweroff и прочие теперь учитывают состояние ингибиторов;
    • set-cgroup-attr — меняет в рантайме параметры cgroups для юнита и сохраняет их как уточнения;
    • status без параметров теперь выводит статус сообщения для всех активных юнитов.
    • --irreversible — последующие задачи, добавленные в очередь, в случае конфликтов не вытесняют задачи, добавленные с таким флагом.
  • systemd теперь умеет симпатично выводить информацию на консоль о подвисших задачах.
  • В журнал добавлено поле _SYSTEMD_USER_UNIT для фильтрации по юнитам пользовательских сессий.
  • Убрана поддержка дистрибутиво-специфичных зависимостей в lsb init скриптах.
  • Связка systemd+gummiboot теперь умеет использовать EFI (автомонтирование ESP, efivars, передача таймингов и т. п.).
  • Добавлен PoC для интерфейса конфигурации загрузки в виде утилит bootctl/kernel-install, которые пока не делают ничего полезного.
  • logind теперь сигнализирует о выходе из сна и теперь умеет unlock-sessions в дополнение к lock-sessions.
  • tmpfiles теперь умеет делать исключения (X).
  • udev теперь расставляет права доступа только в «add» событиях.
  • bootchart перелицензирован под LGPLv2.1+ для единообразия.
  • policykit убран из обязательных зависимостей при компиляции.
  • systemd-analyze переписали на C.
  • Python API теперь умеет читать/писать журнал.
  • Добавлена утилита systemd-activate для тестирования socket activation.
  • journalctl в последние часы перед релизом получил пачку новых опций для вывода задом наперед.
  • Владельцем системных журналов теперь по умолчанию является группа systemd-journal.
  • Исправлено поведение systemd-vconsole-setup, конфигурации переменных окружений, nspawn, работы в составе initrd, SMACK и множества других недочетов в API и багов во второстепенных компонентах, пополнена коллекция тестов.

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

★★★★★

Проверено: svu ()
Последнее исправление: Silent (всего исправлений: 7)
Ответ на: комментарий от vasily_pupkin

Я ничего не считаю. Я указываю на то, что говорить, что inittab - полный аналог юнитов — некорректно.

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

При крупных изменениях в апстриме придется синхронизировать метод инциализации вручную. Например, переименуют сервис, и оп-ля. Или параметры запуска поменяются.

А этого в принципе никак не избежать. Просто не надо к проблемам неизбежным добавлять проблемы избегаемые.

Ну вот и оптимизировали

Создав 4меговый бинарь требующий полного Си тулчейна для изменения этого бинарного конфига? Нюню. Отличная оптимизация КОНФИГА, бро :D

Что отдельный миниязык для системы инициализации не нужен.

Скажите это Поттерингу и самому себе.

Достаточно всунуть костыли там, где они необходимы. А там где они не необходимы - не всовывать.

По этому мы сунули очень простой вариант этого языка: ini файлы с огромным числом «переменных». Так как эти переменные влияют еще и на flow of execution - у нас как раз таки отдельный миниязык для системы инициализации. Но ужасно кривой и завязанный конкретную версию си блоба.

Вы понимаете что сейчас вы в очередной раз аргументировали позицию «системд - монолитное говно» :D

У меня нет с этим проблем, в любом случае.

Окей. То есть это таки монолитное говно. Вот еще один фанат системд сознался. А как дышали, как дышали - постили ссылки на разоблачения мифов :D

Я использую монолитный монолитный системде на монолитном линаксе.

Вообще то линукс как раз модульный просто до упора - по сравнению с системд. Команда modprobe и объем того что вынесено в модули это наглядно демонстрирует. :D

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

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

Фильтр в юниксвее это про пайпы. Движок не может быть однонаправленным. Так что это не про то.

Вот так и рождаются нездоровые сенсации. Сейчас опять выяснится что вы критикуете юниксвей потому что даже пайпы воспринимаете ... альтернативно.

Скажите что такое по вашему программа в пайпе, типа sort например? Что вам мешает посылать команды на вход пайпа, а ответы на команды читать с выхода пайпа? :D

Вообще у нас уже есть движек зависимостей один, make называется. Его даже кто-то использовал для этого )))

make не удобен в режиме работы в качестве «демона».

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

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

Вы похоже не понимаете одной очень простой вещи. При равном функционале хорошая программа гораздо дороже плохой

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

Похоже на аргументы свидетелей иеговы

Чем именно? Вы действительно этой вот простой вещи не понимаете - что просто наваять огромный глючный си-блоб гораздо проще любого юниксвея?

Это плодит неудобства - удобнее как LSB заголовок.

Чем удобнее

Тем что все описание поведения процесса, вместе с костылями - в одном месте.

А еще удобнее завести кроме start|stop в скрипте еще команду depend например. И если она есть - читать зависимости оттуда.

Это было бы мило, наверное. Только зачем?

Это дает гибкость - мы можем перевычислять зависимости согласно любому доступному нам в скрипте методу. Ну и что бы можно было взять тонны уже готовых init скриптов для «непопулярного» софта(под который безумные фанаты системд ваять юниты не будут - так как «ненужно, и энтерпрайз ненужен») и сопряч их с depend-based системами инициализации. При этом у нас получается гибкость скриптов - возможность делать любую политику через вот этот предоставленный механизм.

Я поверю в это, когда увижу работающий PoC

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

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

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

да нет. sysvinit - многоярусная система, в отличие от systemd. и некорректно сравнивать только inittab или только rc.d или только init.d с юнитами. сравнение должно быть комплексным

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

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

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

А этого в принципе никак не избежать. Просто не надо к проблемам неизбежным добавлять проблемы избегаемые.

Ну, вообще то, выделив именно конфигурацию, избегается большинство проблем. В генте с openrc я никогда не обновлял conf.d и всегда неглядя init.d.

Создав 4меговый бинарь требующий полного Си тулчейна для изменения этого бинарного конфига? Нюню. Отличная оптимизация КОНФИГА, бро :D

КОНФИГ там текстовый, бро.

Скажите это Поттерингу и самому себе.

Поттерингу это говорить не нужно, он и так сделал так как сделал.

Так как эти переменные влияют еще и на flow of execution - у нас как раз таки отдельный миниязык для системы инициализации. Но ужасно кривой и завязанный конкретную версию си блоба.

Переменные вообще очень часто влияют на flow of execution, иначе зачем они нужны?

Окей. То есть это таки монолитное говно. Вот еще один фанат системд сознался. А как дышали, как дышали - постили ссылки на разоблачения мифов :D

Я пользуюсь линаксом, фаерфоксом и емаксом. У меня понятие монолита отлично от монолитофобов. От называний чего-либо монолитом суть не меняется

фанат системд

Спасибо, поржал

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

Это.. фильтр?!1

make не удобен в режиме работы в качестве «демона».

Но его же можно упаковать в баш с while :; do, и сгружать туда события по дубасу с dbus-monitor. Или это уже по твоему ненужные усложнения? ))

Аналогов стейтфулл системы на миниязыках(или еще как то) нет потому что это будет лучшим, а значит дорогим решением.
Чем именно?

БО^W UNIX-WAY ДЕЛАЕТ НАМ СТРАДАТЬ ПОТОМУ ЧТО ЖЕЛАЕТ НАМ ДОБРА! :D

Отлично. Лучших, а значит дорогих решений не будет, потому что они лучшие и дорогие. Ну, не будет значит не будет. Будем о них мечтать, значит. Помолимся, бро? ))

Тем что все описание поведения процесса, вместе с костылями - в одном месте.

Поведение, которое «конфигурируется» LSB заголовком, находится _совсем_ в _другом_ месте.

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

Поживем - увидим

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

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

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

Ну, вообще то, выделив именно конфигурацию,

Если ее можно выделить. Мое же предложение позволяет избежать проблем и тогда когда выделить конфигурацию нельзя.

Создав 4меговый бинарь требующий полного Си тулчейна для изменения этого бинарного конфига? Нюню. Отличная оптимизация КОНФИГА, бро :D

КОНФИГ там текстовый, бро.

Там ЧАСТЬ КОНФИГА текстовая, бро.

Переменные вообще очень часто влияют на flow of execution, иначе зачем они нужны?

А очень часто не влияют. А когда у вас есть переменая типа «номер строчки после которой запустить этот файл» это уже не переменная а конструкция языка. И да, собственно в системд часть переменных напрямую предназанчены для flow control. у нас фактически имеет место быть шелл: exec процессов + flow control - только с экзотическим синтаксисом.

А значит ваше утверждение о том что «язык ненужен» - ложно. Он нужен по крайней мере в системд и он есть.

Я пользуюсь линаксом, фаерфоксом и емаксом. У меня понятие монолита отлично от монолитофобов.
От называний чего-либо монолитом суть не меняется

Естественно не меняется - от этого зависит только суть утверждения «Х есть монолит». По сути ложно ли оно или по сути истинно :D

Это.. фильтр?!1

Я надеюсь что этой шуткой вы дали понять, что поняли, что были неправы. Движок прекрасно может работать в качестве фильтра, так как фильтр ничем не отличается от «двунаправленного» канала взаимодействия с демоном: мы шлем демону команды, он шлет ответы.

Но его же можно упаковать в баш с while :; do, и сгружать туда события по дубасу с dbus-monitor. Или это уже по твоему ненужные усложнения? ))

Так это будет банально неоптимально :D Мы стопитсот раз запускаем make. А суть демона именно в том что мы можем в него зависимости один раз загрузить, по этому они могут быть большие и в удобном человеку формате - «компилируем» же их только один раз.

Но ваше решение применимо если мы зависимости захотим на баше пересчитывать, взаимодействуя по dbus :D

О^W UNIX-WAY ДЕЛАЕТ НАМ СТРАДАТЬ ПОТОМУ ЧТО ЖЕЛАЕТ НАМ ДОБРА! :D

Я смотрю свидетели иеговы нашли дорогу к вашему мозгу. Тяжело вам.

Юниксвей выгоден на long run, мы можем производить изменения, развитие системы, исправление багов с заметно меньшими тратами и проблемами чем без него. То есть например когда у нас нет толпы бесплатных поттерингов готовых внезапно писать мегабайты сишных бинарей на каждый чих, или толпы недорогих индусов которые лехко перепишут системд на яве ... и будут это делать каждый релиз заново с нуля :D

Отлично. Лучших, а значит дорогих решений не будет, потому что они лучшие и дорогие. Ну, не будет значит не будет. Будем о них мечтать, значит. Помолимся, бро? ))

Ну почему же только мечтать - просто ситсемд еще только безумные школьники освоили. А вот когда он донесет свои ужасы до масс админов с rhel7, и избежать его использования будет нельзя .... вот тогда все то и забегают :D

Тем что все описание поведения процесса, вместе с костылями - в одном месте.

Поведение, которое «конфигурируется» LSB заголовком, находится _совсем_ в _другом_ месте.

Именно по этому я и предлагаю команду depend.

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

Там ЧАСТЬ КОНФИГА текстовая, бро.

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

А значит ваше утверждение о том что «язык ненужен» - ложно. Он нужен по крайней мере в системд и он есть.

Если ее можно выделить. Мое же предложение позволяет избежать проблем и тогда когда выделить конфигурацию нельзя.

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

Естественно не меняется - от этого зависит только суть утверждения «Х есть монолит». По сути ложно ли оно или по сути истинно :D

В действительности все совсем не так, как на самом деле )

Я надеюсь что этой шуткой вы дали понять, что поняли, что были неправы. Движок прекрасно может работать в качестве фильтра, так как фильтр ничем не отличается от «двунаправленного» канала взаимодействия с демоном: мы шлем демону команды, он шлет ответы.

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

Так это будет банально неоптимально :D Мы стопитсот раз запускаем make. А суть демона именно в том что мы можем в него зависимости один раз загрузить, по этому они могут быть большие и в удобном человеку формате - «компилируем» же их только один раз.

Осторожнее, мы сейчас напишем системде! Похоже, в действительности, ваша вера в юниксвей не слишком сильна

Юниксвей выгоден на long run, мы можем производить изменения, развитие системы, исправление багов с заметно меньшими тратами и проблемами чем без него.

Все верно, если все ресурсы что нам доступны - два админа — выпускника общепита.

А вот когда он донесет свои ужасы до масс админов с rhel7, и избежать его использования будет нельзя .... вот тогда все то и забегают :D

Поживем - увидим ^_^

Именно по этому я и предлагаю команду depend.

Нужно предлагать команду build-job-tree

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

Да народ, Леннарту пора садиться за SystemdOS. Это будет справедливо.

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

Нет, там весь конфиг текстовый.

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

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

Только это геморой.

Я надеюсь что этой шуткой вы дали понять, что поняли, что были неправы. Движок прекрасно может работать в качестве фильтра, так как фильтр ничем не отличается от «двунаправленного» канала взаимодействия с демоном: мы шлем демону команды, он шлет ответы.

Движок может получать команды до завершения предыдущей.

Вы реально похоже тупите и оттого у вас такой юниксвей странный. Что мешает сделать то же с «пайпом»? Ваше непонимание как такие вещи делаются? :D

Например, в середине что-то повисло, пользователь это отрубил и дерево будет пересчитано.

Ну и я примерно о том же юзкейсе думаю. Что-то повисло, тот процесс который это отслеживает посылает в «движок» апдейты дерева и движок пересчитывает что делать дальше :D И я предлагаю в этот «движок» втыкать только обсчет графа. А исполнять это все отдельно. Ничего не мешает такому процессу послать «в пайп» уточняющие команды, что мол такие-то узлы недоступны.

Осторожнее, мы сейчас напишем системде! Похоже, в действительности, ваша вера в юниксвей не слишком сильна

Судя по вашему пониманию юниксвея, ваш уличный юниксвей который вам напел рабинович, действительно «устарел». Он как бы никогда не жил нигде кроме как внутри вашей головы, наводя там ужас и желание избавить мир от его существования. :D

Юниксвей выгоден на long run, мы можем производить изменения, развитие системы, исправление багов с заметно меньшими тратами и проблемами чем без него.

Все верно, если все ресурсы что нам доступны - два админа — выпускника общепита.

Вы очень мощно заклеймили Кена Томпсона и Денниса Ритчи. Вы, сам то, не иначе как сам Эйнштейн с второй головой Хокинга в гриме!? Не узнал, не узнал! Богатыми будете. :D

А вот когда он донесет свои ужасы до масс админов с rhel7, и избежать его использования будет нельзя .... вот тогда все то и забегают :D

Нужно предлагать команду build-job-tree

Это влияние вашего личного безумного юниксвея через вас говорит :D

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

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

«Захардкоженые группы» это дефолтный конфиг.

Только это геморой.

Это существующая реальность. Та которая в sysv. Возможность взаимодействия есть, ей можно пользоваться, ей пользуются.

Вы реально похоже тупите и оттого у вас такой юниксвей странный. Что мешает сделать то же с «пайпом»? Ваше непонимание как такие вещи делаются? :D

Ну, наверное. Мне как то всегда казалось, что в случае с пайпом есть один эмитент и один получатель, причем поток однонаправленный. Я как то туго себе представляю, что в таком случае должен делать «фильтр», и какой смысл в его отделении.

Судя по вашему пониманию юниксвея, ваш уличный юниксвей который вам напел рабинович, действительно «устарел». Он как бы никогда не жил нигде кроме как внутри вашей головы, наводя там ужас и желание избавить мир от его существования. :D

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

Это влияние вашего личного безумного юниксвея через вас говорит
Вы очень мощно заклеймили Кена Томпсона и Денниса Ритчи. Вы, сам то, не иначе как сам Эйнштейн с второй головой Хокинга в гриме!? Не узнал, не узнал! Богатыми будете. :D

Не удержался. Представил себе while:; do dbus-monitor | read, который в long run отлаживают суровые администраторы, простите :D

Это влияние вашего личного безумного юниксвея через вас говорит :D

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

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

Представил себе while:; do dbus-monitor | read, который в long run отлаживают суровые администраторы, простите :D

Ну а что такого? Есть же udevadm --monitor, он вполне полезен на практике.

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

Осторожнее, мы сейчас напишем системде! Похоже, в действительности, ваша вера в юниксвей не слишком сильна

нет чувак, это у тебя недостаточное зрение, чтобы отличить systemd от maked

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

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

Вопрос в необходимости и эффективности. По большому счету все компоненты в стиле юникс вея уже доступны в кореутилс и подобном, пользователю остается написать политику. Только вот никто этого делать не хочет, почему то (%

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