PID assignment

PID assignment

Post by Volker Englis » Fri, 31 Mar 2000 04:00:00



When logging in, then executing ps, I normally see a ps output like
e.g.:

1855 -sh
1857 ps

But sometimes it shows like this e.g.:

 260 -sh
1857 ps

So I wonder what way PIDs are assigned. The first example looks
logical, but in the second one, why is that big hole between the login
shell and further processes? I'd simply like to understand why that is
this way...

(OS is Debian linux kernel 2.0 if thats important for finding a clue).

Thanks a lot.

Volker

 
 
 

PID assignment

Post by Chris Costell » Sat, 01 Apr 2000 04:00:00



> So I wonder what way PIDs are assigned. The first example looks
> logical, but in the second one, why is that big hole between the login
> shell and further processes? I'd simply like to understand why that is
> this way...

   Typically operating systems will assign them incramentally.
This means that each program that has been started between your
login shell and the program you just ran from your login shell
incramented the PID number.  Let's say you ran 3,890 programs
between spawning your login shell and now.  (And look, I just
happened to have done just that over the past week.)

$ ps -o 'pid,ppid,command'
  PID  PPID COMMAND
45454 45453 ksh
49434 45454 ps -o pid,ppid,command

   Now when you have process 2001, 2002, 2003 and 2004, 2004
being the most recently spawned process on the system, when 2002
dies, the next PID assigned will still be 2005.  The PID 2002
will not be reassigned until the counter recycles back to 0, at
least on systems that do this.

   However, on some systems (at least FreeBSD with a certain
option), you have the option to assign a random PID to new
processes.  The only drawback this has is that it would be
substantially harder to predict what the next PID will be
(essentially it will be impossible).


P.S.  The option to enable random PIDs in FreeBSD as of version
      4.0 is controlled by the sysctl MIB ``kern.randompid'' for
      those that are interested.

 
 
 

PID assignment

Post by Benjamin J. Robinso » Sat, 01 Apr 2000 04:00:00



Quote:>    However, on some systems (at least FreeBSD with a certain
> option), you have the option to assign a random PID to new
> processes.  The only drawback this has is that it would be
> substantially harder to predict what the next PID will be
> (essentially it will be impossible).

Interesting -- what is the advantage of having random PIDs?  Is there a
security advantage in not being able to predict what the PID of a new
process would be?  I would think the next PID would be hard to predict
even in a sequential system, since other users and daemons would also be
asynchronously spawning processes as the same time you are.

-Benjamin Robinson
--
"The government cannot reduce the * population to reading or viewing only
            to what is appropriate for children."  -- Bruce Ennis
My opinions don't represent, and are likely contrary to, those of my employer.
This message may or may not contain sarcastic content; your burden to decide.

 
 
 

PID assignment

Post by Barry Margoli » Sat, 01 Apr 2000 04:00:00





>>    However, on some systems (at least FreeBSD with a certain
>> option), you have the option to assign a random PID to new
>> processes.  The only drawback this has is that it would be
>> substantially harder to predict what the next PID will be
>> (essentially it will be impossible).

>Interesting -- what is the advantage of having random PIDs?  Is there a
>security advantage in not being able to predict what the PID of a new
>process would be?  I would think the next PID would be hard to predict
>even in a sequential system, since other users and daemons would also be
>asynchronously spawning processes as the same time you are.

Many scripts use $$ in the generation of temporary filenames; if someone
creates a symlink with the name of a file that the script is about to write
to, the script will write to the target file (most scripts are not very
careful about checking whether the temp file already exists, and even if
they do there's usually still a small window of opportunity to create it
after the check).

I wouldn't be surprised if some random-number generators that might be used
in cryptography use the PID as part of the seed, so making this hard to
predict could help them.

--

GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

 
 
 

PID assignment

Post by Volker Englis » Wed, 05 Apr 2000 04:00:00



Quote:>> So I wonder what way PIDs are assigned. The first example looks
>> logical, but in the second one, why is that big hole between the login
>> shell and further processes? I'd simply like to understand why that is
>> this way...

>   Typically operating systems will assign them incramentally.
>This means that each program that has been started between your
>login shell and the program you just ran from your login shell
>incramented the PID number.

Hi Chris!

Well, thanks for the explanation. Okay so far, but this is a snapshot
*immediately* after login (the system has just been booted, for the
pids being that low):

  PID TTY STAT TIME COMMAND
  161  S0 S    0:04 -sh
  480  S0 R    0:00 ps

There is not a single entry in my ~/.profile, and there are certainly
not more than 300 processes that ran between.

One possible reason was that the getty for this port was initialized as
pid 161, and the login shell continues using that getty pid. Is this
the clue? After booting, my login was the first login process on that
port, so the missing 319 pids could be processes that have been running
between booting and login.

Volker.

 
 
 

PID assignment

Post by Ken Pizzi » Sat, 08 Apr 2000 04:00:00



Quote:>Well, thanks for the explanation. Okay so far, but this is a snapshot
>*immediately* after login (the system has just been booted, for the
>pids being that low):

>  PID TTY STAT TIME COMMAND
>  161  S0 S    0:04 -sh
>  480  S0 R    0:00 ps

>There is not a single entry in my ~/.profile, and there are certainly
>not more than 300 processes that ran between.

>One possible reason was that the getty for this port was initialized as
>pid 161, and the login shell continues using that getty pid. Is this
>the clue? After booting, my login was the first login process on that
>port, so the missing 319 pids could be processes that have been running
>between booting and login.

Correct.  getty exec()s login which in turn exec()s your shell,
without any fork() calls in the chain.  A new process id is
only allocated when fork() is called, and so your login shell
will wind up with the same pid as the getty which (indirectly)
spawned it had.  But if any 318 process were fork()ed between
the time the ttyS0 getty was created and the time you ran your
ps (your ps being the 319th), the above ps listing is an
expected result.

                --Ken Pizzini

 
 
 

1. Assignment of PIDs

Does someone know how AIX assigns new process IDs, or can someone tell
me where I can find information about this in the manuals ?

The reason I ask this question is because AIX appears to re-use unused
process IDs after a relatively short period of time. I've come to this
conclusion because I'm writing to files whose names are based on process
IDs, and I find that 2 different processes have written to the same file,
with an interval of about 1 hour between the two. I'm certain that these
are 2 different processes, but since they've written to the same file
then they must have the same process ID. Is there some way I can change
this method of assignment ?

By the way, I'm talking about AIX 3.2 on an RS6000.

Thanks in advance.
--

2. Shutdown problems

3. How to find children PID's given parent PID?

4. Quick Backup

5. NSCA: "Could not log pid to file httpd.pid"

6. Rutgers, Linux and Slip

7. cygwin, unix pid to windows pid

8. Core Dump when execute the output

9. Getting children's PID with parent's pid?

10. About PID, PPID, and how to find processes with such PID

11. Appache : can not log pid to httpd.pid

12. wait PID for an arbitrary PID

13. Passing VARIABLE from one pid to another pid