It's not a problem for anybody, just a curiosity. Another senior system
admin here from a Solaris background was asking me why, under AIX 4.3.3 and
5.x, all process IDs were even (except for init, pid 1, of course).

So I looked... golly, he was right. Nothing obvious leaps to mind. The pids
are randomized with 5.x, but still appears to only be even numbers except
for init.

Does anyone know why? We'd be much interested in the design reason for it
if anyone knows, solely to satisfy a point of curiosity.

-Dan

Dan Foster <dsf@globalcrossing.net> wrote:
DF> It's not a problem for anybody, just a curiosity. Another senior system
DF> admin here from a Solaris background was asking me why, under AIX 4.3.3 and
DF> 5.x, all process IDs were even (except for init, pid 1, of course).

DF> So I looked... golly, he was right. Nothing obvious leaps to mind. The pids
DF> are randomized with 5.x, but still appears to only be even numbers except
DF> for init.

DF> Does anyone know why? We'd be much interested in the design reason for it
DF> if anyone knows, solely to satisfy a point of curiosity.

If what you're reporting is indeed correct, and I had to guess, I'd
probably say that it's because of the steps of the pid creation
algorithm is to shift the number one or more positions to the left.
Notice that all of the numbers generated by this one-liner are even.

perl -wle 'print rand(~0)<<1 for 0..10'

It's just a guess, of course. Even if it's correct, I don't have
an explanation for why an operating system designer would do this.

Perhaps its origin is in some military security requirements document.
Sun has, or used to have, a separate product for "military-grade"
security, called Trusted Solaris, but IBM sells the same operating
system product to all comers. This might explain the difference.
(Again, assuming the difference exists. I don't have access to
AIX boxes these days.)

Regards,

Nicholas

--
http://www.faqs.org/rfcs/rfc1855.html
3.1.1 General Guidelines for mailing lists and NetNews
3.1.3 NetNews Guidelines

Nicholas Dronen wrote:
> Dan Foster <dsf@globalcrossing.net> wrote:
> DF> It's not a problem for anybody, just a curiosity. Another senior system
> DF> admin here from a Solaris background was asking me why, under AIX 4.3.3 and
> DF> 5.x, all process IDs were even (except for init, pid 1, of course).
>
> DF> So I looked... golly, he was right. Nothing obvious leaps to mind. The pids
> DF> are randomized with 5.x, but still appears to only be even numbers except
> DF> for init.
>
> DF> Does anyone know why? We'd be much interested in the design reason for it
> DF> if anyone knows, solely to satisfy a point of curiosity.
>
> If what you're reporting is indeed correct, and I had to guess, I'd
> probably say that it's because of the steps of the pid creation
> algorithm is to shift the number one or more positions to the left.
> Notice that all of the numbers generated by this one-liner are even.
>
> perl -wle 'print rand(~0)<<1 for 0..10'
>
> It's just a guess, of course. Even if it's correct, I don't have
> an explanation for why an operating system designer would do this.
>
> Perhaps its origin is in some military security requirements document.
> Sun has, or used to have, a separate product for "military-grade"
> security, called Trusted Solaris, but IBM sells the same operating
> system product to all comers. This might explain the difference.
> (Again, assuming the difference exists. I don't have access to
> AIX boxes these days.)
>
> Regards,
>
> Nicholas
>


nope. pids are even tids (thread ids) are odd. Take a look in crash
or kdb. I guess each process gets one thread when its started which
has a tid = pid+1.

-- Jason

Dan Foster wrote:

> Does anyone know why? We'd be much interested in the design reason for it
> if anyone knows, solely to satisfy a point of curiosity.
>
> -Dan

Probably no one will tell your the design reason.

I know how PID is formed, but that's not your question :-)
They're certainly not random.
Obviously AIX doens't use the lowest bit for PID.

In article <0k2Ob.307$Md6.27@fe2.texas.rr.com>, Tao Chen <opinion@taochen.com> wrote:
> Dan Foster wrote:
>
>> Does anyone know why? We'd be much interested in the design reason for it
>> if anyone knows, solely to satisfy a point of curiosity.
>>
>> -Dan
>
> Probably no one will tell your the design reason.

It's worth an ask. I don't know if any kernel developers from Austin
hangs out here. One or two used to, but most usually has more pressing
things to do, and I'm sure, a lot tires of simple questions or whatever.
Understandable.

I've been to IBM's Austin labs -- it's a very nice place, as is the town.
(Sixth Street, hill country, reduced traffic jams during rush hour on
Burnet Road, etc... It's just too bad the economy's shrunk a little for
tech workers.)

> I know how PID is formed, but that's not your question :-)
> They're certainly not random.
> Obviously AIX doens't use the lowest bit for PID.

Well, there's init... which is pid 1. If it uses a conventional process ID
scheme in the in-memory PCB, that would occupy the lowest bit. (2^0 set = 1)

Other than the init discrepancy, not using the lowest bit would otherwise
explain the even-ness nature of process IDs. Or another way to explain it
would be an algorithm that uses a modulo 2 scheme of some sort.

Unless there's some special flag/bit that if set, identifies itself as
being init, without having to occupy the lowest bit.

I misspoke when I said 'random'... perhaps really meant that there is some
numeric algorithm that selects pids that is deterministic and not random,
but as far as the average user is concerned, essentially non-deterministic
or random to them.

That's a very good thing because it makes it much harder for certain
security attacks to succeed -- namely the ones that guesses or tries to
force a particular guessed/known process to be created in order to exploit
something like a man-in-the-middle situation, an elevated priv race, or
whatever.

That's one of the many things that we occasionally have to audit our
systems and applications for while evaluating security needs, design, and
issues.

Linux has a get_pid() function in /usr/src/linux/kernel/fork.c that's
interesting. With the grsecurity patches applied, it generates a *very*
well done random pid. Else, it takes the last allocated pid, runs by an AND
mask, makes sure it's at least 300 (to skip boot-time daemons that usually
lives between pid 2-299...rather arbitrary, I know...), make sure it
doesn't exceed PID_MAX, etc.

I've got the Solaris Foundation sources somewhere around here for personal
edification along with the Solaris Internals book written by a Sun kernel
developer (Jim Mauro), but don't recall if pid creation stuff were listed
in either the Foundation sources or the book. I'll have to get both from
storage at home and look.

FreeBSD has sysctl_kern_randompid() in /usr/src/sys/kern/kern_fork.c but
that appears to use a much more simplistic algorithm. I think part of the
randomization uses some sort of modulus. pid selection under FreeBSD v5
bothers me because it doesn't seem particularly well done... quite
sequential.

Under Linux, FreeBSD, and Solaris (most of the major platforms that we
manage at work), they all have pids that are both even and odd... so that's
how the new-to-AIX colleague noticed the AIX pids.

Ultimately, it's not a problem re: AIX pid scheme -- it's just a simple
nagging curiosity. Nothing our homemade system admin tools (shell scripts,
python, perl, Tcl, C, etc) does even cares about pid schemes, and they
certainly don't go mucking around in kernel space since they're expected to
be platform independent due to our environment of hundreds of servers and
multiple platforms as well as a wide range of OS versions.

-Dan

Jason Mather wrote:

> nope. pids are even tids (thread ids) are odd. Take a look in crash
> or kdb. I guess each process gets one thread when its started which
> has a tid = pid+1.

... except init, which is 1. otherwise, pids are even, tids are odd. this
was mentioned in my cert class, Q1811.

-r

Hi Dan,

> It's worth an ask. I don't know if any kernel developers from Austin
> hangs out here. One or two used to, but most usually has more pressing
> things to do, and I'm sure, a lot tires of simple questions or whatever.
> Understandable.

Most questions here are sys-admin and ISV related, very few touch kernel
area ( internal design and implementation ).

> I've been to IBM's Austin labs -- it's a very nice place, as is the town.
> (Sixth Street, hill country, reduced traffic jams during rush hour on
> Burnet Road, etc... It's just too bad the economy's shrunk a little for
> tech workers.)

I am on the "other" side of the Burnet Road, i.e. the "old" side.
The developer's side of area is much nicer

Just saw the news about IBM going to hire more people this year,
not sure how many will be in Austin.

>>I know how PID is formed, but that's not your question :-)
>>They're certainly not random.
>>Obviously AIX doens't use the lowest bit for PID.
>
> Well, there's init... which is pid 1. If it uses a conventional process ID
> scheme in the in-memory PCB, that would occupy the lowest bit. (2^0 set = 1)
> Other than the init discrepancy, not using the lowest bit would otherwise
> explain the even-ness nature of process IDs. Or another way to explain it
> would be an algorithm that uses a modulo 2 scheme of some sort.
>
> Unless there's some special flag/bit that if set, identifies itself as
> being init, without having to occupy the lowest bit.

init doesn't go through the normal Process creation procedure.

> I misspoke when I said 'random'... perhaps really meant that there is some
> numeric algorithm that selects pids that is deterministic and not random,
> but as far as the average user is concerned, essentially non-deterministic
> or random to them.

Actually, part of the PID is decided by its process slot number (PSLOT),
and another part is called "Generation Count", which is used to prevent
the rapid re-use of PIDs (PSLOT can be re-used immediately).

In 32bit kernel: PSLOT = PID/256
In 64bit kernel: PSLOT = PID/8192 ( 5.1 )
PSLOT = PID/4096 ( 5.2 )

This is covered in the "AIX Kernel Internal I" class.

> Ultimately, it's not a problem re: AIX pid scheme -- it's just a simple
> nagging curiosity. Nothing our homemade system admin tools (shell scripts,
> python, perl, Tcl, C, etc) does even cares about pid schemes, and they
> certainly don't go mucking around in kernel space since they're expected to
> be platform independent due to our environment of hundreds of servers and
> multiple platforms as well as a wide range of OS versions.
>
> -Dan

I know. No program should make assumption of anything that undocumented.

Tao

In article <QTnOb.82051$WS1.3165@fe1.texas.rr.com>, Tao Chen <opinion@taochen.com> wrote:
> Hi Dan,

Hello!

> Most questions here are sys-admin and ISV related, very few touch kernel
> area ( internal design and implementation ).

That's true.

> I am on the "other" side of the Burnet Road, i.e. the "old" side.
> The developer's side of area is much nicer



> Just saw the news about IBM going to hire more people this year,
> not sure how many will be in Austin.

I heard a little about that... supposed to be about 4500 in the U.S., but
don't know where exactly.

> init doesn't go through the normal Process creation procedure.

Indeed.

> Actually, part of the PID is decided by its process slot number (PSLOT),
> and another part is called "Generation Count", which is used to prevent
> the rapid re-use of PIDs (PSLOT can be re-used immediately).
>
> In 32bit kernel: PSLOT = PID/256
> In 64bit kernel: PSLOT = PID/8192 ( 5.1 )
> PSLOT = PID/4096 ( 5.2 )
>
> This is covered in the "AIX Kernel Internal I" class.

Ahh! That *is* interesting, thanks. Guess I'll have to take that class at
some point sooner than later, then.

> I know. No program should make assumption of anything that undocumented.

Indeed.

-Dan

Dan Foster <dsf@globalcrossing.net> wrote:
DF> In article <QTnOb.82051$WS1.3165@fe1.texas.rr.com>, Tao Chen <opinion@taochen.com> wrote:

>> Just saw the news about IBM going to hire more people this year,
>> not sure how many will be in Austin.

DF> I heard a little about that... supposed to be about 4500 in the U.S., but
DF> don't know where exactly.

Here's a link to the Reuters story on CNN:

http://xrl.us/bctm

A few notable items:

An article in The Wall Street Journal in December said IBM
planned to move 4,730 highly skilled software jobs from the
United States to India. MacDonald said that figure was
incorrect but he declined to say how many jobs were being
sent overseas.

. . .

IBM will hire 15,000 new employees in 2004, with an additional
4,500 jobs in the United States, a top executive said
Saturday.

"We are going to hire more in the U.S. than we shift"
overseas, said Randy MacDonald, IBM's senior vice president
for human resources.

MacDonald forgot to add, "but barely." :-)

Last fall, with signs of growth starting to emerge, chief
executive Samuel Palmisano said IBM would hire 10,000 new
employees in 2004 in "hot" segments, such as software for doing
business over the Internet and services to support wireless
technology and the growing Linux operating system.

The decision to add 5,000 jobs was made in the past few
weeks, MacDonald said.

Discussing where the hiring will occur, MacDonald said that was
a matter of the availability of the technical skills and customer
needs, as well as cost. IBM's plans do not favor one geographic
region over another.

No one knows where the jobs will be. And it's not obvious what the
jobs will be. (Phone jockeys? Router jockeys? People who know how
to type 'ls' at a Bash prompt?) While this is good news for people
in the tech sector, it's obvious that this is also tail-covering PR
on IBM's part.

In the big picture, the economy needs to add 100,000 jobs per *month*
just to keep up with the growth in the working-age population. That
hasn't been happening for a while. The official unemployment figure
is down slightly, but most of that is due to people giving up looking
for work:

http://xrl.us/bcvi

Let's hope what's happening with IBM will happen with many more
companies in the next 12 months.

Regards,

Nicholas

--
http://www.faqs.org/rfcs/rfc1855.html
3.1.1 General Guidelines for mailing lists and NetNews
3.1.3 NetNews Guidelines