LINUX.ORG.RU

Вышел cgroups v2

 , , ,


2

2

Инженер Facebook Tejun Heo объявил о выходе cgroups v2. Полностью переделанная версия механизма cgroups уже доступна в mainline и будет включена в релиз Linux 4.5.

cgroups v2 сфокусирован на предоставлении единого, универсального и продуманного интерфейса (в то время как v1 очень беспорядочен и непоследователен). В частности, в v2 есть только одна унифицированная иерархия, per-process. Все контроллеры теперь жестко иерархические и ведут себя стандартизированным образом. Работающие, четко определенные soft limits для котроллера памяти, теперь не надо полагаться на тюнинг OOM killer'а. Работающий resource control для writeback IO.

Механизм ядра cgroups широко используется такими важными и популярными инструментами, как Docker, Hadoop, Kubernetes, LXC, Mesos и CoreOS. cgroups v2 уже обкатан в продакшене в Фейсбуке, хотя в ближайшем будущем ожидается несколько больших интересных нововведений, которые стали возможны благодаря редизайну.

>>> Пост в FB

★★★★★

Проверено: Pinkbyte ()
Последнее исправление: Wizard_ (всего исправлений: 3)

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

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

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

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

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

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

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

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

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

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

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

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

Чо?!!?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из 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

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

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

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

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

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

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

Вот это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я не нашёл.

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

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

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

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

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

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

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

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

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

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

Для чего?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не видно

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

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

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

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

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

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

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