0

On my system ulimit -u reports 63172 and /proc/sys/kernel/pid_max reports 32768.

Why is it that the value for ulimit -u is higher than the kernel's value? From my understanding, ulimit -u shows the max processes a user can have, not system-wide. pid_max is supposed to be system-wide via the kernel. It seems wrong to me that ulimit -u is higher than pid_max, wouldn't this mean that a user could cause PIDs to wrap around if they spawned enough processes? Also, if the pid_max value is hit by something a user is doing, won't that cause the No more processes error to occur?

2

PIDs do wrap around in normal usage. That's not a problem at all; the kernel ensures that new PIDs don't collide with existing PIDs. Nothing says that PIDs have to be monotomically increasing; process 12345 could easily fork() and have a child process of 5001.

In this scenario, yes, a user could potentially use up all process slots and prevent further fork() type activity from occurring. If this is a problem in your environment then you need to tune the ulimit values in /etc/security/limits.conf or /etc/security/limits.d/*

0

This usually means that the system will run out of process slots before the user's limit is reached. The man page of setrlimit says:

RLIMIT_NPROC

The maximum number of processes (or, more precisely on Linux, threads) that can be created for the real user ID of the calling process. Upon encountering this limit, fork(2) fails with the error EAGAIN. This limit is not enforced for processes that have either the CAP_SYS_ADMIN or the CAP_SYS_RESOURCE capability.

The return value of EAGAIN strongly implies that this is a limit on concurrent threads, and that once a child has exited, a subsequent fork() may succeed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.