Thank you for the answer.
I mean the number of threads a process/pid can spawn.
Similar with /proc/sys/kernel/threads-max but per container.
I mean the number of threads a process/pid can spawn.
Similar with /proc/sys/kernel/threads-max but per container.
Would a lxc container be able to use 1 single pid with many threads (bypassing the max-pids limit)?
From the doc
Abstract
--------
The process number controller is used to allow a cgroup hierarchy to stop any
new tasks from being fork()'d or clone()'d after a certain limit is reached.
Since it is trivial to hit the task limit without hitting any kmemcg limits in
place, PIDs are a fundamental resource. As such, PID exhaustion must be
preventable in the scope of a cgroup hierarchy by allowing resource limiting of
the number of tasks in a cgroup.
Abstract
--------
The process number controller is used to allow a cgroup hierarchy to stop any
new tasks from being fork()'d or clone()'d after a certain limit is reached.
Since it is trivial to hit the task limit without hitting any kmemcg limits in
place, PIDs are a fundamental resource. As such, PID exhaustion must be
preventable in the scope of a cgroup hierarchy by allowing resource limiting of
the number of tasks in a cgroup.
Or to answer your question (since I find the doc lacking): no. Threads are also created with `clone()`, so they're also covered by pids.max. So, currently you can set `lxc.cgroup.pids.max: 100` in /etc/pve/lxc/$vmid.conf manually to add a limit covering both processes and threads as a whole.