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:
> >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: =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 =
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
> 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
> 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.
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
> 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
>
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
> On 2008-04-01, yoco...@gmail.com
>
> > 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.
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
>
>>On 2008-04-01, yoco...@gmail.com
>>
>>
>>>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.
>
>
> 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
On 2008-04-01, yocohen
>
> 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?
Yes, but you can't assume even for a minute that the limit isn't
there - wrapping around is common. I just control-Z'ed out of here
and did a quick ps:
$ ps
PID TT STAT TIME COMMAND
6011 ro T 0:01.41 slrn
17400 ro Ss 0:00.03 -ksh
26633 ro R+ 0:00.00 ps
Obviously I started my login shell before slrn, but since slrn's
PID is lower than ksh's we can see very clearly that it has wrapped
around. This kind of thing is _very_ common on a busy multiuser
machine. On a quiescent personal machine the PIDs give a much
better aprroximation of slowly incrementing over time but it is
still far too unpredictable to be relied on.
--
Andrew Smallshaw
andrews@sdf.lonestar.org
On Apr 1, 11:42=A0pm, Andrew Smallshaw
> On 2008-04-01, yocohen
>
>
>
> > 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?
>
> Yes, but you can't assume even for a minute that the limit isn't
> there - wrapping around is common. =A0I just control-Z'ed out of here
> and did a quick ps:
>
> $ ps
> =A0 PID TT STAT =A0 =A0TIME COMMAND
> =A06011 ro T =A0 =A00:01.41 slrn
> 17400 ro Ss =A0 0:00.03 -ksh
> 26633 ro R+ =A0 0:00.00 ps
>
> Obviously I started my login shell before slrn, but since slrn's
> PID is lower than ksh's we can see very clearly that it has wrapped
> around. =A0This kind of thing is _very_ common on a busy multiuser
> machine. =A0On a quiescent personal machine the PIDs give a much
> better aprroximation of slowly incrementing over time but it is
> still far too unpredictable to be relied on.
>
> --
> Andrew Smallshaw
> andr...@sdf.lonestar.org
Thanks everyone for the replies.
BTW, my problem is on a Solaris 10 machine. I have a tcsh script that
I want to add a check in its beginning. I want to add this check for a
case that someone from some reason will run several instances of this
script simultaneously. I want the script to check the minimum PID of
any other scripts like it and only the instance with the lowest PID
will continue running, others will abort. I think I will look for
other options to do it because the assumption of ascending PIDs is
crucial for this check...
Thanks,
Yossi
In article
yocohen
> BTW, my problem is on a Solaris 10 machine. I have a tcsh script that
> I want to add a check in its beginning. I want to add this check for a
> case that someone from some reason will run several instances of this
> script simultaneously. I want the script to check the minimum PID of
> any other scripts like it and only the instance with the lowest PID
> will continue running, others will abort. I think I will look for
> other options to do it because the assumption of ascending PIDs is
> crucial for this check...
Sounds like a job for a lock file. The script checks whether the file
exists; if it does, it aborts, otherwise it creates it and continues.
This is actually somewhat tricky to do atomically from a script.
BTW, tcsh is not a good shell for scripting in, I suggest you use ksh or
bash. And for creating the lock file, you may need to use something
more powerful, like perl.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
yocohen
> Thanks everyone for the replies.
> BTW, my problem is on a Solaris 10 machine. I have a tcsh script that
> I want to add a check in its beginning. I want to add this check for a
> case that someone from some reason will run several instances of this
> script simultaneously. I want the script to check the minimum PID of
> any other scripts like it and only the instance with the lowest PID
> will continue running, others will abort. I think I will look for
> other options to do it because the assumption of ascending PIDs is
> crucial for this check...
As another person already said, this is normally done via a lock file.
But to find the oldest instance of a given process list look at the
ps -o etime -p
output. This is more reliable than doing heuristics on the PID itself.
--
Daniel
On Apr 2, 12:30=A0pm, "Daniel Rock"
> yocohen
> > Thanks everyone for the replies.
> > BTW, my problem is on a Solaris 10 machine. I have a tcsh script that
> > I want to add a check in its beginning. I want to add this check for a
> > case that someone from some reason will run several instances of this
> > script simultaneously. I want the script to check the minimum PID of
> > any other scripts like it and only the instance with the lowest PID
> > will continue running, others will abort. I think I will look for
> > other options to do it because the assumption of ascending PIDs is
> > crucial for this check...
>
> As another person already said, this is normally done via a lock file.
>
> But to find the oldest instance of a given process list look at the
> =A0 =A0 =A0 =A0 ps -o etime -p
> output. This is more reliable than doing heuristics on the PID itself.
>
> --
> Daniel
Yes, I know a lock file is a better way to do it. I was looking for a
simple/easier way. I must use tcsh (I bet you all know the limitations
on existing big projects and historic code...).
Regarding the etime option - is there a way to get this time in
milliseconds because the seconds accuration is not good for me...?
Thanks,
Yossi
On 2008-04-02, yocohen
> On Apr 2, 12:30 pm, "Daniel Rock"
>> yocohen
>> > Thanks everyone for the replies.
>> > BTW, my problem is on a Solaris 10 machine. I have a tcsh script that
>> > I want to add a check in its beginning. I want to add this check for a
>> > case that someone from some reason will run several instances of this
>> > script simultaneously. I want the script to check the minimum PID of
>> > any other scripts like it and only the instance with the lowest PID
>> > will continue running, others will abort. I think I will look for
>> > other options to do it because the assumption of ascending PIDs is
>> > crucial for this check...
>>
>> As another person already said, this is normally done via a lock file.
>>
>> But to find the oldest instance of a given process list look at the
>> ps -o etime -p
>> output. This is more reliable than doing heuristics on the PID itself.
>>
>> --
>> Daniel
>
> Yes, I know a lock file is a better way to do it. I was looking for a
> simple/easier way. I must use tcsh (I bet you all know the limitations
> on existing big projects and historic code...).
> Regarding the etime option - is there a way to get this time in
> milliseconds because the seconds accuration is not good for me...?
>
> Thanks,
>
> Yossi
Lock files aren't that tough. Easiest way to do it from a shell is to
use mkdir. Since it fails if the directory already exists, it makes for
a dandy test-and-set.
--
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, 2:51 pm, Janis Papanagnou
wrote:
> Hi sjdevnull! :-)
>
>
>
> sjdevn...@yahoo.com wrote:
> > On Apr 1, 1:11 pm, Chris Mattern
>
> >>On 2008-04-01, yoco...@gmail.com
>
> >>>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.
>
> > 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.
Yes, that's better. A process has a (single) PID until it terminates
and is reaped, after that the PID may be reused. Any two processes
that exist _at the same time_ will have distinct PIDs. (and of course
if the machine dies/reboots then PIDs are all free at boot even though
the processes may not technically have been reaped).
The important thing is that PIDs aren't unique in the sense you cannot
look and see that process A has PID X, and then later on assume that
PID X refers to process A (unless you know that process A is still
around).
yocohen
> Yes, I know a lock file is a better way to do it. I was looking for a
> simple/easier way. I must use tcsh (I bet you all know the limitations
> on existing big projects and historic code...).
You can't write a 4-line /bin/sh script that calls a C shell script?
You can't call a /bin/sh script from a csh script?
On Apr 2, 10:20=A0pm, "sjdevn...@yahoo.com"
> On Apr 1, 2:51 pm, Janis Papanagnou
> wrote:
>
>
>
>
>
> > Hi sjdevnull! :-)
>
> > sjdevn...@yahoo.com wrote:
> > > On Apr 1, 1:11 pm, Chris Mattern
>
> > >>On 2008-04-01, yoco...@gmail.com
>
> > >>>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. =A0Any system may start recycling PIDs if it runs long enough. =A0=
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.
>
> > > 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.
>
> Yes, that's better. =A0A process has a (single) PID until it terminates
> and is reaped, after that the PID may be reused. =A0Any two processes
> that exist _at the same time_ will have distinct PIDs. =A0(and of course
> if the machine dies/reboots then PIDs are all free at boot even though
> the processes may not technically have been reaped).
>
> The important thing is that PIDs aren't unique in the sense you cannot
> look and see that process A has PID X, and then later on assume that
> PID X refers to process A (unless you know that process A is still
> around).- Hide quoted text -
>
> - Show quoted text -
Yes, I never said I rely on the same PIDs.
Thanks.
On Apr 2, 11:10=A0pm, Maxwell Lol
> yocohen
> > Yes, I know a lock file is a better way to do it. I was looking for a
> > simple/easier way. I must use tcsh (I bet you all know the limitations
> > on existing big projects and historic code...).
>
> You can't write a 4-line /bin/sh script that calls a C shell script?
>
> You can't call a /bin/sh script from a csh script?
Yes, I believe anything can be done. But being a Windows/Java person I
am looking for the fastest simple solution that will not take me too
much into those scripts. It already took more time than I intended.
But it was interesting...
Thanks for the help!
Only one running instance is allowed.
Just one line.
It uses grep and output from ps command.
I dont know if this works in your system.
#!/bin/tcsh
ps ha|grep -v "^$$ "|grep -q "/bin/tcsh $0"&&exit
#just for testing
echo started...
sleep 30
yocohen wrote:
> Yes, I believe anything can be done. But being a Windows/Java person I
> am looking for the fastest simple solution that will not take me too
> much into those scripts. It already took more time than I intended.