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?

  • 2
    stackoverflow.com/questions/6294133/maximum-pid-in-linux I guess you could change the maximum value and find out ;) – drewbenn Aug 17 '16 at 18:30
  • 1
    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 '16 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 '16 at 19:08
  • 2
    Neither suggested duplicates really answer this question though. – Julie Pelletier Aug 17 '16 at 21:08
  • 1
    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.) – Keith Thompson Aug 19 '16 at 0: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:


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.


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

  • 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. – Fred Frey Aug 18 '16 at 4:09
  • 1
    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. – Julie Pelletier Aug 18 '16 at 4:48

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)

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.