4

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.

Improve this question
1

4 Answers 4

Reset to default
9

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

Improve this answer
1
  • And that's true of just about all UN*Xes, not just Linux.
    – user44841
    Jul 26, 2015 at 19:06
2

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>

int
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));
                        _exit(9);
                        break;
                default:
                        _exit(0);
                        break;
                }
                --cnt;
        }
        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.

Improve this answer
0

It removes predictability which is a security problem.

Improve this answer
4
  • 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, 2011 at 16:43
  • Sorry, I'm interested in this one. What removes predictability, and how could that create a security problem?
    – Teekin
    Oct 11, 2011 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.
    – user732
    Oct 11, 2011 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, 2011 at 23:45
0

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

Improve this answer

You must log in to answer this question.

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