avoidr: pid_max in Linux is adjustable

While reviewing my dwm patch¹, I went off to research on the width of pid_t, where I came across something I didn't know before: The maximum PID in Linux is adjustable.

I've heard that the maximum PID value can be read out from /proc/sys/kernel/pid_max, and that this file is writable.

The maximum PID value can be read out from /proc/sys/kernel/pid_max. What I didn't know is that this file is also writable. I looked up the man page for procfs (man 5 proc); It told me that the default value is 32768 and that on 64-bit systems the default value can be up to 2²².²

Out of curiosity, I checked the max_pid values on my systems; to my surprise, on the Debian systems the value was 4194304 (2²²). With the help of the sysctl(8) man page, I found where this value is set: /usr/lib/sysctl.d/50-pid-max.conf:

#  This file is part of systemd.
[…]
# 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

So this is part of systemd. I've digged through the systemd repo with git log --all -S 'kernel.pid_max' and the earliest relevant commit I found is this one:

commit 45497f4d3b212307569fc06bdab6a35a3e2dab07
Author: Lennart Poettering <lennart@poettering.net>
Date:   Fri Apr 5 15:38:16 2019 +0200

    sysctl: let's by default increase the numeric PID range from 2^16 to 2^22

    This should PID collisions a tiny bit less likely, and thus improve
    security and robustness.

    2^22 isn't particularly a lot either, but it's the current kernel
    limitation.

    Bumping this limit was suggested by Linus himself:

    https://lwn.net/ml/linux-kernel/CAHk-=wiZ40LVjnXSi9iHLE_-ZBsWFGCgdmNiYZUXn1-V5YBg2g@mail.gmail.com/

    Let's experiment with this in systemd upstream first. Downstreams and
    users can after all still comment this easily.

    Besides compat concern the most often heard issue with such high PIDs is
    usability, since they are potentially hard to type. I am not entirely sure though
    whether 4194304 (as largest new PID) is that much worse to type or to
    copy than 65563.

    This should also simplify management of per system tasks limits as by
    this move the sysctl /proc/sys/kernel/threads-max becomes the primary
    knob to control how many processes to have in parallel.

The commit message reads entirely unexciting to me. It reads to me like "because we can". I don't know what the real reason is for the change, what prompted them to adjust that value.

I also personally don't think that the default value of 32768 is small, at least not for a desktop system.

I've run an experiment on my own system, and for the past month—from 2022.12.15 till 2023.01.14—the vast majority of times, the amount of threads on this system was below 1000. The maximum amount of threads was 3032, the minimum amount was 151 threads. With about normal usage, when Firefox isn't running, there are below 250 threads running. Starting Firefox with my Firefox profile adds another almost 200 threads. And opening a new tab with my favorite Searx instance spawns up another 30-40 threads.

This is what I did to collect those numbers:

while true
do
	printf '%d %d\n' $(date +%s) $(ps -eL | wc -l) >>/tmp/threads
	sleep 1
done

Anyway, I have found my answer, on Linux the high bound for PIDs is 2²², which is 4194304, a 7 digit wide number.

As for my dwm patch, I decided not to simplify my code from dynamic allocation to static allocation with a magic number, because I don't like making assumptions about the environment. And the code in question is not critical to performance, as it is only executed when spawning a new X11 window, which happens extremely rarely. Therefore, I pick the more robust way and hope to never hear of that code again, so to speak.

The *-cwd_spawn branches in my dwm repo. ↩︎

From man 5 proc ↩︎:

       /proc/sys/kernel/pid_max (since Linux 2.5.34)
              This file specifies the value at which PIDs wrap  around  (i.e.,
              the  value  in  this  file is one greater than the maximum PID).
              PIDs greater than this value are not allocated; thus, the  value
              in  this file also acts as a system-wide limit on the total num‐
              ber of processes and threads.  The default value for this  file,
              32768,  results in the same range of PIDs as on earlier kernels.
              On 32-bit platforms, 32768 is the maximum value for pid_max.  On
              64-bit  systems,  pid_max  can  be  set  to any value up to 2^22
              (PID_MAX_LIMIT, approximately 4 million).