Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
PID number generation 1
- Thread starter michaelvv
- Start date
-
1
- #3
- Thread starter
- #4
Michael, it's the other way around (PSLOT number is low number, PID numbers are high)...
If you look at [tt]pstat -a[/tt] output, you can deduce that PID number is PSLOT number times a factor plus some offset.
On AIX53, I have PID=PSLOT*4096+offset
So I'm betting that this offset (I've seen it called generation count on some info I googled) is incremented at every reuse of the PSLOT number.
For every PSLOT number, it would theoretically take up to a maximum of 4096 generations for the same PID number to come up again. But it is probably half of 4096 (or less) as apparently PID numbers on AIX in this schema are always EVEN, the PID 1 for [tt]init[/tt] being the exception...
So you'd be pretty safe in assuming the same PID won't come up again in the same 24hr period, unless you have a server that has massive amounts of short running (sub-second) processes... And probably the kernel programmers accounted for this and would probably block the re-use that PSLOT number for the remainder of that 24hr period or distribute the rapid restarting processes evenly among all free PSLOT numbers to avoid that scenario.
Anyway, this is just google-and-guess-work so maybe I will want to find out for real on the AIX Kernel Internals class some day soon... ;-)
HTH,
p5wizard
If you look at [tt]pstat -a[/tt] output, you can deduce that PID number is PSLOT number times a factor plus some offset.
On AIX53, I have PID=PSLOT*4096+offset
So I'm betting that this offset (I've seen it called generation count on some info I googled) is incremented at every reuse of the PSLOT number.
For every PSLOT number, it would theoretically take up to a maximum of 4096 generations for the same PID number to come up again. But it is probably half of 4096 (or less) as apparently PID numbers on AIX in this schema are always EVEN, the PID 1 for [tt]init[/tt] being the exception...
So you'd be pretty safe in assuming the same PID won't come up again in the same 24hr period, unless you have a server that has massive amounts of short running (sub-second) processes... And probably the kernel programmers accounted for this and would probably block the re-use that PSLOT number for the remainder of that 24hr period or distribute the rapid restarting processes evenly among all free PSLOT numbers to avoid that scenario.
Anyway, this is just google-and-guess-work so maybe I will want to find out for real on the AIX Kernel Internals class some day soon... ;-)
HTH,
p5wizard
That's so odd - why and where are you getting this from? It's certainly not 4096, although it does look like they're spaced apart but it seems to be by 102h:
3 a 306 0 0 0 0 1 sched
FLAGS:swapped_inno_swapfixed_prikproc
4 a 408 0 0 0 0 1 lrud
FLAGS:swapped_inno_swapfixed_prikproc
Most of them are oddly enough like this for unclear reasons.
Doesn't really add up with ps though:
daemon 55512 1 0 08:53:00 - 0:00 send-mail -i -x djprod
daemon 55664 1 0 08:59:00 - 0:00 send-mail -i -x djprod
As these are less than 100h apart...
On an AIX 53 LPAR:
[tt]
# pstat -a|head -3; pstat -a|grep sleep|tail -1
PROC TABLE:
SLT ST PID PPID PGRP UID EUID TCNT NAME
331 a 14b070 c00e6 d0082 0 0 1 sleep
[/tt]
SLT number 331 (apparently in decimal)
PID number 14b070 (apparently in hex)
[tt]
# bc
ibase=16
14B070
1355888
[/tt]
So 14b070 hex is 1355888 in decimal
[tt]
# bc -l
1355888/331
4096.33836858006042296072
[/tt]
so for this generation number (which I assume to be 112)
[tt]
(SLT x 4096) + GEN = PID
(331 x 4096) + 112 = 1355888
[/tt]
That is my best guess of course... ;-)
And AIX version and kernel size (32 or 64bit) also have a say in this...
HTH,
p5wizard
[tt]
# pstat -a|head -3; pstat -a|grep sleep|tail -1
PROC TABLE:
SLT ST PID PPID PGRP UID EUID TCNT NAME
331 a 14b070 c00e6 d0082 0 0 1 sleep
[/tt]
SLT number 331 (apparently in decimal)
PID number 14b070 (apparently in hex)
[tt]
# bc
ibase=16
14B070
1355888
[/tt]
So 14b070 hex is 1355888 in decimal
[tt]
# bc -l
1355888/331
4096.33836858006042296072
[/tt]
so for this generation number (which I assume to be 112)
[tt]
(SLT x 4096) + GEN = PID
(331 x 4096) + 112 = 1355888
[/tt]
That is my best guess of course... ;-)
And AIX version and kernel size (32 or 64bit) also have a say in this...
HTH,
p5wizard
Could be 256 it looks like. - Thread starter
- #9
Point is, Michael asked a question and I became curious, that's all.
And I also found out that it is easy to make the system use the same PIDs over and over.
[tt]
while true
do
ps | grep [p]s
done >/tmp/ps.out
[/tt]
(let run for a couple of minutes, then hit ctrl-C)
[tt]
sort /tmp/ps.out|uniq -c|sort
[/tt]
(see duplicate/triplicate/more... counts at the end of the output)
So a lot of short lived processes may lead to PIDs being reused within a relatively short time period.
HTH,
p5wizard
And I also found out that it is easy to make the system use the same PIDs over and over.
[tt]
while true
do
ps | grep [p]s
done >/tmp/ps.out
[/tt]
(let run for a couple of minutes, then hit ctrl-C)
[tt]
sort /tmp/ps.out|uniq -c|sort
[/tt]
(see duplicate/triplicate/more... counts at the end of the output)
So a lot of short lived processes may lead to PIDs being reused within a relatively short time period.
HTH,
p5wizard
- Thread starter
- #11
- Thread starter
- #13
That is true, but sadly enough, it is also used as a tag to identify a sequence of events in an application log which over its 24 hour lifetime ends up with the same tag for multiple transactions. At least I know what I have to work with. Thanks for your help, you ARE the wizard!
- Status