Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
    
possible duplicate of About the pid of the process –  Hasturkun Oct 11 '11 at 9:42
add comment

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

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

4 Answers

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

It removes predictability which is a security problem.

share|improve this answer
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? –  Helgi Hrafn Gunnarsson 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 Oct 11 '11 at 23:45
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.