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

Alexey Gladkov legion на altlinux.ru
Вс Ноя 21 16:15:00 MSK 2021


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 от такого же пользователя.

Например, у тебя rlimit_proc=10 и ты можешь запустить 10 userns с
rlimit_proc=1. Но вот 11 таких контейнеров запустить не получится и внутри
не получится запустить больше 10 процессов суммарно.

> Речь идёт о том, что, насколько я понимаю, при включённом unprivileged userns
> эффективное значение RLIMIT_NPROC следует умножать на величину
> 1 + $(cat /proc/sys/user/max_user_namespaces).

Нет. Ты неправильно понимаешь.

-- 
Rgrds, legion



Подробная информация о списке рассылки Devel