Unix process ID

Hi,

I couldn't google out the answer. Is the process id number always
ascending? i.e. if I start process A and a second later start process
B, can I be sure that process id of B will be bigger than process id
of A?
I believe there is an issue when we run out of numbers (what is the
max number, BTW?), but assuming this may happen rarely, what is the
common behavior?

Thanks,

Yossi

yocohen@gmail.com writes:
>Hi,
>
>I couldn't google out the answer. Is the process id number always
>ascending? i.e. if I start process A and a second later start process
>B, can I be sure that process id of B will be bigger than process id
>of A?
>I believe there is an issue when we run out of numbers (what is the
>max number, BTW?), but assuming this may happen rarely, what is the
>common behavior?
>

The answer to your third question is:  The kernel gives the new process
the lowest unused process id, and resumes the pattern of assigning
ascending (unused) process ids to new processes.

Therefore the answer to your first question is:  No, it isn't certain
that the id for process B will be larger than for process A.

The answer to your second question is:  It depends on the particular
operating system implementation.  In some the maximum process id can
be adjusted.


-Greg
--
:::::::::::::  Greg Andrews  :::::  gerg@panix.com  :::::::::::::
I have a map of the United States that's actual size.
-- Steven Wright

On 1 Apr., 16:03, yoco...@gmail.com wrote:
> Hi,
>
> I couldn't google out the answer. Is the process id number always
> ascending?

No, not always. (Think about it; that cannot be true with any
limited range of numbers.)

> i.e. if I start process A and a second later start process
> B, can I be sure that process id of B will be bigger than process id
> of A?

No, there's a wrap around at some point. (I think at least a
15-bit number is used, so that would then be at 32767. Though,
I can imagine systems that have a larger domain.)

> I believe there is an issue when we run out of numbers (what is the
> max number, BTW?), but assuming this may happen rarely, what is the
> common behavior?

The number selection restarts from the low numbers incrementally
while using only the free (i.e. currently non-assigned) numbers.

You only "run out" of numbers if the number of running processes
exceeds a system limit; in that case, even if still free process
numbers available, you won't be able to start another process.

Janis

On Apr 1, 5:22=A0pm, g...@panix.com (Greg Andrews) wrote:
> yoco...@gmail.com writes: 
> 
>
> The answer to your third question is: =A0The kernel gives the new process
> the lowest unused process id, and resumes the pattern of assigning
> ascending (unused) process ids to new processes.
>
> Therefore the answer to your first question is: =A0No, it isn't certain
> that the id for process B will be larger than for process A.
>
> The answer to your second question is: =A0It depends on the particular
> operating system implementation. =A0In some the maximum process id can
> be adjusted.
>
> =A0 -Greg
> --
> ::::::::::::: =A0Greg Andrews =A0::::: =A0g...@panix.com =A0:::::::::::::
> =A0 =A0 =A0I have a map of the United States that's actual size.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Steven =[/color
]
Wright

Hi,

Thanks for prompt response. I find some ambiguity in the answer as I
understand it, so I will rephrase the question :)
Assuming there is no number limit, will process id be assigned in
ascending pattern?

Thanks,

Yossi

yocohen@gmail.com wrote:
> Hi,
>
> I couldn't google out the answer. Is the process id number always
> ascending? i.e. if I start process A and a second later start process
> B, can I be sure that process id of B will be bigger than process id
> of A?
> I believe there is an issue when we run out of numbers (what is the
> max number, BTW?), but assuming this may happen rarely, what is the
> common behavior?

No, I don't know the algorithm AIX chooses the next PID but you cannot
rely on increasing PIDs:

$ sh -c 'echo $$'
2244706
$ sh -c 'echo $$'
2244708
$ sh -c 'echo $$'
2187416
$ sh -c 'echo $$'
2244712
$ sh -c 'echo $$'
2203804

You see? There seems to be a pattern, but nothing you can depend on.

pid_t is on most system a 32 bit signed integer. So in theory PIDs could
go up to MAX_INT. In practise most OS wrap PIDs around MAX_SHORT.

Solaris wraps at 30000, this can be adjusted by setting pidmax in
/etc/system. FreeBSD used to wraps at 32767, now wraps at 99999 (to avoid
formatting problems where only 5 chars are reserved for printing PIDs, like
in printf("%5d", pid))

So you should put no assumption on PIDs in your scripts.

--
Daniel

On 2008-04-01, yocohen@gmail.com <yocohen@gmail.com> wrote:
> Hi,
>
> I couldn't google out the answer. Is the process id number always
> ascending? i.e. if I start process A and a second later start process
> B, can I be sure that process id of B will be bigger than process id
> of A?

No.  Any system may start recycling PIDs if it runs long enough.  Some
systems (AIX, for example) deliberately do not assign PIDs in any kind
of sequential manner as a security measure.

> I believe there is an issue when we run out of numbers (what is the
> max number, BTW?), but assuming this may happen rarely, what is the
> common behavior?
>
The common behavior is that you should make no assumptions about how
PIDs will be assigned other than each process will have a unique one.

--
Christopher Mattern

NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities

On 2008-04-01, Greg Andrews <gerg@panix.com> wrote:
> yocohen@gmail.com writes: 
>
> The answer to your third question is:  The kernel gives the new process
> the lowest unused process id, and resumes the pattern of assigning
> ascending (unused) process ids to new processes.

Not always; this is not required behavior and some systems do not conform
to it.  If you intend your code to be portable, you should not rely on this
being the case.


--
Christopher Mattern

NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities

On 2008-04-01, Daniel Rock <v200814@deadcafe.de> wrote:
> yocohen@gmail.com wrote: 
>
> No, I don't know the algorithm AIX chooses the next PID but you cannot
> rely on increasing PIDs:
>
> $ sh -c 'echo $$'
> 2244706
> $ sh -c 'echo $$'
> 2244708
> $ sh -c 'echo $$'
> 2187416
> $ sh -c 'echo $$'
> 2244712
> $ sh -c 'echo $$'
> 2203804
>
As I stated in another post, AIX deliberately scrambles PIDs as a
security measure.  It is common for PIDs to be assigned in a
mostly sequential, ascending fashion, but it is not a part of
any standard specification and some systems do not do it.  It is
not good programming practice to rely on this behavior.

--
Christopher Mattern

NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities

On Apr 1, 1:11 pm, Chris Mattern <sys...@sumire.gwu.edu> wrote:
> On 2008-04-01, yoco...@gmail.com <yoco...@gmail.com> wrote:
> 
> 
>
> No.  Any system may start recycling PIDs if it runs long enough.  Some
> systems (AIX, for example) deliberately do not assign PIDs in any kind
> of sequential manner as a security measure.
> 
>
> The common behavior is that you should make no assumptions about how
> PIDs will be assigned other than each process will have a unique one.

Clarifying, not contradicting:
PIDs are only unique among running processes.  You can't be sure that
the process with pid 100 is the same process at time X as the process
that has PID 100 at time Y, unless you know that the first process is
still running.

Hi sjdevnull! :-)

sjdevnull@yahoo.com wrote:
> On Apr 1, 1:11 pm, Chris Mattern <sys...@sumire.gwu.edu> wrote:
> 
>
>
> Clarifying, not contradicting:
> PIDs are only unique among running processes.

I am not sure that's a perfect clarification :-}

The process will keep that PID even if not "running", e.g. if waiting
for I/O or being otherwise suspended.

Once a process terminated and is removed from the process table the
PID can be re-assigned.

> You can't be sure that
> the process with pid 100 is the same process at time X as the process
> that has PID 100 at time Y, unless you know that the first process is
> still running.

Janis