PID Range Calculator
Check current PID usage against kernel.pid_max and estimate remaining headroom.
Inputs
PID Usage % (of pid_max)
86.975%
Status
Elevated — approaching pid_max; wraparound is approaching (wraparound itself is normal kernel behavior, not an error).
Remaining PIDs Before Wraparound
4,268
pid_max in Use
32,768
Estimated Hours to Wraparound
8.5
Step by step
Values used
pid_max Value = 32768 (default on many distros); Custom pid_max = 65,536; Current Highest Assigned PID = 28,500; PID Allocation Rate (new PIDs/hour, for wraparound estimate) = 500
PID usage and wraparound estimate
usage% = current_highest_pid / pid_max × 100; hours_to_wraparound = (pid_max − current_highest_pid) / allocation_rate
PID Usage % (of pid_max)
= 86.975
Status
= Elevated — approaching pid_max; wraparound is approaching (wraparound itself is normal kernel behavior, not an error).
Remaining PIDs Before Wraparound
= 4,268
pid_max in Use
= 32,768
Estimated Hours to Wraparound
= 8.50
How it works
Linux assigns PIDs sequentially up to kernel.pid_max, then wraps back around to low numbers (skipping any still in use) rather than failing — so reaching pid_max itself is normal, expected behavior, not an error condition, unlike hitting the total process count limit. This calculator estimates how close the running PID counter is to that ceiling and, given an allocation rate, roughly how soon wraparound will occur — useful context for understanding PID reuse patterns rather than a warning sign requiring intervention, since wraparound is a routine, harmless part of normal operation on any long-running system.
Formula
PID usage and wraparound estimate
usage% = current_highest_pid / pid_max × 100; hours_to_wraparound = (pid_max − current_highest_pid) / allocation_rate
- P_{cur}
- current highest assigned PID
- P_{max}
- pid_max
- r
- PID allocation rate per hour
Frequently Asked Questions
Is it a problem when the PID counter reaches pid_max and wraps around?
No — wraparound is completely normal, expected kernel behavior on any system that's been running long enough to allocate pid_max worth of PIDs. The kernel simply resumes allocating from low numbers again, skipping any still actually in use by running processes; this is distinct from and unrelated to hitting the total live process count limit.
What's the actual difference between pid_max and the total process count limit?
pid_max caps the numeric range PIDs are assigned from (and wraps around harmlessly when exhausted); the total live process/thread count is separately capped by kernel.threads-max and various ulimits/cgroup limits, which do produce real fork() failures if exceeded. A system can wrap PIDs many times over its uptime while never coming close to the live process count limit.
Should I increase pid_max preemptively?
It's low-risk and sometimes done on systems with extremely high process/thread churn (raising it to 4194304, the max on 64-bit systems, via `sysctl -w kernel.pid_max=4194304`), mainly to reduce PID reuse frequency for tooling that tracks processes by PID over time, rather than to avoid any real failure mode.