Onde o limite está definido? bash: fork: retry: nenhum processo filho

Question

Isto:

$ seq 100000 | xargs -P0 -n1 -I {} bash -c 'echo {};sleep {}'
:
5514
bash: fork: retry: No child processes

começou a reclamar por volta de 5500 quando o sistema tinha 11666 processos em execução. Agora, 11666 foi realmente surpreendente para mim:

$ ulimit -u
313370
$ cat /proc/sys/kernel/pid_max
313370
$ grep hard.*nproc /etc/security/limits.conf
*                hard    nproc           313370

Por que só posso executar 11600 processos?

Editar:

Teste em outro usuário Eu chego a 6100 (ou seja, 12200 procs), totalizando 24000 procs. Então o limite não é todo o sistema.

$ uname -a
Linux aspire 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ grep -i tasksmax /etc/systemd/*
/etc/systemd/logind.conf:#UserTasksMax=12288
/etc/systemd/system.conf:#DefaultTasksMax=

Assim, o 12288 poderia ser o culpado. Eu mudei para 1000 e fiz:

sudo systemctl daemon-reexec
sudo systemctl restart systemd-logind

Se eu fizer login como usuário, não fiz login como antes, o novo limite funciona. Mas se eu fizer login como um usuário que tenha feito login recentemente, o limite ativo no primeiro login será imposto. Então o limite é armazenado em algum lugar.

Usando o acima, testei até 30000 procs e isso funciona, mas apenas para usuários que não fizeram login antes.

Então, qual é o cache do limite de %código%? E como posso liberar esse cache?

O novo limite está bem acima de 60000 procs (e possivelmente poderia ser o 313370, como seria de esperar).

    

Answer 1

O sistema em questão é executado systemd. Isso é uma coisa que usa cgroups para dividir recursos do sistema entre vários grupos de processos.

É provável que o sysctl kernel.sched_autogroup_enabled = 1 esteja definido. Isso seria uma segunda coisa dividindo os recursos do sistema usando cgroups.

Existe a possibilidade de que uma vez que um cgroup ou um conjunto de cgroups para um usuário em particular tenha sido inicializado, ele permanecerá intocado até a reinicialização.

Eu não tenho como caçar se é por causa do systemd ou do autogroup, seja por causa da limitação do número do processo ou por causa da limitação de memória (dentro de um cgroup), nem do tempo de busca no código-fonte. Queria comentar em vez de responder, mas não tenho reputação suficiente.