Bug in System V relating to accounting

[mash at mips.UUCP]

In article <132 at milford.UUCP> bill at milford.UUCP (bill) writes: 
>> I have recently found a bug relating to System V accounting.
>  . . .
>> I did a little research and found the problem.  The "start time" 
>> of his shell was 10pm, the night before, and therefore got 
>> charged for the cpu of his shell as if he was on all night (as 
>> far as p/np goes).  This is because 'exec' does not reset the 
>> start time to the current time, and user b's shell is the same 
>> process as the getty that was started the night before.  
>> 
>> This is somewhat of a philosophical problem.  Should the start 
>> time be the creation time of the process (i.e., pid), or should 
>> it be the time of the most recent 'exec'?  
>> 
>> In any case, it's a bug in System V accounting, and the same 
>> problem might exist in 4.2BSD.  
>> 
>
>I noticed this way back before SYS V was released (System 4.something
>at BTL) and just assumed it was a 'feature'; I remember some jokes
>about it being a precursor of The Phone Company's "Network Access Charge",
>after all the cpu has been spending all night just waiting for you
>to log in.

1) It wasn't particularly done on purpose!

2) On the other hand, it's hard to see how the start time can be the time of
last exec: what about all of the accumulated CPU time before that?
(i.e., it's always counted, but is it Prime or NonPrime?)
Philosophically, the accounting system's information is mostly associated
with processes, not with execs.

3) As usual with accounting systems, one can almost always find bad examples.
Suppose we used the time of last exec as the start time.  Now, I work all day,
then logoff after NonPrime time starts.  Just before I logoff, I say:
	exec /bin/echo x
to my login shell.  Do I then have all day's work treated as NonPrime?

4) All of this is the inevitable outcome of the requirements for an
accounting system.  The requirements for this one were:
	a) Provide a system that accounted for all user CPU time once and
	only once (unlike the previous shell accounting, which had its uses,
	but was not good for computer center charging.)
	b) Offer enough flexibility that different organizations could use
	it to charge (or not) in different ways.
	c) Include information useful for system performance analysis and
	assistance to system administrators in tracking down odd behavior.
	d) Don't spend too much CPU time to make the recorded information
	TOO precise (i.e., don't even think of having the kernel know
	Prime /NonPrime boundaries and emit multiple records for running
	processes that cross the boundaries.)
	e) Use accounting records whose size was a power of 2, so that
	an integral multiple fit in one disk block (desirable for
	various reasons).
	f) Do something that would not consume "too much" disk space or
	Prime CPU time. (This really meant that there were limits on how
	big accounting files could be, individually, and in total, for a day.
	Specifically, this meant it had to survive certain big PDP-11/70s
	in the Piscataway computer center.  I don't remember the numbers,
	but it meant we couldn't add anything else to the records of the
	time, because we ran out of space!)
	g) Do something that could work with both V6 (i.e., PWB 1.2) and V7.
	(many weird constraints).
Reasons f) and g) are no longer very relevant, but, as usual, as is oft
said of old code:
	"the evils that these do live on after them."
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD:  	408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086