naftoli@aecom.UUCP (Robert N. Berlinger) (05/07/86)
I have recently found a bug relating to System V accounting.
Consider the following scenario:
1. User 'a' logs out at 10pm. A new getty is spawned for the
tty and hangs around waiting for next lucky soul to come
along.
2. User 'b' comes in at 9am the next morning and logs in to the
same tty. He logs out five minutes later.
3. User 'b' comes to me the next morning. He's noticed that he
has some non-prime cpu charges, even though he never logged in
at night.
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.
Suggested fixes (other than major mods to getty to make it fork,
I can't even think of the ramifications of that one...) would be
welcome.
--
Robert Berlinger
...{philabs,cucard,pegasus,ihnp4,rocky2}!aecom!naftolimash@mips.UUCP (05/12/86)
In article <132@milford.UUCP> bill@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
narayan@wg3b20.UUCP (05/16/86)
Just use the -t flag to getty in the inittab file
eg.
02:2:respawn:/etc/getty -t60 tty02 9600
This forces a new getty every minute on that line.
It is a not a very clean work around. But it would
do the trick.
--
Narayan Mohanram
Phone: 415-962 7170
ARPANET wg3b20!narayan@lll-tis-b.ARPA
Usenet ihnp4!{amdahl,pesnta}!wg3b20!narayan
Mail The Wollongong Group
1129 San Antonio Road
Palo Alto, CA 94303. USA
=========================================================
|| If you can't lick it, try some whipped cream ||
=========================================================