[devel] [Erlang] ограничение на количество потоков в Альте

[Dmitry V. Levin]

On Sun, Nov 21, 2021 at 02:15:00PM +0100, Alexey Gladkov wrote:
> On Sun, Nov 21, 2021 at 04:00:16PM +0300, Dmitry V. Levin wrote:
> > On Sun, Nov 21, 2021 at 01:52:01PM +0100, Alexey Gladkov wrote:
> > > On Sun, Nov 21, 2021 at 01:00:38PM +0300, Dmitry V. Levin wrote:
> > > > On Sun, Nov 21, 2021 at 11:59:26AM +0300, Nikolay A. Fetisov wrote:
> > > > > В Сб, 20/11/2021 в 21:15 +0300, mikhailnov@ пишет:
> > > > > > 20.11.2021 18:04, Nikolay A. Fetisov пишет:
> > > > > > > ...
> > > > > > 
> > > > > > > Механизм ulimit про namespaces ничего не знает, ограничения в 
> > > > > > > security/limits.d/50-defaults.conf считаются по процессам _всех_
> > > > > > > контейнеров. Как итог, можно получить срабатывение ulimit внутри
> > > > > > > полупустого контейнера на, например, запуск задачи по cron.
> > > > > > Почему? cron же пропустит задачу через PAM-стек, а pam_limits
> > > > > > выставит лимиты, ...
> > > > > 
> > > > > ... А дальше ядро сосчитает количество процессов данного UID и сравнит
> > > > > с лимитами. А считаются как минимум до текущего в p10 std-def 5.10.72
> > > > > включительно _все_ процессы без учёта их распределения по namespaces.
> > > > > В результате, имея для примера пару контейнеров с работающими 
> > > > > 255 процессами пользователя, в третьем получаем превышение
> > > > > RLIMIT_NPROC. Хотя у контейнеров nproc по-умолчанию 512,
> > > > > а в хост-системе, например, поднят до 1024.
> > > > > Реально у меня это проявилось на двух машинах с где-то 50 контейнерами
> > > > > каждая.
> > > > > 
> > > > > Так это поведение известное, хотя и неочевидное. Исправление уже есть, 
> > > > > см. https://lkml.org/lkml/2021/2/22/207 - но в наших ядрах как минимум
> > > > > в p10 и ниже этого патча нет.
> > > > 
> > > > Серия изменений v5.14-rc1~153^2~2, призванная решить эту проблему,
> > > > в качестве побочного эффекта позволяет любому непривилегированному
> > > > пользователю превышать ограничения RLIMIT_NPROC и нескольких других
> > > > лимитов путём создания userns и переноса в них своей активности.
> > > 
> > > Дим, твоя фраза в водит в заблуждение. Пользователь внутри userns не может
> > > превысить RLIMIT_NPROC из родительского userns. НИкакого превышение
> > > невозможно.
> > 
> > Я говорю о том, что непривилегированный пользователь с помощью userns
> > может создать процессы, число которых многократно превышает RLIMIT_NPROC.
> 
> Нет. Дим, ты не понял этот патчет.
> 
> При создании userns rlimit_proc (не только он, а все привязанные к
> пользователю) пользователя записывается в userns как max. При создании
> процесса проверка лимита происходит рекурсивно вверх по дереву userns и
> если где-то max превышен, то всё. Ты не сможешь превысить в userns свой
> собственный rlimit_proc.
> 
> Этот патч позволяет _уменьшить_ rlimit_proc в одном userns без поломки
> соседнего userns от такого же пользователя.

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


-- 
ldv