This:
$ seq 100000 | xargs -P0 -n1 -I {} bash -c 'echo {};sleep {}'
:
5514
bash: fork: retry: No child processes
started complaining around 5500 when the system had 11666 processes running. Now, 11666 was really surprising to me given:
$ ulimit -u
313370
$ cat /proc/sys/kernel/pid_max
313370
$ grep hard.*nproc /etc/security/limits.conf
* hard nproc 313370
Why can I only run 11600 processes?
Edit:
Testing on another user I get to 6100 (i.e. 12200 procs), thus totalling 24000 procs. So the limit is not systemwide.
$ 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=
So the 12288 could be the culprit. I changed that to 1000 and did:
sudo systemctl daemon-reexec
sudo systemctl restart systemd-logind
If I now log in as a user I have not logged in as before, the new limit works. But if I log in as a user that has recently been logged in, the limit active at the first login is enforced. So the limit is cached somewhere.
Using the above I tested up to 30000 procs and this works, but only for users that have not logged in before.
So what is caching the limit from
/etc/systemd/logind.conf
? And how can I flush that cache?
The new limit is well above 60000 procs (and could possibly be the 313370 as I would expect).
limits.conf
andprlimit
as mentioned in that thread. – U880D Apr 16 '18 at 12:33limit.conf
, but instead from/etc/systemd/logind.conf
. The question is: How do I flush the cache of this, so the limits given in that file is respected if Issh
to localhost as myself. – Ole Tange Apr 16 '18 at 13:05