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)

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

теперь комп выключается, если ему сказать halt или reboot из виртуальной консоли?

А разве с этим есть какие-то проблемы? УМВР на федоре.

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

Вот поэтому и пилят Hurd.

HURD не юниксвеен. Куча linux-драйверов прямо в mach'е, ага.

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

unix-way в том что каждая программа выполняет свою функцию, в systemd же куча всего что выполняет именно свою функцию, или я ошибаюсь?

Если в целом, то да, ошибаешься.
Еще unix-way в том, что нужно стремиться все хранить в текстовых файлах. systemd этому не последовал, притом без веских на то причин. В итоге даже если там каждая утилита делает что-то одно (в чем я сомневаюсь), эта утилита является аналогом (велосипедом) другой стандартной утилиты. А вот здесь я сомневаюсь, что она делает свою функцию хорошо. Ибо стандартные утилиты вылизывались годами, некоторые over 10 лет, а этому поделию лишь несколько лет.

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

Ну, например, комп с SSD эта штука на обычном винте не переплюнет, т.е. тем, кому действительно нужно очень быстро загрузиться, заморочатся с SSH и там разница в полсекунды не будет видна.
В случае сервера тоже сомнительно - загрузится он за 15 секунд или за 30. В основном влиять на загрузку будут инициализируемые службы, а не система загрузки. Можно и полторы минуты и две грузиться. Т.е. тоже без нужды.

Это вообще довод в пользу того, что Systemd не во всех ситуациях лучше. Я и не спорю.

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

Я не говорю, что Systemd - панацея, и вообще никакие другие системы инициализации не нужны. Тем не менее я не могу не отметить, что ресурсов в последнее время все больше и больше. Кстати, у меня сейчас под руками ноутбук, которому лет 7-8, и единственное, что в нем поменялось с момента его производства - видеокарта. Сейчас тут бодро работает OpenSUSE 12.2 с Systemd.

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

Вы каждый день пишете новые юниты? Когда я поставил Systemd себе на Gentoo (заметьте, поставил, она не была предустановлена, а Gentoo не славится своей дружелюбностью к пользователю) мне пришлось написать один-единственный юнит для Tor, в котором было строк 6.

В инитах черт ногу сломит - симлинки какие-то везде, названия, дублирующиеся названия.

А в это и не надо вникать. Disable, enable, start, stop. Все мирно и спокойно.

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

Не нуждаюсь, потому комментировать не буду.

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

симпатично выводить информацию на консоль

что, простите?

Симпатично == няшно.

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

все описанное возможно только при этом допущении. пока что все не так плохо.

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

А так да, собственно мы сейчас и посмотрим на то, насколько сообщество устойчиво к подобного рода атакам. То есть насколько оно mature и не готово не примитивно хватать любое говно а оценивает поступающий код с более высокого уровня. Грубо говоря, насколько в опенсорсе реально инженеры овладевшие искусством программирования юникс - а не очередная глупая школота с рассказами про то что «ето все было в 70-х и усталело, сичас прагресс и усе чисто новое и ето всио естория и надо пириосмыслить».

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

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

Удав вроде форкнули как раз в первую очередь.

А так да - по моему вот форк logind это как раз the right way. Не надо пытаться грудью остановить танк systemd - танк должен завязнуть в болоте. А мы сольем с него горючее и отвинтим колеса.

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

ЩИТО

Ну только что ты вот лично мне втирал про то что systemd это бинарный вариант functions из инитскриптов. Вот тебе и пример, был текстовый файл - стал 4х меговый бинарь. И он еще «щито» тут орет. :D

kernel ★★☆
()

freedesktop.org лежит

Хотел в кои веки глянуть хоть одним глазком на сабжевое говноподелие, ан нет - freedesktop.org в дауне, что кагбе намекает: не трожь каку. Или уже само размещение такого говнокода отправляет сервант в даун.

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

А вот здесь я сомневаюсь, что она делает свою функцию хорошо. Ибо стандартные утилиты вылизывались годами, некоторые over 10 лет, а этому поделию лишь несколько лет.

Получается если лопата веками выполняла свою работу хорошо, то мотоблоки нам какбы теперь и ненужны? Имхо у systemd есть шанс со временем превратиться в мотоблок против лопаты. А это прогресс, развитие и всё такое

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

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

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

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

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

Когда тебе кто-то говорит, что любую программу нужно распиливать обязательно на cat/grep/sort/uniq

Ну твой оппонент писал про «до состояния» cat/grep/... Что как бы предполагает что программа будет распилена просто на мелкие процессы куски. А тут он уже неправ - чаще всего если действительно внятно распилить программу именно на такие мелкие куски, это будет очень хорошо. Это просто не всегда возможно - мы очень часто не знаем как внятно пилить и это дорого стоит.

То есть оппонент говорит что пиление на мелкие куски однозначно плохо - а это как раз не так.

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

все описанное возможно только при этом допущении

пока что все не так плохо

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

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

Имхо у systemd есть шанс со временем превратиться в мотоблок против лопаты. А это прогресс, развитие и всё такое

В случае ситемд нам настаивают что мотоблок делает лопаты в целом ненужными, вообще-то :D

kernel ★★☆
()

О, ненужно уже имеет номер 198. 198 раз ненужно, ппц. Оно уже научилось не думать за юзера? Поцтерингщитает, что его быдлоподелка перевершит всех по разуму, поэтому банальные ситуации превращают систему в кусок неработающего дерьма, и пофикисить это на работающей системе не удаётся. Лопату кто-нибудь взял? // юзаю sysvinit

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

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

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

То есть оппонент говорит что пиление на мелкие куски однозначно плохо - а это как раз не так.

Это еще не всегда возможно, не всегда выгодно и не всегда нужно - классический пример с troff, где вполне юниксвейная программа сделана на основе DSL.

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

В случае ситемд нам настаивают что мотоблок делает лопаты в целом ненужными, вообще-то :D

Ну для производителя мотоблоков это логично. Разве реклама по весне не говорит с каждого постера «Купи мотоблок себе на дачу! Выбрось лопату.»

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

А разве с этим есть какие-то проблемы? УМВР на федоре.

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

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

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

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

Древняя — по причине заморозки Wheezy, после релиза обновят.

на момент заморозки Wheezy уже шли 18х версии

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

Входные данные в текстовом варианте. Логика залита бетоном в бинарь, да.

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

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

Нет.
Юниксвей в данном случае это предоставлять механизм а не политику. То есть сделать возможность использовать любой(почти любой) язык на месте systemd юнита. А сейчас юнит как язык описания неустраним.

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

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

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

Получается если лопата веками выполняла свою работу хорошо, то мотоблоки нам какбы теперь и ненужны? Имхо у systemd есть шанс со временем превратиться в мотоблок против лопаты. А это прогресс, развитие и всё такое

Использование мотоблока подразумевает, что можно им пользоваться, а можно взять лопату и пользоваться ей. Кому как удобно. В случае с системд, приобретая в магазине мотоблок к вам приходит дядя, забирает все лопаты с заявлением «они теперь вам не нужны!», и оставляет с мотоблоком. А мотоблок - китайская китайщина.

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

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

Ну наконец-то.

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

«Купи мотоблок себе на дачу! Выбрось лопату.»

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

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

Вот-вот, я о том же. Пусть не трогают лопаты, они должны быть.

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

Именно 10и минутную?

С секундомером не замерял, но субъективно примерно так. Ну, может, минут 5.

Скорее всего в каких-то юнитах кривой ExecStop

Чаще всего виснет на nfsd.service, там ExecStop=/usr/sbin/rpc.nfsd 0. Иногда просто на «reached target Shutdown».

Axon ★★★★★
()

Нововведения и улучшения

Ждём аналогичных плюшек в Upstart.

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

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

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

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

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

Тут настаивают, что как раз вот эта ситуация с таким именно вот вашим мотоблоком, безумна. А в комплект к любому мотоблоку должна быть лопата, и набор инструментов по починке мотоблока без применения «завода 80го уровня по гарантии пешком в японию.»

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

да ладно, мужик! у меня после halt или reboot из виртуальной консоли оно до пропадания электричества виснет;) а у тебя какие-то жалкие 10 минут.

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

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

Я бы не стал утверждать, что это было «именно по этому». Иниттаб полный аналог юнитов только в некоторой далекой светлой идее, как коммунизм, наверное. Он был настолько бесполезен, что единственное толковое что с ним можно было делать - запускать скрипт инициализации. Впрочем, в некоторых юниксах типа аикса им до сих пор активно пользуются для рестартов некоторых сервисов. Выглядит жутко, да.

Юниксвей в данном случае это предоставлять механизм а не политику. То есть сделать возможность использовать любой(почти любой) язык на месте systemd юнита. А сейчас юнит как язык описания неустраним.

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

Развитие инитов двигалось к вырождению этой фичи. Например, в широкоизвестном интерпрайзе собственно данные конфигурации выкидывались в sysconfig, а логика копипастилась и дублировалась в инитскриптах. Их модификация - доастаточно редкое явление, и сопряжена с геммороем при апдейтах. В openrc, например, наблюдается практически полное вырождение DSL в более узкий DSL. В бебиане похожая история. Если посмотреть на предлагаемый skel инита, то в большинстве случаев заполняться будет только шапка.

Причем тут еще важно понимать, что именно захардкожено в системде. Это движек зависимостей в первую очередь, машина управления состоянием, интерфейсы к дубасу итд. Например в опенрц движок зависимостей также реализован на С. Аналогов стейтфулл системы на миниязыках нет - это просто не рационально. Собственно юнит в [Service] секции - это просто как аргументы для start-stop-daemon, а в [Unit] — грубо говоря как depend{} секция в openrc или LSB заголовок в SysV. Я не считаю что это плохо.

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

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

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

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

Тут настаивают, что как раз вот эта ситуация с таким именно вот вашим мотоблоком, безумна. А в комплект к любому мотоблоку должна быть лопата, и набор инструментов по починке мотоблока без применения «завода 80го уровня по гарантии пешком в японию.»

Будто бы к этому мотоблоку нельзя прикрутить лопату. Да тут просто вагон способов это делать! Это как аргументы против mc любителей командной строки, которые забывают что по ^O в mc та же самая командная строка ))

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

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

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

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

Вот именно - в большинстве. Но отнюдь не во всех.

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

900к для движка зависимостей и интерфейса к DBus - это как-то слишком дофига.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.