The pid_max tunable for the maximum number of process IDs allowed simultaneously was increased by default back in 2019 with systemd. But that increase breaks a long held assumption by some user-space software that pid_max or the process ID would not be greater than 65,535. To now better workaround such outdated user-space software, a set of patches for the Linux 6.14 kernel will allow adjusting the pid_max limit on a per PID namespace basis to help cope with such software hitting such artificial limits and without having to lower the overall system limit.
Christian Brauner of Microsoft sent out the PID namespace pull request this weekend in advance of the Linux 6.14 merge window opening. He explained of the issues and motivation for this change to allow pid_max to be set on a per PID namespace basis:
“The pid_max sysctl is a global value. For a long time the default value has been 65535 and during the pidfd dicussions Linus proposed to bump pid_max by default. Based on this discussion systemd started bumping pid_max to 2^22. So all new systems now run with a very high pid_max limit with some distros having also backported that change. The decision to bump pid_max is obviously correct. It just doesn’t make a lot of sense nowadays to enforce such a low pid number. There’s sufficient tooling to make selecting specific processes without typing really large pid numbers available.
In any case, there are workloads that have [expectations] about how large pid numbers they accept. Either for historical reasons or architectural reasons. One [concrete] example is the 32-bit version of Android’s bionic libc which requires pid numbers less than 65536. There are workloads where it is run in a 32-bit container on a 64-bit kernel. If the host has a pid_max value greater than 65535 the libc will abort thread creation because of size assumptions of pthread_mutex_t.
That’s a fairly specific use-case however, in general specific workloads that are moved into containers running on a host with a new kernel and a new systemd can run into issues with large pid_max values. Obviously making assumptions about the size of the allocated pid is suboptimal but we have userspace that does it.
Of course, giving containers the ability to restrict the number of processes in their respective pid namespace [independent] of the global limit through pid_max is something desirable in itself and comes in handy in general.
Independent of motivating use-cases the existence of pid namespaces makes this also a good semantical extension and there have been prior proposals pushing in a similar direction. The trick here is to minimize the risk of regressions which I think is doable. The fact that pid namespaces are hierarchical will help us here.
…
All in all this means pid_max continues to enforce a system wide limit on the number of processes but allows pid namespaces sufficient leeway in handling workloads with assumptions about pid values and allows containers to restrict the number of processes in a pid namespace through the pid_max interface.”
More details within this pull request. Assuming Linus Torvalds finds no objections to the change, it will be part of the upcoming Linux 6.14 merge window.
