19

This is a purely academic question, because this will never happen.

If a PID is stored as type pid_t, and not some arbitrary-precision type, then there is a limit to the number of PIDs that can exist at one time. Is there a defined behavior for when PIDs overflow?

Will the 65536th process kill /sbin/init and create a kernel panic? Or is there some safety measure in place?

7
  • 2
    stackoverflow.com/questions/6294133/maximum-pid-in-linux I guess you could change the maximum value and find out ;)
    – user4443
    Aug 17, 2016 at 18:30
  • 2
    Lower numbers do get reused (OpenBSD and others randomize the PIDs) and you''ll probably hit some other limit (e.g. run out of memory on account of all the processes or swap death or OOM killer going wild) before fork fails on account of no pid available.
    – thrig
    Aug 17, 2016 at 18:41
  • 1
    For information: I do not believe that I have seen a PID larger than 2^15-1 = 32767. Have you?
    – thb
    Aug 17, 2016 at 19:08
  • 3
    Neither suggested duplicates really answer this question though. Aug 17, 2016 at 21:08
  • 2
    It's not clear whether you're asking what happens when PIDs reach some maximum value (whether it's about 2^15 or about 2^32), or what happens when it's no longer possible to allocate a new PID, which is not the same thing. I don't think your question is a duplicate of either of the marked questions; both ask what the limit is, not what happens when you exceed it. If you update the question to clarify what you're asking, I'll vote to reopen it. (You already have answers to both possible versions.) Aug 19, 2016 at 0:15

3 Answers 3

19

POSIX doesn't specify that the PID of each new process is obtained by incrementing the previous PID. It only requires it to be unique.

On a system where PIDs are incremented on each fork(), I've observed that the values wrap around after reaching some upper bound (which in my experience is around 215). After wrapping around, new PIDs are not strictly incremented, since some PID values will still be in use from previous cycles.

There shouldn't be a problem until you have 2N simultaneously running processes. I suspect the system would run into some capacity limit long before that happened. In that case, the fork() system call would fail and probably set errno to EAGAIN or ENOMEM (man fork for details).

The code that implements fork may or may not check whether any PIDs are available. It might not bother, because it assumes that system resources would have run out before it got to that point, or it might have an explicit check for the sake of completeness and to handle future possibilities. I haven't checked, and if I had I could only address whichever kernel I had looked at.

UPDATE: On my current system (Ubuntu 20.04), the maximum PID is 222, as seen here:

$ cat /proc/sys/kernel/pid_max
4194304

From man 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 number 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).

But the specific maximum is probably not terribly relevant to the question, except that you're even less likely to be able to have 4+ million processes than to have more than 32767.

6
  • 1
    Of course I know it would never happen, but the system does have a limited number of PIDs to assign. I just want to know what happens when it runs out.
    – fpf3
    Aug 18, 2016 at 4:09
  • 2
    This answer is actually the only one that really answers the question. The behavior is system dependent but only needs to ensure a unique pid per new process. Of course you get limited by the configured maximum amount of PIDs which is detailed in the 2 questions marked as duplicates, but it is very unlikely to happen unless your system is running containers or you have a severe bug in an installed program or script. Aug 18, 2016 at 4:48
  • On my 32 bit LM VM, the max pid is 32768. In Ruby, I just ran system('cp') 32000 times to max out the pid. After reaching the PID, it started again from a small count, like 9000 or so. I did it multiple times, nothing really happened. In such case, cp just exits and doesn't occupy the process table. Then I ran 32000.times { fork { } } which just creates 32K zombies. I got (irb):2: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken. This is disastrous, I can't even close Ruby, neither I can run terminal nor click on poweroff to shutdown the system.
    – 15 Volts
    Oct 20, 2020 at 23:17
  • There is still a way to overflow it. If you keep creating new process and tear it down, for example during heavy compilation of multiple large projects, you could possibly overflow it. Using ccache with ‘%compiler -v’ as compiler_check would likely help accelerate this.
    – JiaHao Xu
    Mar 23, 2021 at 11:51
  • @JiaHaoXu Sure, but overflowing isn't a problem as long as there aren't PID_MAX processes simultaneously in existence. (I suppose they don't have to be running; zombie processes still consume a PID.) Mar 23, 2021 at 20:35
15

The fork syscall should return -1, and set errno to EAGAIN. What happens after that will depend on the process that called fork.

From fork:

The fork() function shall fail if:

[EAGAIN]

The system lacked the necessary resources to create another process, or the system-imposed limit on the total number of processes under execution system-wide or by a single user {CHILD_MAX} would be exceeded.

3

The maximum PID limit is much much less than 2^((sizeof(int)*CHAR_BIT). See What is the maximum value of the Process ID?. In other words, your PIDs will never go near 4 billion.

When all pid slots are filled, fork calls will start failing with errno==EAGAIN (see fork(2)). If you simply hit the top without filling all the slots, the next PID will be the next free slot after 1 (1 is init)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .