Fedora 31 has decided to allow (and have) giant process IDs (PIDs)

January 10, 2020

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

Comments on this page:

From at 2020-01-10 01:17:24:

I have used this setting for several years before systemd picked it up, with no problems at all. Looks like everyone honors sizeof(pid_t).

It should be safe to just override the same sysctl back to 65535 if you want.

By Lennart at 2020-01-10 07:34:51:

I think in all the time we have defaulted to large pids now we got not a single report of breakage. So this apparently worked out well.


From at 2020-01-10 08:15:12:

Which, coming from you, doesn't mean much, since you are known for dismissing breakage reports as "invalid, works as intended, it's the user's fault" (the attempt to hijack debug kernel option and the issue with usernames starting with a digit come to mind).

Written on 10 January 2020.
« Why I use both uBlock Origin and uMatrix
OCSP stapling and what web servers and browsers do in the face of errors »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jan 10 00:52:15 2020
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.