Today I just noticed that my process IDs are very high, in the 400,000 (i.e 449624). When I run ps -ef | more, that's when I noticed it. Is that normal or does that indicate a problem? Otherwise the scripts are running fine.

I am using Redhat 7.3 x64 bit.

One other thing I noticed is that we also have Redhat 7.2 and the pids are not that high, just on newer OS. Why would that be? Does it mean it's OS related and normal?

I don't have that kernel_pid_max in my sysctl.conf. I ran cat /proc/sys/kernel/pid_max and I see 458752.

  • You don't have kernel_pid_max in your sysctl.conf because it should be kernel.pid_max. – JRFerguson Feb 12 '19 at 22:23
  • Large process IDs just mean you've started a lot of processes since the machine was booted. Each time a process is started, the kernel assigns the next available process ID larger than the most recently used one, rolling over when you reach the maximum. – chepner Feb 13 '19 at 13:56

At boot, the kernel adjusts the default pid_max depending on the number of CPUs available. When the number is low, the usual 32768 is selected. Else the calculation is done as follows (showing here a 3.10 kernel to be similar to RHEL but beside some variations it's the same for any recent Linux kernel):


 * This controls the default maximum pid allocated to a process
#define PID_MAX_DEFAULT (CONFIG_BASE_SMALL ? 0x1000 : 0x8000)

0x8000 = 32768 is the usual value used on systems with less than 32 cpu threads available.

and later:

#define PIDS_PER_CPU_DEFAULT    1024

Those values are then used in kernel/pid.c:

int pid_max = PID_MAX_DEFAULT;

and later:

    /* bump default and minimum pid_max based on number of cpus */
    pid_max = min(pid_max_max, max_t(int, pid_max,
                PIDS_PER_CPU_DEFAULT * num_possible_cpus()));
    pid_max_min = max_t(int, pid_max_min,
                PIDS_PER_CPU_MIN * num_possible_cpus());
    pr_info("pid_max: default: %u minimum: %u\n", pid_max, pid_max_min);

So from OP this should mean a total of 458752/1024 = 448 simultaneous threads available: quite a lot. The other system has probably not as many CPUs/cores/threads etc., so has a lower default pid_max.


From the proc documentaton :

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

You can see the with cat /proc/sys/kernel/pid_max. You can also query this with sysctl.

sudo sysctl -a | grep kernel.pid_max


sysctl -n kernel.pid_max

Modify /etc/sysctl.conf to change the value permanently and reload with sysctl -p.


A process ID can be any value represented by the pid_t type, which is specific to your operating system. In practice, it is usually a 32-bit signed integer, which means the maximum process ID would be 2147483647, or approximately 5000 times larger than the process IDs you're observing.

The GNU documentation says:

Data Type: pid_t

The pid_t data type is a signed integer type which is capable of representing a process ID. In the GNU C Library, this is an int.

In practice, the kernel will usually enforce an upper limit which is lower than that. On a Linux system, this is controlled by /proc/sys/kernel/pid_max, which defaults to 32768. If your system is Linux, you can check that file to see what the current limit is.

The limit may be different on different operating systems; for example, it appears that on macOS, PID_MAX is hardcoded as 99999.

  • 3
    Linux has fundamental API reasons pids can't fill a 31-bit space; the top 2 bits (in addition to the sign bit) are reserved for special purposes in the robust futex and PI futex interfaces. That leaves only 29 bits, for a 512M pid space. – R.. GitHub STOP HELPING ICE Feb 13 '19 at 0:54
  • 1
    @R.: Sure, that's true for Linux. But when I wrote this answer, the question didn't specify Linux, and so I gave an answer for any Unix. As far as I know, there is nothing in the POSIX standard that requires a particular size for pids; it seems unnecessary now but I could imagine a future system where pid_t was 64-bits in size. – Daniel Pryden Feb 13 '19 at 14:15
  • Indeed that's all true. – R.. GitHub STOP HELPING ICE Feb 13 '19 at 15:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.