Is there any chance the new process's pid is smaller than the existed ones ? I have a daemon process which will restart when be killed, I recorded the pids, and found that the pid first came smaller, and then go bigger.

what's the possible reason ?


sorry for asking & thanks for the answers.

I think I have found the answer. /proc/sys/kernel/pid_max shows 32768(android os on a phone), in the longtime test, it must have exceeded this,and reallocated. Thanks again.

migrated from stackoverflow.com Oct 11 '11 at 16:26

This question came from our site for professional and enthusiast programmers.


On Linux, PIDs are assigned in order, but eventually the system will hit its PID limit and start over, skipping already-assigned PIDs.

  • And that's true of just about all UN*Xes, not just Linux. – user44841 Jul 26 '15 at 19:06

I thought that PIDs got assigned randomly, so as to prevent attackers from guessing temporary file names, which typically have a string representation of the process' PID in them. But I was wrong. I wrote the following little C program and ran it on RHEL 5, x86_64, to check:

#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

main(int ac, char **av)
        int cnt;
        pid_t firstpid = getpid();

        long diff = 32768 - firstpid;
        cnt = diff;

        printf("Going to fork %d times\n", cnt);

        while (cnt)
                pid_t mypid = getpid();
                printf("cnt %d, pid %d\n", cnt, mypid);
                switch (fork())
                case 0: break;
                case -1:
                        fprintf(stderr, "fork() problem: %s\n", strerror(errno));
        return 0;

The largest numerical PID I could get was 32767, 2^15-1, what can fit in a signed 2-byte short. I'll be a monkey's uncle.


It removes predictability which is a security problem.

  • 3
    That doesn't happen on Linux. Not on any Linux I've ever used, anyway. And besides, with only 15 bits at stake, there's not much security to be gained. Randomized PIDs might be valuable with 32-bit PIDs. – Warren Young Oct 11 '11 at 16:43
  • Sorry, I'm interested in this one. What removes predictability, and how could that create a security problem? – Teekin Oct 11 '11 at 18:11
  • 2
    A great many programs that create temporary files put PID in the temporary file's name. If you can guess the next PID, sometimes you can create the temporary file before the program does. If the temp file the attacker creates gets that program's UID and GID, the attacker can create a script to run as that UID. Can't cite any real examples, but I know this has happened. – Bruce Ediger Oct 11 '11 at 19:05
  • @WarrenYoung I'm pretty sure there's a patch floating around. It's not much use unless you also raise the PID size to at least 2^31 if not 2^63: adding about 7 bits of unpredictability doesn't buy much. – Gilles 'SO- stop being evil' Oct 11 '11 at 23:45

This is normal. When a new process starts, it has a new process ID, but it is not required to be bigger.

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.