Вышел cgroups v2

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

Зачем? Просто следи за новостями на ЛОРе. «В ядре Linux исправлена опасная уязвимость. Она присутствует начиная с 4.5 и до 5.1, в RHEL8 и Ubuntu 20.04 уже пришёл фикс. Баг оказался в cgroups, и он может теоретически дать все права взломщику. Рекомендуется обновиться как можно быстрее».

Нет, там использовались стандартные сцгруппы одна cgroup_root (больше не примонтируешь), ну и в какой-то момент они стали по дефолту одну иерархию со всеми контроллерами делать, убив половину идеи.

Исключительно ради этого и затевался systemd.

Это утверждение не имеет ничего общего с действительностью.

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

Чо?! Это ты про release_notification так? Ну так это наименьшая из проблем, которую поправили тупо заодно.

Возможность введения UH была одним аргументов Поттеринга по поводу дизайна systemd и необходимости объединения функционала PID 1 и менеджера cgroups. Да и внедрения systemd вообще.

Чо?!!?

Или я в альтернативной реальности?

В документации в /usr/SRC/Linux/Documentation есть, и UH позволяет его ещё расширить, документация по UH тамже

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

Хоть 15, но в systemd эти радостно вело к гонкам и там было предложено,чтобы был один менеджер, эта же идея продвигается и в UH, но я честно не помню деталей того, к чему в итоге там пришли.

UH в ядре доступно достаточно давно и его включение планировалось раньше, если я правильно помню, бери да конфигуряй, только возьми инит попроще тогда

О, когда они таки это сделали?

Да нет, к гонкам вело не это. Я помню, Леннарт жаловался, что со старыми cgroups в каких-то случаях невозможно адекватно получать нотификации об опустошении цгрупп, и им приходилось при остановке пользовательской сессии отсылать ей сразу SIGKILL (чтобы всё сдохло сразу, а не постепенно, потому что оповещения о сдыхании могут не сработать). Именно оттуда росли баги вида «у меня история в баше не сохраняется». А теперь типа всё хорошо и замечательно.

Что касается одного менеджера — они просто морально готовили всех к тому, что через какое-то время введут UH.

В 226.

Нет, они до всегда делали по одной иерархии на контроллер. Но иерархии были идентичными, да.

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

Вот и я не помню деталей. Гугл не помогает, а подробнее искать лень. Я некоторое время назад много чего перерыл в поисках объективной критики systemd. Не нашёл... А детали просмотренных срачей уже позабыл. Надо нафиг дневник начинать вести.

Как я помню, всё-таки планировалось что менеджер в юзерспейсе будет один. Но не из-за гонок в systemd а ради упрощения cgroups.

systemd капец или Поцеринг предложит groupsd?

Нет. Скорее, systemd начало.

В чём проблема в любом дистрибутиве собрать своё ядро из транка?

В том что в соседней аптеке упорин форте закончился.

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

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

Как я понял, в cgroups2 это уже неактуально. Например, можно делегировать часть иерархии процессу, запущенному под юзером (systemd --user, ага).

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

Да-да, теперь можно делегировать. Под это дело в юнитах даже специальную директиву запилили, правда, к чему конкретно она приводит — я не знаю (в код не смотрел).

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

Да, после того как со стороны ядра его объявят годным и стабильным.

Я некоторое время назад много чего перерыл в поисках объективной критики systemd. Не нашёл.

И какими же критериями объективности ты руководствовался? Какой критики ты искал? Критики его функциональности? Только такую критику ты назвал бы объективной?

Так я тебе замечу, что когда кто-то, открыто, без палева заталкивает в систему трояна, он не заинтересован в том, чтобы его поделие подрывало ее работу. Напротив, он заинтересован в том, чтобы все рукоплескали трояну, — на то он и троян.

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

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

эта его функция — поглощение контроля над системой — ПЕРВИЧНА, а та функциональность, которой он прельщает разработчиков и пользователей — лишь наживка, а не цель его существования.

Есть хороший принцип

зачем мне победа, которая не будет моей?

Адаптируя к нашей ситуации

зачем мне линукс, который не будет свободным?

Может systemd и привнесет в линукс определенные технические преимущества. Но если он позволит redhat взять под контроль свободную ось, то нахер мне эти технические преимущества?

Очевидно, неважно и непопулярно.

И какими же критериями объективности ты руководствовался?

Например,

без палева заталкивает в систему трояна

поглощение контроля над системой

зачем мне линукс, который не будет свободным

позволит redhat взять под контроль свободную ось

Являются примерами плохой, негодной критики. Кроме того, не соответствуют действительности.

история оттеснения пользователя от контроля над системой.

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

Это один из примеров противонаправленности двух слоев функциональности: одной рукой системд подкармливает меня удобствами, а другой лишает контроля над ситуацией, деалая себя незаменимым.

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

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

Я не нашёл. Хотя, много и целенаправленно искал.

Эй, это не ответ.

И встало несколько вопросов: нахера мне журнал, который я не могу прочитать? Зачем мне все эти няшные форматирования и фильтрации, разбиение по сессиям, если с журнала нет толка, на мертвой системе его просто не прочтешь?

Я легко читал через journalctl журнал соседней системы, которая не загружалась. Не пойму какая проблема тут может быть.

Из journalctl --help:

-D --directory=PATH      Show journal files from directory
     --file=PATH           Show journal file
     --root=ROOT           Operate on catalog files below a root directory

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

Кроме того, не соответствуют действительности.

Что именно не соответствует действительности? Это

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

Это правда, очевидная. Или за лесом деревьев не видно?

Вот это

эта его функция — поглощение контроля над системой — ПЕРВИЧНА, а та функциональность, которой он прельщает разработчиков и пользователей — лишь наживка, а не цель его существования.

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

В частности обратить внимание на полное отсутствие чего либо общего между декларировавшимися целями и результатом внедрения systemd.

Они обещали упрощение системы а мы имеем многократное усложнение. Они обещали только систему инициализации, — мол мы на полшишечки, мы не местные, а мы имеем что? По самые помидоры.

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

У меня нет «соседней системы». Это раз. Во вторых,

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

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

У меня нет «соседней системы»

А как вы собираетесь читать плейнтекстовый журнал умершей системы? :DDDDD

Тоесть ты согласен, что без него я не могу читать журнал?

А без хотя бы nano или grep - сможете? Не вижу разницы между набором nano, grep или journalctl в терминале. Хотя да, journalctl это длинновато.

Я не нашёл.

От тебя и не ожидалось.

Хотя, много и целенаправленно искал.

Как ты умеешь искать ты уже показал.

Не вижу разницы между набором nano, grep или journalctl в терминале.

Я разницу сильно почувствовал, когда пришлось chroot'иться

Не вижу разницы

Всем даны глаза но всем дано видеть

Я разницу сильно почувствовал, когда пришлось chroot'иться

Для чего?

Всем даны глаза но всем дано видеть

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

Для чего?

Чтобы запустить сраный journalctl

В рабочей системе его не было?

я с лавсиди грузился. Древней мандривы.

В рабочей системе его не было?

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

Ну cpuacct, и cpuset были объединены почти всегда.

я с лавсиди грузился. Древней мандривы.

И в чём тут вина systemd - в том, что он так поздно появился? Угар какой-то.

И опять, ты опять подтверждаешь его незаменимость, то есть именно то, о чем я говорил

grep ещё более незаменим. А во многих дистрибутивах даже nano нет искаропки.

Ну гонки не в systemd, а со стороны cgroups, если несколько процессов по цгруппам процессы перекидывают, то цгруппам становится плохо, вроде в кернел доках это должно быть. Я читал примерно когда документация по UH там появилась, тогда в systemd ещё поддержки не было.

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

В чес проблема с делегировантес раньше? Все прекрасно делалось, если проигнорировать иерархии контроллеров, с которым были проблемы (но не с правами)

grep ещё более незаменим.

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

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

Или за лесом деревьев не видно?

Всё видно. Не видно *объективной* критики. Т.е. не видно *измеримых* и *воспроизводимых* результатов. Я уж молчу подробном онтологическом и семиотическом анализе systemd.

Всё что есть — одна сплошная болтовня, навроде генерируемой тобой. Никакой информации в этом наборе букв — нету. Один сплошной поток сознания, незамутнённого в своей упоротости.

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

Поправочка: cpu и cpuacct. Да, за исключением этих двух.

Да, они мне за каждый коммент тут платят. А ваша аватарка висит в нашем офисе, мы в неё дротики кидаем.

Я не помню сейчас. В чём проблема с делегированием была, тоже не помню. Там вроде не «проблема» per se, а просто некрасивое/гипотетически несекьюрное решение получалось.

Не видно *объективной* критики.

Вернулись к тому, с чего начинали

Не видно

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

То, что по ссылке, — это не объективная критика, а размахивание языком и громкими словами. «Прогнозировать» что-либо тебя никто не просил.

это не объективная критика

И что конкретно в ней не объективно. Я уже задавал вопрос — в чем конкретно я не прав? Можно на него объективно ответить?