Re: [devel] [#290158] FAILED del=python-module-yaml

Re: [devel] [#290158] FAILED del=python-module-yaml

[Dmitry V. Levin]

On Sat, Nov 20, 2021 at 02:58:43AM +0000, Girar awaiter (cleaner) wrote:
> http://git.altlinux.org/tasks/290158/logs/events.1.1.log
> 
> 2021-Nov-20 02:54:21 :: task #290158 for sisyphus started by cleaner:
> 2021-Nov-20 02:54:21 :: message: Final removal of 13+ weeks x86_64 ftbfs package

Коллеги, слово Final означает, что других вариантов не осталось,
и пакет будет удалён.

> #100 delete python-module-yaml
> 2021-Nov-20 02:54:23 :: build check OK
> 2021-Nov-20 02:54:23 :: noarch check OK
> 2021-Nov-20 02:54:26 :: plan: src +0 -1 =17408, aarch64 +0 -2 =29133, armh +0 -2 =27472, i586 +0 -2 =29733, ppc64le +0 -2 =28916, x86_64 +0 -2 =30370
> 2021-Nov-20 02:56:09 :: patched apt indices
> 2021-Nov-20 02:56:29 :: created next repo
> 2021-Nov-20 02:56:44 :: duplicate provides check OK
> 	x86_64: NEW unmet dependencies detected:
>  llvm11.0-tools#11.0.1-alt4:sisyphus+289472.200.2.1@1636807238  python2.7(yaml)
> 	i586: NEW unmet dependencies detected:
>  llvm11.0-tools#11.0.1-alt4:sisyphus+289472.200.2.1@1636807474  python2.7(yaml)
> 	aarch64: NEW unmet dependencies detected:
>  llvm11.0-tools#11.0.1-alt4:sisyphus+289472.200.2.1@1636810968  python2.7(yaml)
> 	ppc64le: NEW unmet dependencies detected:
>  llvm11.0-tools#11.0.1-alt4:sisyphus+289472.200.2.1@1636811675  python2.7(yaml)
> 	armh: NEW unmet dependencies detected:
>  llvm11.0-tools#11.0.1-alt4:sisyphus+289472.200.2.1@1636813636  python2.7(yaml)
> 	ACLs of affected packages (1):
>  llvm11.0  shrek arseny @everybody
> 2021-Nov-20 02:58:43 :: unmets: x86_64 +1 -0 =1, i586 +1 -0 =1, aarch64 +1 -0 =5, ppc64le +1 -0 =5, armh +1 -0 =19
> 2021-Nov-20 02:58:43 :: dependencies check FAILED
> 2021-Nov-20 02:58:43 :: task #290158 for sisyphus FAILED


-- 
ldv

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

[Илья Курдюков]

Почему в нормальных системах этот код возвращает 10000 с плюсом, а в 
Альте 500 с чем-то?

$ cat threadlim.c
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>

static void* test(void *data) { while(1) sleep(1); return NULL; }

int main() {
     int i, err = 0;
     pthread_t t;
     for (i = 0; !err && i < 100000; i++)
       err = pthread_create(&t, NULL, test, NULL);
     printf("i = %d, err = %d\n", i, err);
     exit(0);
}
$ cc -O2 -pthread threadlim.c && ./a.out
i = 507, err = 11

ulimit -u стоит по умолчанию на 512 и не даёт поставить выше 1000:

$ ulimit -u
512
$ ulimit -u 1000
$ ulimit -u 1001
-bash: ulimit: max user processes: не удаётся изменить ограничение: 
Операция не позволена

Эти ограничения с начала времён не меняли?

http://git.altlinux.org/gears/e/erlang.git

Почему в спеке Erlang делаются костыли с уменьшением количества потоков, 
вместо того, чтобы наконец исправить устаревшие лимиты в Альте?

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

[Dmitry V. Levin]

On Sat, Nov 20, 2021 at 07:07:09PM +0700, Илья Курдюков wrote:
> Почему в нормальных системах этот код возвращает 10000 с плюсом, а в 
> Альте 500 с чем-то?
> 
> $ cat threadlim.c
> #include <stdio.h>
> #include <stdlib.h>
> #include <pthread.h>
> #include <unistd.h>
> 
> static void* test(void *data) { while(1) sleep(1); return NULL; }
> 
> int main() {
>      int i, err = 0;
>      pthread_t t;
>      for (i = 0; !err && i < 100000; i++)
>        err = pthread_create(&t, NULL, test, NULL);
>      printf("i = %d, err = %d\n", i, err);
>      exit(0);
> }
> $ cc -O2 -pthread threadlim.c && ./a.out
> i = 507, err = 11
> 
> ulimit -u стоит по умолчанию на 512 и не даёт поставить выше 1000:
> 
> $ ulimit -u
> 512
> $ ulimit -u 1000
> $ ulimit -u 1001
> -bash: ulimit: max user processes: не удаётся изменить ограничение: 
> Операция не позволена
> 
> Эти ограничения с начала времён не меняли?

Это очень похоже на настраиваемые лимиты со значениями по умолчанию,
определёнными в /etc/security/limits.d/50-defaults.conf

> http://git.altlinux.org/gears/e/erlang.git
> 
> Почему в спеке Erlang делаются костыли с уменьшением количества потоков, 
> вместо того, чтобы наконец исправить устаревшие лимиты в Альте?

Пакет должен собираться с любым разумным значением RLIMIT_NPROC,
а не только с авангардным.


-- 
ldv

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

[Anton Farygin]

On 20.11.2021 15:11, Dmitry V. Levin wrote:
>> Эти ограничения с начала времён не меняли?
> Это очень похоже на настраиваемые лимиты со значениями по умолчанию,
> определёнными в /etc/security/limits.d/50-defaults.conf
>
Да, эти умолчания конечно уже устарели и меняются в дистрибутивах. 
Возможно, их стоит уже расширить и в пакете с умолчаниями.

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

[Илья Курдюков]

Произведя в спеке сложные вычисления о том сколько потоков создаёт 
Erlang и сколько разрешено в ulimit и количеством ядер на машине?

Так 500+ не хватило на сборку документации в 8 потоков на 32-х ядерной 
машине. На 4 потока хватило.

Они там три пачки потоков scheduler-ов создают, предположительно 3 на 
количество ядер на машине.


On 20.11.2021 19:11, Dmitry V. Levin wrote:
>
>> http://git.altlinux.org/gears/e/erlang.git
>>
>> Почему в спеке Erlang делаются костыли с уменьшением количества потоков,
>> вместо того, чтобы наконец исправить устаревшие лимиты в Альте?
> Пакет должен собираться с любым разумным значением RLIMIT_NPROC,
> а не только с авангардным.
>
>

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

[Nikolay A. Fetisov]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

В Сб, 20/11/2021 в 15:14 +0300, Anton Farygin пишет:
> > ...
> Да, эти умолчания конечно уже устарели и меняются в дистрибутивах. 
> Возможно, их стоит уже расширить и в пакете с умолчаниями.

+1, как минимум для серверных систем.

Я с этим встретился при использовании непривилегированных контейнеров
LXC/LXD, в случае запуска контейнеров с выделением им одного общего 
диапазона subuid/subgid .
Механизм ulimit про namespaces ничего не знает, ограничения в 
security/limits.d/50-defaults.conf считаются по процессам _всех_
контейнеров. Как итог, можно получить срабатывение ulimit внутри
полупустого контейнера на, например, запуск задачи по cron.
И править значения nproc при этом приходится и в хост-системе,
и во всех контейнерах.

-- 
С уважением,
Николай Фетисов

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

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

[Dmitry V. Levin]

On Sat, Nov 20, 2021 at 03:14:09PM +0300, Anton Farygin wrote:
> On 20.11.2021 15:11, Dmitry V. Levin wrote:
> >> Эти ограничения с начала времён не меняли?
> > Это очень похоже на настраиваемые лимиты со значениями по умолчанию,
> > определёнными в /etc/security/limits.d/50-defaults.conf
> >
> Да, эти умолчания конечно уже устарели и меняются в дистрибутивах. 
> Возможно, их стоит уже расширить и в пакете с умолчаниями.

По идее, RLIMIT_NPROC имеет смысл зависеть от аппаратной конфигурации.


-- 
ldv

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

[Andrew A. Vasilyev]

[-- Attachment #1.1: Type: text/plain, Size: 643 bytes --]

20.11.2021 19:07, Dmitry V. Levin пишет:
> On Sat, Nov 20, 2021 at 03:14:09PM +0300, Anton Farygin wrote:
>> Да, эти умолчания конечно уже устарели и меняются в дистрибутивах.
>> Возможно, их стоит уже расширить и в пакете с умолчаниями.
> 
> По идее, RLIMIT_NPROC имеет смысл зависеть от аппаратной конфигурации.

   А вот в pam-limits-desktop всё гораздо лучше:

$ fgrep nproc /etc/security/limits.d/90-desktop.conf
*		soft	nproc	4096
*		hard	nproc	5120

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[mikhailnov]

20.11.2021 18:04, Nikolay A. Fetisov пишет:
> В Сб, 20/11/2021 в 15:14 +0300, Anton Farygin пишет:
>>> ...
>> Да, эти умолчания конечно уже устарели и меняются в дистрибутивах. 
>> Возможно, их стоит уже расширить и в пакете с умолчаниями.
> +1, как минимум для серверных систем.
>
> Я с этим встретился при использовании непривилегированных контейнеров
> LXC/LXD, в случае запуска контейнеров с выделением им одного общего 
> диапазона subuid/subgid .

+100500, я года 2 не мог понять, почему в контейнере не работали банальные вещи, например, "su -u user", пока внимательно не посмотрел strace свежим взглядом, да и glebfm@ подсказал.

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

> Механизм ulimit про namespaces ничего не знает, ограничения в 
> security/limits.d/50-defaults.conf считаются по процессам _всех_
> контейнеров. Как итог, можно получить срабатывение ulimit внутри
> полупустого контейнера на, например, запуск задачи по cron.
Почему? cron же пропустит задачу через PAM-стек, а pam_limits выставит лимиты, если, конечно, ему на это хватит прав, а в разной степени непривилегированных контейнерах может не хватить.
> И править значения nproc при этом приходится и в хост-системе,
> и во всех контейнерах.

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

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

Hi,

On Sat, Nov 20, 2021 at 09:15:03PM +0300, mikhailnov@altlinux.org wrote:
> 
> 20.11.2021 18:04, Nikolay A. Fetisov пишет:
> > В Сб, 20/11/2021 в 15:14 +0300, Anton Farygin пишет:
> >>> ...
> >> Да, эти умолчания конечно уже устарели и меняются в дистрибутивах. 
> >> Возможно, их стоит уже расширить и в пакете с умолчаниями.
> > +1, как минимум для серверных систем.
> >
> > Я с этим встретился при использовании непривилегированных контейнеров
> > LXC/LXD, в случае запуска контейнеров с выделением им одного общего 
> > диапазона subuid/subgid .
> 
> +100500, я года 2 не мог понять, почему в контейнере не работали банальные вещи, например, "su -u user", пока внимательно не посмотрел strace свежим взглядом, да и glebfm@ подсказал.

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

Раньше для решения задачи можно было использовать маппинг uid/gid-ов, а в
совсем свежих ядрах (начиная с v5.14-rc1~153^2~2^2~5 [1]) RLIMIT_NPROC
стал виртуализирован для разных user_namespace-ов.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=21d1c5e386bc751f1953b371d72cd5b7d9c9e270

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

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

[Nikolay A. Fetisov]

[-- Attachment #1: Type: text/plain, Size: 1889 bytes --]

В Сб, 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 и ниже этого патча нет.

-- 
С уважением,
Николай Фетисов

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

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

[Dmitry V. Levin]

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 и переноса в них своей активности.


-- 
ldv

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

[Nikolay A. Fetisov]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

В Вс, 21/11/2021 в 13:00 +0300, Dmitry V. Levin пишет:
> ...
> 
> Серия изменений v5.14-rc1~153^2~2, призванная решить эту проблему,
> в качестве побочного эффекта позволяет любому непривилегированному
> пользователю превышать ограничения RLIMIT_NPROC и нескольких других
> лимитов путём создания userns и переноса в них своей активности.
> 

Т.е. теперь namespaces могут создавать и обычные пользователи...
Проверил на p10 / 5.10.72-std-def-alt1 - можно,
на p9 / 5.4.62-std-def-alt1 от пользователя - 
"unshare failed: Операция не позволена".

Хотя, как минимум внутри контейнеров LXC/LXD это не так страшно,
есть ещё ограничение по числу процессов в контейнере в целом,
и оно успешно срабатывает.

-- 
С уважением,
Николай Фетисов

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

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

[Dmitry V. Levin]

On Sun, Nov 21, 2021 at 02:56:05PM +0300, Nikolay A. Fetisov wrote:
> В Вс, 21/11/2021 в 13:00 +0300, Dmitry V. Levin пишет:
> > ...
> > 
> > Серия изменений v5.14-rc1~153^2~2, призванная решить эту проблему,
> > в качестве побочного эффекта позволяет любому непривилегированному
> > пользователю превышать ограничения RLIMIT_NPROC и нескольких других
> > лимитов путём создания userns и переноса в них своей активности.
> 
> Т.е. теперь namespaces могут создавать и обычные пользователи...
> Проверил на p10 / 5.10.72-std-def-alt1 - можно,
> на p9 / 5.4.62-std-def-alt1 от пользователя - 
> "unshare failed: Операция не позволена".

Это как раз зависит от положения переключателя
/proc/sys/kernel/userns_restrict, см. соседний тред.

> Хотя, как минимум внутри контейнеров LXC/LXD это не так страшно,
> есть ещё ограничение по числу процессов в контейнере в целом,
> и оно успешно срабатывает.

Но если внутри контейнера можно создавать userns, то это ограничение,
видимо, обходится таким же образом, как и глобальные ограничения?
Или что-то препятствует этому?


-- 
ldv

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

[Nikolay A. Fetisov]

[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]

В Вс, 21/11/2021 в 15:09 +0300, Dmitry V. Levin пишет:
> On Sun, Nov 21, 2021 at 02:56:05PM +0300, Nikolay A. Fetisov wrote:
> > 
> > Т.е. теперь namespaces могут создавать и обычные пользователи...
> > ...
> 
> Это как раз зависит от положения переключателя
> /proc/sys/kernel/userns_restrict, см. соседний тред.
> 

Ну т.е. это уйдёт само при следующей сборке ядра.

> > Хотя, как минимум внутри контейнеров LXC/LXD это не так страшно,
> > есть ещё ограничение по числу процессов в контейнере в целом,
> > и оно успешно срабатывает.
> 
> Но если внутри контейнера можно создавать userns, то это ограничение,
> видимо, обходится таким же образом, как и глобальные ограничения?
> Или что-то препятствует этому?

Для изоляции контейнера используются namespaces. То, что создаётся 
внутри контейнера - получается следующим уровнем иерархии.
Ограничение на число процессов контейнера задаётся в хост-системе
через /sys/fs/cgroup/pids/lxc.payload.<ct>/pids.max , и учитывает
и процессы создаваемых внутри контейнера namespaces.


Отсюда и неочевидность описанного выше срабатывания ограничений 
RLIMIT_NPROC - при заданном ограничении pids.max в, скажем, 256,
и пакетном nproc 512 получение ошибки "fork: retry: Ресурс временно
недоступен" оказывается несколько неожиданно.

-- 
С уважением,
Николай Фетисов

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

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

[Alexey Gladkov]

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. НИкакого превышение
невозможно.

-- 
Rgrds, legion

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

[Dmitry V. Levin]

On Sun, Nov 21, 2021 at 03:37:19PM +0300, Nikolay A. Fetisov wrote:
> В Вс, 21/11/2021 в 15:09 +0300, Dmitry V. Levin пишет:
> > On Sun, Nov 21, 2021 at 02:56:05PM +0300, Nikolay A. Fetisov wrote:
> > > 
> > > Т.е. теперь namespaces могут создавать и обычные пользователи...
> > > ...
> > 
> > Это как раз зависит от положения переключателя
> > /proc/sys/kernel/userns_restrict, см. соседний тред.
> 
> Ну т.е. это уйдёт само при следующей сборке ядра.

Если у вас не установлен пакет bubblewrap, конечно.

> > > Хотя, как минимум внутри контейнеров LXC/LXD это не так страшно,
> > > есть ещё ограничение по числу процессов в контейнере в целом,
> > > и оно успешно срабатывает.
> > 
> > Но если внутри контейнера можно создавать userns, то это ограничение,
> > видимо, обходится таким же образом, как и глобальные ограничения?
> > Или что-то препятствует этому?
> 
> Для изоляции контейнера используются namespaces. То, что создаётся 
> внутри контейнера - получается следующим уровнем иерархии.
> Ограничение на число процессов контейнера задаётся в хост-системе
> через /sys/fs/cgroup/pids/lxc.payload.<ct>/pids.max , и учитывает
> и процессы создаваемых внутри контейнера namespaces.

Т.е. ответ "да", число процессов в контейнере на практике ограничивают
другими средствами.  Видимо, это имели в виду авторы v5.14-rc1~153^2~2,
когда решили в некотором смысле упразднить RLIMIT_NPROC для userns.
Видимо, они считали это настолько очевидным, что не стали упоминать
об этом в commit message'ах.


-- 
ldv

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

[Dmitry V. Levin]

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.

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


-- 
ldv

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

[Nikolay A. Fetisov]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]

В Вс, 21/11/2021 в 15:55 +0300, Dmitry V. Levin пишет:
> On Sun, Nov 21, 2021 at 03:37:19PM +0300, Nikolay A. Fetisov wrote:
> 
> > ...
> > Для изоляции контейнера используются namespaces. 
> > ....
> Т.е. ответ "да", число процессов в контейнере на практике
> ограничивают другими средствами. ....

Да, и поэтому поведение на текущих ядрах p9/p10, когда RLIMIT_NPROC
считает процессы во _всех_ контейнеров, а срабатывает по значению
nproc, заданному в _конкретном_ контейнере, оказывается несколько 
неожиданным.

-- 
С уважением,
Николай Фетисов

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 858 bytes --]

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

[Alexey Gladkov]

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

Re: [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

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

[Michael Shigorin]

On Sat, Nov 20, 2021 at 09:15:03PM +0300, mikhailnov@altlinux.org wrote:
> Лимит на кол-во процессов пользователя настолько дикий,
> что его не хватило в банальном чруте на весьма минималистичной
> десктопной системе!

Ну это скорее приговор нынешним тенденциям "минимализма", кмк.

Но на всякий напомню про pam-limits-desktop, который с 2017 года
входит в дистрибутивные профили для десктопов; см. тж. ветку около
http://lists.altlinux.org/pipermail/devel/2017-February/202397.html

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info