LINUX.ORG.RU

systemd 256

 ,


0

2

Cвободный (GPLv2+) системный менеджер GNU/Linux порадовал поклонников очередным релизом.

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

  • убрана поддержка старых cgroups v1 по умолчанию;
  • поддержка старых скриптов System V объявлена устаревшей, её планируется убрать в одном из следующих релизов;
  • добавлена поддержка допконфигов (drop-ins) для systemd-udevd;
  • в systemd-creds добавлена поддержка секретов для непривелигированных пользователей;
  • аналог опции юнита ProtectSystem= добавлен к системному менеджеру и включён по умолчанию в initrd – соответственно, код из initrd не сможет писать в /usr;
  • новый спецификатор %D в описании юнита – раскрывается в $XDG_DATA_HOME или /usr/share/ для пользовательских и системных юнитов соответственно$
  • интерфейс Varlink добавлен к systemd-networkd и systemd-hostnamed;
  • добавлена концепция капсул – группа юнитов под контролем отдельного экземпляра пользовательского systemd: фактически эквивалента запуску сервисов под отдельным пользователем без необходимости явно создавать этого пользователя – см. доки;
  • journal получил поддержку отправки логов (в формате JEF) в сокет что позволило организовать доставку логов из виртуалки, запущенной systemd-vmspawn на хост даже при отсутствии поддержки сети у гостевой системы;
  • systemd-run получил алиас run0 который работает как аналог sudo с контролем привелегий с помощью PolKit;
  • множество других замечательных нововведений и улучшений.

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

★★★★★

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

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

И как много UNIX-like это поддерживают?

А как много unix-like актуальны?

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

Почти рандомный пример из серии «пальцем в небо»:

systemd-boot is a free and open-source boot manager created by obsoleting the gummiboot project and merging it into systemd in May 2015 (источник).

Вы уж там определитесь, трусы или крестик.

То, что не все компоненты systemd являются обязательными, я в курсе. Но они носят в своём названии слово systemd и, как видно по цитате выше, признаются его частями. Ну или иди в Википедию и объясняй им, что они написали ерунду. И даже если получится, вопрос, почему он именно systemd-boot, остаётся в силе. В начале было слово, как говорится.

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

То, что не все компоненты systemd являются обязательными, я в курсе. Но они носят в своём названии слово systemd и, как видно по цитате выше, признаются его частями. Ну или иди в Википедию и объясняй им, что они написали ерунду. И даже если получится, вопрос, почему он именно systemd-boot, остаётся в силе. В начале было слово, как говорится.

Компоненты openbsd тоже носят в себе ее название, но являются ее частями. Тебе это мешает пользоваться openssh?

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

Моновендорность - это не очень хорошо

Какая ещё моновендорность у открытого проекта который может форкнуть любой желающий и куда контрибьютят представители всех ключевых дистрибутивов GNU\Linux? Даже на ЛОР есть люди чьи патчи приняли в systemd.

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

когда-то ЛОР крутился на фряхе

Ты реально идиот именно в медицинском смысле? У тебя функциональная неграмотность? Как это соотносится с текстом на который ты отвечаешь? Что и кому это доказывает? Ты вообще понимаешь смысл текста который читаешь?

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

Ну или иди в Википедию и объясняй им

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

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

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

Если да, тогда что ты делаешь на айтишном форуме?

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

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

когда-то ЛОР крутился на фряхе

… и был написан на php

На пёрле, вообще-то.

P.S. На щёт фряхи - меня чё-то берут большие сомнения. Вроде как со старта на красношапке было.

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

Видимо истинная причина хейтерства systemd в том что проект посмел выпустить документацию не в формате аниме-сериала

Тогда поборники духовности будут возмущены. После самоубийства очередного депрессивного подростка окажется, что этот подросток смотрел аниме. И документацию к systemd запретят к чертовой бабушке :)

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

merging it into systemd

merging into systemd следует понимать как слияние репозитариев. От того, что systemd-boot теперь находится в том же git-репозитарии что и systemd, не следует, что systemd-boot являеется неотделимой частью systemd. В дебиане он вообще отдельным пакетом идет.

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

Иниту и в принципе системному менеджеру не нужен быстрый прогресс. Оно уже перешло в фазу молотков и чайников: система запущена? запущена. Сбои обработаны, упавшие юниты переподняты? Отлично, большего не требуется. +/- 5с на запуске роли не играют, любое супер-мега-улучшение это всего лишь 0,1% на третьестепенной фоновой задаче и если там требуются какие либо, любые, изменения со стороны софта - это принесёт ненужные проблемы.

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

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

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

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

Там не просто прочитать надо, там ещё и понять требуется, а для этого нужен работающий мозг.

Интересно, если в доке написано «опция Х= делает Х если выполнено условие У», то для прокачанного (веществами?) мозга это видимо означает что опция Х на самом деле задаётся через Z=, условие У устарело 2 версии назад и теперь нужно процерять условие W и дополнительно прописать V= для всех предшествующих юнитов дерева.

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

Нет, это сделает systemd.

А системд тоже сам напишет новый юнит чтобы новое действие легло в нужный момент?

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

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

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

Ты ведь в курсе, что топологическая сортировка дерева из 100-200 элементов займёт ну максимум 10 мс?

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

Вместе с чтением, парсингом и генерацией виртуальных юнитов?

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

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

Вместе с чтением, парсингом и генерацией виртуальных юнитов?

# time systemctl daemon-reload                                                                                                                                                                   
systemctl daemon-reload  0,01s user 0,01s system 3% cpu 0,422 total

Это синхронная операция, включающая в себя вообще всё. Приведённое время — у меня на ультрабуке восьмилетней давности.

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

Хуже ламера — только ламер самоуверенный (c)

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

у вас полагается затыкать рты

См. первую строчку моего профиля после списка железа.

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

на фоне существования не менее гибких альтернатив

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

ламерами осваиваются и делают практически всё то же самое

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

следовало избавиться ещё

И по этой же причине твоё мнение об архитектуре интересует разработчиков systemd и создателей дистров не больше чем мнение свиньи о яблоках интересует создателя сидра.

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

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

Граф зависимостей нужен не для ускорения загрузки. Собственно, целью создание systemd было облегчение управления системой. Ускорение загрузки — это просто приятный бонус, но не самоцель

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

Но ламеры по определению не обладают ни экспертизой, ни интеллектом чтобы произвести адекватную оценку.

Специалиста в чём то можно узнать по 2-м признакам: во первых он не станет рассуждать про то что все вокруг ламмеры и нихрена не понимают, особенно в контексте «я прав, вы нет». А во вторых - потратит всё то же самое время не на словестный понос а на пару-тройку конкретных примеров почему runit/upstart принципиально хуже системд ну хотябы чтобы не напрягаться, потому что они сами по себе выскользнут из его памяти.

А ещё есть третье соображение из области здравого смысла и житейской мудрости: грамотно спроектированная система должна быть простой в использовании. Задача вмешательства в запуск ОС/программы/службы это что, кунг-фу для избранных? Нет, **ять!!! Это должен делать эникейщик после двухчасового чтения мануала! Причём с возможностью не просто вкл/выкл, но ещё и поправить на ходу если что то пошло не так.

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

Это конечно хорошая идея, но за время пути граф успел подрасти. Начиная с какого то момента сложность вопроса «что я должен прописать в юните чтобы он выполнился после монтирования ФС но до запуска ХХХ?» должна превысить возможности человека, сидящего перед консолью с systemctl и nano. И лично для меня - давно и значительно превысила.

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

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

Это конечно хорошая идея, но за время пути граф успел подрасти. Начиная с какого то момента сложность вопроса «что я должен прописать в юните чтобы он выполнился после монтирования ФС но до запуска ХХХ?» должна превысить возможности человека, сидящего перед консолью с systemctl и nano.

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

В этом случае самый тупой и архаичный костыль init’а, реализующий линейную последовательность действий на основе последовательности чтения файлов в папке может эффективней решить задачу

В случае, если ты не осилил документацию?

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

на пару-тройку конкретных примеров

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

Это должен делать эникейщик после двухчасового чтения мануала

Всё так. Тот факт что ты до сих пор этого не осилил показывает лишь то, что ты тупее эникейщика.

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

И лично для меня - давно и значительно превысила.

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

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

стабильной параллельности

в openrc есть stacked runlevels, и они отлично работают

зависимости старта сервиса от точки монтирования

не нужно при наличии inotifywait

если не встроенного, то хотя бы интегрированного журнала

а, я понял. Ты фанат кучи магических настроек в юнитах, вместо какого-нибудь элементарного | s6-log в строке запуска. Это не считая того, что в openrc есть rc_logger.

пользовательских юнитов

чтобы пользоваться ими в сустемд, нужно

  • передать в сустемд все нужные переменные среды
  • создать специальный таргет
  • прописать в пользовательские юниты зависимость от этого таргета
  • прописать запуск этого таргета в конфиге WM

очевидно что подобная архитектура - ненужная переусложненная хрень, и намного проще оставить в ней только последний пункт, запуская пользовательский супервизор (например s6-svscan) напрямую из конфига WM.

встроенной супервизии

есть supervise-daemon.

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

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

в openrc есть stacked runlevels, и они отлично работают

Причем тут это?

не нужно при наличии inotifywait

Каким образом это связанные вещи, объясни пожалуйста? Я бы ещё понял, если бы ты сказал «при наличи mountpoint», но это все костылищи.

а, я понял. Ты фанат кучи магических настроек в юнитах, вместо какого-нибудь элементарного | s6-log в строке запуска.

В s6-log нет НИЧЕГО элементарного. s6 это вообще наименее userfriendly замена иниту. Самое смешное, что это даже автор признает и клянчит деньги на фронтенд.

Это не считая того, что в openrc есть rc_logger.

Который либо не установлен, либо установлен в «logger» и шлет все в один syslog где тебе надо руками все разгребать :)

чтобы пользоваться ими в сустемд, нужно

Написать юнит в десять строк. Вот, смотри:

[Unit]
Description=Syncthing - Open Source Continuous File Synchronization
Documentation=man:syncthing(1)

[Service]
ExecStart=/usr/bin/syncthing serve --no-browser --no-restart --logflags=0
Restart=on-failure

[Install]
WantedBy=default.target

ТАДАМ. Вы великолепны.

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

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

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

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

Во-вторых, для решения этих вопросов есть документация.

У инита тоже. И может даже длинная, сложная и правильна, но там есть ключевые 2-3 абзаца которые необходимы и достаточны в 99,99% случаев.

В случае, если ты не осилил документацию?

Ок, аналогия. На Матизе масляный картер свободно доступен снизу. В принципе можно почитать документацию, но и так понятно что если течёт - открути эти болты и поменяй прокладку/помаж герметиком. На Ниссан Х-трэйл масляный картер доступен после снятия всей передней подвески и то ли обоих радиаторов, то ли кондиционера. Всё это великолепно описано в целой главе мануала, качественного перевода на русский просто не существует, как и не существует адаптации для стандартного набора инструментов вместо нисанновских сервисных наборов съёмников. Результат: стоимость обслуживания Х-трэйла раз в 10-50 раз выше, время простоя больше, ремонт в гаражных и домашних условиях почти невозможен, а вероятность ремонта и дополнительных повреждений в сервисном центре примерно равна. Или обобщая: у Матиза 12 года совершенно логично не течёт масло, а у Х-трэйла 12 года - течёт, и это проще признать нормой чем исправить.

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

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

В s6-log нет НИЧЕГО элементарного

еще и тупой получается, иди маны покури

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

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

Я не знаю, ты написал очень много страшных буков. Я показал, что они не имеют к реальности отношения, ведь все что мне потребовалось чтобы сделать user unit – написать вот эти строки. И все работает. Значит, ты балабол?

еще и тупой получается, иди маны покури

Зачем? У меня systemd, там все работает из коробки и никакого пердолева с шизофренией skarnet.

Напомню как выглядит конфиг s6-log:

s6-log n30 E500 - +fatal: 2 - +^STAT =/var/log/foobard/status f s10000000 S15000000 T !"gzip -nq9" /var/log/foobard
cumvillain
()
Последнее исправление: cumvillain (всего исправлений: 3)
Ответ на: комментарий от cumvillain

ExecStart=/usr/bin/syncthing

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

#!/bin/sh
/usr/bin/syncthing serve --no-browser --no-restart --logflags=0
kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Кстати, вот почему системд считает, что для запуска демона достаточно одной команды а типичный инит-скрипт имеет размер в 10Кб, там отдельно определён сценарий запуска, сценарий остановки и сценарий рестарта?

Да нет, в openrc это тоже три переменные. Просто openrc пользовательские юниты тоже через жопу умеет, как и все остальное.

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

Но системд не может определить отдельный сценарий завершения и отдельный для рестарта! Как и выполнить запуск в несколько действий.

kirill_rrr ★★★★★
()

systemd-run получил алиас run0 который работает как аналог sudo с контролем привелегий с помощью PolKit;

У pkexec нашли фатальный недостаток.

поддержка старых скриптов System V объявлена устаревшей, её планируется убрать в одном из следующих релизов;

Офигели, они так кучу софта поломают.

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

Или вот ещё одна странная архитектурная химера: он принципиально работает только с полными путями. А что если системе нужно по-быстрмоу глобально переключать версии каких нибудь питонов или джав просто перееопределяя PATH?

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

Или вот ещё одна

Ты хотел сказать «первая», потому что остальные – твое непрочтение мана.

странная архитектурная химера: он принципиально работает только с полными путями. А что если системе нужно по-быстрмоу глобально переключать версии каких нибудь питонов или джав просто перееопределяя PATH?

Так делают все сервисные менеджеры, оло. И systemd, и openrc, и даже rc в OpenBSD, который по сути тупо обвязка на pkill.

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

Это команды а не сценарии. Ну типа там примонтировать, скопировать, разархивировать, запустить 3 бинарника, подождать, один прибить, второму послать команду по ssh.

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

Это команды а не сценарии. Ну типа там примонтировать, скопировать, разархивировать, запустить 3 бинарника, подождать, один прибить, второму послать команду по ssh.

Засунь это в скрипт.

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

Так делают все сервисные менеджеры

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

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