I can't find any pattern when I look at the numbering of PIDs in process table (ps -a), as the PIDs are not subsequent numbers and sometimes there are large "gaps" between those numbers. Is it because there may be some processes that run for a short time and they reserve some PIDs? Is there some range, after which the numbering of processes resets?

I'm using Mac OS X but I guess that the answer should apply to UNIX in general.

3 Answers 3


Yes on both counts.

Many processes are short lived. They get a PID, run, finish, and the PID disappears from the process table.

Processes sometimes only live for a fraction of a second!

Often when programs start they run numerous commands as part of checking the system and initializing their environment.

The maximum PID number depends on the system and is sometimes configurable. Basically if you know you are going to have a huge number of processes, then you may need to increase the number, but on new operating systems I believe the maximum number is typically large enough for most any workload.

PIDs are entries in the process table, and the more you have the more memory the process table takes up.

Have a look at this related question: https://serverfault.com/questions/279178/what-is-the-range-of-a-pid-on-linux-and-solaris

Also note that related to this is the "maximum nr of processes per user" which is a measure to protect against a malicious user intentionally creating many processes to hog the whole process table.


It is also possible to configure some modern kernels to assign random PIDs to new processes for improved security. At least Linux and FreeBSD can do it with a sysctl setting, and OpenBSD does it always. In those cases you can say ever less about the numbering schemas.

  • Do you know what, if any, performance cost exists for this?
    – user732
    Commented Feb 26, 2013 at 18:01
  • @Bruce: the first proposed patch had the worst case performance of O(infty) due the naive randomize. But I think they got something safe and usable. I didn't find anything very current on the topic... not that used I believe. :)
    – mike3996
    Commented Feb 26, 2013 at 18:22
  • 5
    Random PIDs sounds like security through obscurity to me.
    – Johan
    Commented Feb 27, 2013 at 7:43
  • That's what it is, mostly...
    – mike3996
    Commented Feb 27, 2013 at 8:08
  • Appart from individual initiatives, Linux used to propose it only through grsecurity patch, the Linux kernel team always refused to implement it (example here) and even grsecurity team finally dropped it in the late 2006. Commented Jun 2, 2015 at 21:30

Processes in UNIX are very light, cheap and are born by forking(!).

The forking aspect often eludes users, sysadmins and programmers alike, especially those who are coming from so called "spawn" oriented systems like Windows.

Windows cannot fork, or rather, it can only fork threads (technically it can fork, but this API is beyond reach of WINAPI programs).

I.e. on UNIX, fork is much more similar to thread spawning, than to Windows process spawning. It splits initial process into itself and it's child that is running copy of it's parent and both share same data and history up until the point of the fork (then their respective histories start to slowly but steadily diverge).

As was already said in other answers, this all (cheapness, quickness, lightweightness) means PIDs can appear and go away very, very quickly.

Please understand that traditional UNIX way of writing internet servers is to use one fork per one connection model - this essentially means that one new PID is spawned for each connection.

Just think about it in context of very busy image serving http server: each time image is displayed to a remote client, this means new PID is forked image data is read and sent and then PID is consumed, all happening in very quick succession during fraction of a second. Traditional ftp, but also many lightweight http servers are still being written in such a way to this day.

Another initially weird aspect of UNIX is, that defunct ie. dead processes don't release their PIDs! By the time process of given PID has ended, it has no way to affect the PID still being held in any way. Yet this PID remains allocated and occupies/hogs the system process table.

Why is that? Because under that process table PID record program exit code value and various accounting counters of that process are being held!

This is so CPU and memory accounting programs can read information of their children, even after they have ended.

We call such a defunct accounting record a ZOMBIE.

It means that until specific zombie is processed, its PID cannot be reused (ie several zombies waiting to be accounted for can cause "holes" in case of UNIX systems with very naive linear PID assignement scheme) for newly forking processes.

It is responsibility of process's parent process to "reap" the zombie, ie to consume its accounting information and thus return zombie's PID into the pool of "free PIDs" for other forking processes to reuse.

Given all these facts, even if PID generation is naively linear algorithm preffering to reuse first "unoccupied" PID possible, we see that various system actions like parental zombie reaping, will result with PID never being strictly linearly growing.

On all modern systems completely random PID assignment algorithms can be activated, but OpenBSD is an only system where it mandatory enforced by default.

Thus we should always treat PIDs as completely opaque identifiers.

You must log in to answer this question.

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