LINUX.ORG.RU

systemd 246

 , , , ,


1

3

Не нуждающийся в представлении системный менеджер для GNU/Linux подготовил очередной релиз за номером 246.

В этом выпуске:

  • автоматическая загрузка правил безопасности AppArmor
  • поддержка проверки шифрования диска в юнитах с помощью ConditionPathIsEncrypted=/AssertPathIsEncrypted=
  • поддержка проверки переменных окружения ConditionEnvironment=/AssertEnvironment=
  • поддержка проверки цифровой подписи раздела (dm-verity) в .service юнитах
  • возможность передачи ключей и сертификатов через сокеты AF_UNIX без необходимости сохранения в файл
  • дополнительный спецификаторы в шаблонах юнитов для различных параметров из /etc/os-release
  • убрана поддержка .include из юнит файлов (была объявлена устаревшей 6 лет назад)
  • убрана поддержка недокументированных вариантов syslog и syslog-console для StandardError=/StandardOutput= в юнитах - вместо этого используются современные опции journal и journal+console
  • автоматические ограничения на размер всех tmpfs монтируемых самим systemd (/tmp, /run…)
  • дополнительные опции для systemd из команды загрузки ядра

И многое другое -см. https://github.com/systemd/systemd/blob/master/NEWS

От себя добавлю что релиз выглядит не столь новаторским как прошлый, добавивший systemd-repart, systemd-homed и userdb. Просто множество различных улучшений, удобств и исправлений.

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

★★

Проверено: alpha ()

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

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

Тогда бы вместе The One Ring получился просто ещё один init. Никто бы и не заметил.

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

запуск сервисов-зависимостей

/bin/service1 && /bin/service2 && ...

перезапуск упавшего сервиса

while :; do /bin/service1 ; done

Я бы посмотрел, как ты это реализовал с помощью полутора строк на баше.

Баш это полноценный ЯП, на нем можно что угодно реализовать.

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

/bin/service1 && /bin/service2 && …

А теперь предположим, что service1 и service2 запускаются по минуте каждый (но при этом процессор не является бутылочным горлышком), service2 требует сеть, а service3 зависит от них обоих. Кстати, перезапускать их нужно строго в обратном порядке. А ещё service1 торчит голой жопой в Интернет, и его бы неплохо засунуть в суровую песочницу, а service2 ограничить до 50% CPU, потому что ну вот так, жопой его писали. Твои действия?

while :; do /bin/service1 ; done

Предположим, service1 демонизируется. Твои действия?

Баш это полноценный ЯП, на нем можно что угодно реализовать.

Но далеко не всегда с помощью полутора строк.

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

конечно, лучше же 20 раз написать cat/grep и путя, чем написать journald и юнит. ах ты ж мамкин гений!

Да просто grep отлично катит. Понимаешь, что проблема унификации логов – это проблема унификации логов, не больше.

предвижу фразу: «ты неосилил таб!!1»

Как будто, с sudo он работает. И если в /var/log/ можно добавить себе +r и [tab] будет катить. То с journalctl – не, нет.

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

Ну вот твоя писанина в данном треде — это однозначно демагогия вперемежку с хамством.

Т.е. мнение о том, что systemd - разжирел, это у нас уже демагогия? очень интересная позиция. Но ты ведь у нас прям светило. Самоуверенное донельзя.

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

Лучшего подарка ты мне даже сделать не мог. Не придется отвечать на самоуверенную болталогию в ответ на мои сообщения. Но уж про твои я - не забуду. Уж поверь. Ты у меня встал в один ряд с reactos-ом.

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

while :; do /bin/service1 ; done

Т.е. инит-скрипт не вернёт управление после запуска вообще никогда? Классная идея!

/bin/service1 && /bin/service2 && ...

Подожди, но по твоей логике зависимости надо тоже в бесконечных циклах запускать, вдруг они тоже упадут? Кроме того, от сервиса могут зависеть несколько других, как предполагается отслеживать все эти связи? А полученного монстра на bash ты потом копипастить с небольшими изменениями в каждый сервис-файл будешь?

m0rph ★★★★★ ()

Как вообще можно быть системным администратором ОС, если херовина, которую ты администрируешь имеет 245 версий и в каждой что-то сделано иначе, чем в предыдущей? Это же адский ад.

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

А полученного монстра на bash ты потом копипастить с небольшими изменениями в каждый сервис-файл будешь?

Сервис-файлы это переусложнение, /etc/rc.bash хватит для всех сервисов.

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

Вполне. Но это на самом деле не имеет никакого значения: даже между отдельными сущностями могут быть жёсткие зависимости. Ты же не жалуешься, что Firefox жёстко зависит от GTK?

Имеет значение лишь то, можно ли их заменить на аналогичные.

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

А теперь предположим, что service1 и service2 запускаются по минуте каждый

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

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

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

Нет, конечно.

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

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

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

Да вот нет. Как только речь заходит о чём-то сложнее стандартной поставки дистрибутива, разница начинает быть очень и очень заметной.

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

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

Да вот нет.

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

Вот и получается, что на синтетических тестах польза видна, а в реальной реальности — не очень.

разница начинает быть очень и очень заметной.

Поделитесь историей из личного опыта?

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

Да вот нет. Как только речь заходит о чём-то сложнее стандартной поставки дистрибутива, разница начинает быть очень и очень заметной.

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

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

Поделитесь историей из личного опыта?

Поделюсь, конечно. Мир не ограничивается докером и кубернетесом.

Есть (был) вот у меня сервер, на котором крутится несколько сервисов на пхытоне и чём-то таком на JVM. Все сугубо stateful и дофига хрупкие, поэтому из кубера вынесены (не моё решение, я бы прикрутил к кластеру провиженинг PVC и дело с концом). Ну каждый стартует там секунд по 30-100, а раньше они при этом ещё и общались друг с другом. Сервисов всего порядка десяти штук. Удачи с последовательным запуском.

Ну и заметка на полях — если бы тот же кубернетес стартовал поды по порядку, ты бы тоже кричал «параллельный запуск не нужен, последовательного хватит всем»? :)

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

Есть (был) вот у меня сервер, на котором крутится несколько сервисов на пхытоне и чём-то таком на JVM. Все сугубо stateful и дофига хрупкие

Ну кто-бы сомневался-то. Уже даже и удивления - не вызывает, что то, что у тебя крутиться такого качества, что даже дунуть страшно. Но это - лирика. ну стартуют долго, и? В чем проблема распаралеливания? Ах - надо программировать научиться? зачем, если можно взять монстра, в котором от изначальной идеи, параллельного запуска, уже мало что осталось и понапихать туда криворукие «хрупкие» поделия. Никто не говорит, что идея systemd изначально ненужное барахло. Люди говорят, что он разжирел и принял в себя кучу ненужного. Но ты, как светило, которое за своим светом не видит уже совсем ничего, никак не в состоянии это осознать. У тебя одно собственное мнение имеет значение. Нимбанутое.

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

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

Ну да, как послушать ЛОРовцев, так их софт не течёт, не падает и потребляет отрицательное количество памяти :) Оно и понятно, 5.1здеть — не мешки ворочать.

В чем проблема распаралеливания? Ах - надо программировать научиться?

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

P. S.: макском, почини игнор.

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

Есть (был) вот у меня сервер,

Железный или виртуальный? Если железный, то сколько времени проходило между админ нажал на кнопку включения и «сервере сделал вжух-вжух, можно приступать к загрузке OS»?

несколько сервисов на пхытоне и чём-то таком на JVM … каждый стартует там секунд по 30-100

Жуть. В этой ситуации, параллельный запуск, конечно, оправдан.

если бы тот же кубернетес

А я разделяю задачи инициализации системы и оркестрации микросервисов, не валю всё в одну кучу.

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

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

строго говоря, в sysvinit запилили insserv и startpar для таких сценариев. А зависимости systemd сделаны, мягко говоря, через одно место.

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

строго говоря, в sysvinit запилили insserv и startpar

Читай «костыли на соплях». Но хорошо, допустим. Речь не о sysvinit, а о нужности параллельного запуска.

А зависимости systemd сделаны, мягко говоря, через одно место.

Раскрой мысль.

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

Ну да, как послушать ЛОРовцев, так их софт не течёт, не падает и потребляет отрицательное количество памяти :) Оно и понятно, 5.1здеть — не мешки ворочать.

Так я так и не услышал, что там у тебя в реальной практике так требует полного функционала systemd? Только какие-то сказки про абстрактное кривонаписанное барахло. И меня реально нисколько не удивляет, ни барахло в комплекте с тобой, ни применение тобой монстра для управления подобным хозяйством. Примеров - реальных, а не «несколько сервисов на пхытоне и чём-то таком на JVM. Все сугубо stateful и дофига хрупкие», мы так и не увидели. Что, разумеется, нисколько не удивляет, учитывая, кто этоим всем управлял/управляет. Да-да. Я имею в виду именно - тебя. Наверное, для исправления ситуации нужно начать прислушиваться к мнениям других людей, а не только самоуверенный нимб носить.

Ни в чём. Просто его уже сделали за меня, причём намного более качественно и аккуратно, чем я

тут - вообще без комментариев. Я и говорю - раздвоение личности. вам надо срочно на Загородный проспект в городе-герое Москве. Там вам - помогут.

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

https://blog.darknedgy.net/technology/2020/05/02/0/index.html - ну вот, например, статья. И вот к какому выводу там приходят:

What the Requisite= example vividly shows is that systemd dependencies are not additive, nor are they constraints, invariants or ‘checks’ of any kind that one might intuitively expect. Combining dependencies overrides and supersedes behavior rather than enforcing more constraints, since all of these dependency directives are coarse-grained ad hoc instructions with numerous side effects that range from events, relationships, and ordering to their propagation effects

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

Железный или виртуальный?

Арендованная виртуалка.

А я разделяю задачи инициализации системы и оркестрации микросервисов, не валю всё в одну кучу.

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

Иначе получается «шутка-самосмейка» — кольцевой аргумент, который обосновывает сам себя, только если изначально принять его на веру.

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

Примеров - реальных, а не «несколько сервисов на пхытоне и чём-то таком на JVM. Все сугубо stateful и дофига хрупкие», мы так и не увидели.

Может тебе ещё и исходники продукта с прошлой работы притащить?

Так я так и не услышал

Ты сначала определись, что ты хочешь услышать. А то в каждом своём сообщении (которое я почему-то всё ещё вижу) ты почему-то «хочешь услышать» совершенно разные вещи. Отличная тактика, но нет.

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

К чьим мнениям-то? Хамящего юникс-вытирана с ЛОРа? Насмешил.

И да, видишь ли, ситуация не требует исправления. У меня всё замечательно работает.

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

А зачем?

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

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

А зачем?

Потому, что это - логично. Ты знаешь, что такое - логика?

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

Т.е. по вашему выходит, что инициализация системы и ее дальнейшее управление, это одно и тоже? Как интересно. Давайте тогда понапихаем все это барахло, скажем, в grub2. А что - вполне себе идея, с такой-то «божественной» и «верной» идеологией, как у вас, mon chere. Можно еще дальше пойти. И позапихать все в efi. Единственно, конечно, вас не поймут производители материнских плат и тут уж точно они наймут крепких санитаров, для успокоения буйнопомешаных на монолитных системах типа systemd.

DrRulez ()

Кароче словил я notabug: компьютер долго выключается или перезагружается. Ничего нового.

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

С иными системами инициализации такого никогда не было, фишка systemd. Ну да ладно.

Вербальный лог на экране ничерта не говорит. A stop job is running for Session c1 of user ntfs (1min 30s). Ну да ладно.

Загуглил на тему «как понять, WTF». И вы таки удивитесь, ответы - включить логгирование всего, storage=prsistent, и написать в автозагрузку скрипт который будет сохранять dmesg в файл чтобы потом можно было его прочитать.

Это же просто ЛОЛ. Комбайн, который влез уже везде даже в загрузчик, не может мне сказать по-человечески, какой сервис долго завершается ?!

Если бы не авторитарная политика RH, этот шлакd бы почил в бозе, и никто бы о нем уже не вспоминал тащемта.

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

Потому, что это - логично. Ты знаешь, что такое - логика?

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

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

Конечно.

Давайте тогда понапихаем все это барахло, скажем, в grub2.

Можешь собрать ядро как GRUB2-модуль. И не надо разводить никакой демагогии. Что сказать-то хотел?

Можно еще дальше пойти. И позапихать все в efi.

Я могу вкомпилить initramfs в ядро, а ядро с EFISTUB вкомпилить в прошивку как UEFI executable. Так, в общем-то, вполне делают в очень узкоспециализированных случаях.

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

Хамло.

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

Может тебе ещё и исходники продукта с прошлой работы притащить?

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

Ты сначала определись, что ты хочешь услышать.

так и быть. Для носящих нимб самоуверенности я поясню еще раз. Назови конкретные, практические задачи, которые требуют реального применения всего функционала systemd. и не образных «сервис1, общается с сервис2 и зависит от глюканиия сервис3», а реальных задач, которые требуют весь фукционал (это не опечатка) кадавра systemd.

И да, видишь ли, ситуация не требует исправления. У меня всё замечательно работает.

ахахаха. замечательно работает. Т.е. ситуация, когда все «хрупкое» у тебя является "замечательной работой? Я даже представить в таком случае боюсь, что в твоем понимании «незначительный инциндент» :) Не иначе как это полный пи-ц, когда пользователи бегут к тебе со сковородками на перевес и начинают бить тебя по нимбу. Тогда, да, конечно, понятно, откуда такая любовь к разжиревшему systemd-кадавру.

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

Если вычесть Docker-образы, то останется полтора локалхоста. Такая себе популярность.

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

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

Можешь собрать ядро как GRUB2-модуль. И не надо разводить никакой демагогии. Что сказать-то хотел?

Я могу вкомпилить initramfs в ядро, а ядро с EFISTUB вкомпилить в прошивку как UEFI executable. Так, в общем-то, вполне делают в очень узкоспециализированных случаях.

Кто-то еще, после всего вышенаписанного, сомневается в психическом здоровьи данного персонажа? Я - уже в точности уверен, что, человек, который считает нормальным впихивать функционал системы в загрузчик и в систему изначальной аппаратной инициализации, не сильно дружит с той самой логикой (если не сказать больше - с головой), о которой он так красноречиво описал в своем сообщении.

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

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

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

Данные слова требуют обоснования

Прибивание udev и login гвоздями к системд это не переусложнение? Те же бинарные логи, для чтения которых нужно изобретать велосипеды? homed и repart это не переусложнение? А systemd-boot? Завязывание GDM на systemd? Одним словом, считается ли попытка запустить щупальца во все компоненты системы переусложнением? В то время, как openrc обладает всеми фишками системд как инита, но не пытается лезть во все и вся и весит 900 килобайт? systemd в чем-то похож на snap. В обеих случаях хорошая идея убивается отсутствием четко определенных целей и, как следствие, убогой реализацией.

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

systemd - лучшее, что случалось с Linux

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

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

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

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

Прибивание udev и login гвоздями к системд это не переусложнение?

нет, это вендорлок. попробуй загрузить линукс без udev, а кто у нас имеет право на комит?

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

примеры сломанных юнитов и ссылки на багтрекер - это отсебятина?

Там такой говнокод, что, например, сам Поттеринг не рекомендует использовать Conflicts= в общем случае. В манах про это, конечно же, ни слова.

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

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

anonymous ()

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

balsoft ★★ ()