Hello,I wouldn't think that preventing PID exhaustion would be all that much of a niche case, it's fully possible for it to happen without using excessive amounts of kernel memory (think about BIG server systems with terabytes of memory running (arguably poorly written) forking servers that handle tens of thousands of client requests per second, each lasting multiple tens of seconds), and not necessarily as trivial as you might think to handle sanely (especially if you want callbacks when the limits get hit).
On Fri, Feb 27, 2015 at 11:42:10AM -0500, Austin S Hemmelgarn wrote:
Kernel memory consumption isn't the only valid reason to want to limit the
number of processes in a cgroup. Limiting the number of processes is very
useful to ensure that a program is working correctly (for example, the NTP
daemon should (usually) have an _exact_ number of children if it is
functioning correctly, and rpcbind shouldn't (AFAIK) ever have _any_
children), to prevent PID number exhaustion, to head off DoS attacks against
forking network servers before they get to the point of causing kmem
exhaustion, and to limit the number of processes in a cgroup that uses lots
of kernel memory very infrequently.
All the use cases you're listing are extremely niche and can be
trivially achieved without introducing another cgroup controller. Not
only that, they're actually pretty silly. Let's say NTP daemon is
misbehaving (or its code changed w/o you knowing or there are corner
cases which trigger extremely infrequently). What do you exactly
achieve by rejecting its fork call? It's just adding another
variation to the misbehavior. It was misbehaving before and would now
be continuing to misbehave after a failed fork.
In general, I'm pretty strongly against adding controllers for thingsPID's are a fundamental resource, you run out and it's an only marginally better situation than OOM, namely, if you don't already have a shell open which has kill builtin (because you can't fork), or have some other reliable way to terminate processes without forking, you are stuck either waiting for the problem to resolve itself, or have to reset the system.
which aren't fundamental resources in the system. What's next? Open
files? Pipe buffer? Number of flocks? Number of session leaders or
program groups?
If you want to prevent a certain class of jobs from exhausting a givenWhich is why I'm advocating something that provides a more robust method of preventing the system from exhausting PID numbers.
resource, protecting that resource is the obvious thing to do.
Thanks.