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 . 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 .)

A few years ago I discovered that a Fedora package had raised this limit on me , which I was able to see because it turned out that my Fedora machines routinely go through a lot of PIDs . 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.)