== Fedora 31 has decided to allow (and have) giant process IDs (PIDs) Every new process and thread on Linux gets a new *PID* (short for process ID). PIDs are normally assigned sequentially [[until they hit some maximum value and roll over ../unix/PidRollover]]. The traditional maximum PID value on Unixes has been some number related to a 16-bit integer, either signed or unsigned, and Linux is no exception; the kernel default is generally still 32768 (which is 2^15 exactly, and so not quite authentic to a signed 16-bit int). (You can find the current limit in ``/proc/sys/kernel/pid_max'', but [[it may have been increased through sysctls FedoraInitramfsSysctl]].) A few years ago [[I discovered that a Fedora package had raised this limit on me FedoraInitramfsSysctl]], which I was able to see because [[it turned out that my Fedora machines routinely go through a lot of PIDs PidRapidRollover]]. I reverted this by removing the package for various reasons, including that I don't really like gigantic process IDs (they bulk up the output of _ps_, _top_, and other similar tools). Then recently I updated to Fedora 31, and not too long afterward noticed that I was getting giant process IDs again (as I write this a new shell on one machine gets PID 4,085,915). This turns out to be a deliberate choice in modern versions of systemd, instead of another stray package deciding it knows best. In Fedora 31 (with systemd 243), /usr/lib/sysctl.d/50-pid-max.conf says: > # Bump the numeric PID range to its maximum of 2^22 > # (from the in-kernel default of 2^16), to make PID > # collisions less likely. > kernel.pid_max = 4194304 (Since the PID that new processes get is so close to the maximum, I suspect that I have actually rolled over even this large range a couple of times in the 21 days that this machine has been up since the last time I got around to a kernel update.) Given that this is a new official systemd thing, I'm going to let it be and live with gigantic PIDs. It's not really worth fighting systemd; it generally doesn't end well for me. (Hopefully there aren't any programs on the system that assume PIDs are small and always fit into five-character fields in ASCII. Or at least no programs that will fail when this assumption is incorrect, as opposed to producing ugly output.)