Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!netsys!vector!rpp386!jfh
From: jfh@rpp386.Dallas.TX.US (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: pid rollover?
Summary: don't worry.  happens all the time ;-)
Message-ID: <11992@rpp386.Dallas.TX.US>
Date: 29 Jan 89 15:52:31 GMT
References: <460@oglvee.UUCP>
Reply-To: jfh@rpp386.Dallas.TX.US (John F. Haugh II)
Organization: River Parishes Programming, Dallas TX
Lines: 56

In article <460@oglvee.UUCP> jr@oglvee.UUCP (Jim Rosenberg) writes:
>Our system is an Altos 2000 running Xenix System V.  The CPU is a 386, and the
>C compiler produces 4 as sizeof(int).  However we seem to be hitting rollover
>of pids at 32K, implying that the kernel must be using short as the type of a
>pid -- at least internally.  I have two questions.  Why wouldn't the kernel use
>a true int for a pid, preventing rollover until 2147483647 or so?  Surely this
>isn't just because someone thought it would louse up the output format of ps??

I can't answer for the EXACT reason this was done this way, but can explain
the behaviour better.

For starters, PID's roll over at 30000 exactly.  The code goes something
like

	if (nextpid == 30000)
		nextpid = 1;

So it is quite intentional.  Why an unsigned short wasn't used might really
be a good question since 64K can be expressed in as many digits as 30,000
can.

>As system administrator should I be concerned about letting the pids roll over?
>We've had this happen several times with no apparent ill effects.

I administer several systems.  This one rolls over every 4 days or so, the
large system at work rolls over about once a week.  They do this so long as
they are up continuously and never have had problems because of it.

> I'm not
>concerned about the kernel -- it seems to know what to do when pids roll over.

Correct.  In the same code there is another loop which scans the process
table looking for a process already using that PID.  If it finds one, it
increments `nextpid' and starts all over again.  Eventually it must find a
process ID it can use ...

>But what about all those programs using mktemp() or $$ ?  Does anyone have any
>horror stories about applications that behaved badly after pid rollover?

Insuring the process ID is unique should do the trick.  Failing that, I
have used the process group ID or parent process ID if a process was supposed
to leave temp files remaining to be used by another process after it had
exited.

I don't think you would have to worry unless your system is generating
new processes at a rate high enough to have multiple rollovers per day.

On a side bar - there are systems where the process ID is a long for
exactly this sort of reason.  Imagine how many active processes an
Amdahl 58xx or Cray X/MP would have?  If a 3MIP 68020 has 400 process
slots, how many would you put in your 400 user mainframe?
-- 
John F. Haugh II                        +-Ad of the Week:----------------------
VoiceNet: (214) 250-3311   Data: -6272  |"Your hole is our goal"
InterNet: jfh@rpp386.Dallas.TX.US       |     -- Gearhart Wireline Services
UucpNet : <backbone>!killer!rpp386!jfh  +------  Shrevesport, LA  -------------