Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site wgivax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!mcnc!unccvax!wgivax!fpt
From: fpt@wgivax.UUCP (Fred Toth)
Newsgroups: net.unix-wizards
Subject: UNIX per-process accounting
Message-ID: <158@wgivax.UUCP>
Date: Tue, 8-Apr-86 14:15:53 EST
Article-I.D.: wgivax.158
Posted: Tue Apr  8 14:15:53 1986
Date-Received: Thu, 10-Apr-86 20:57:32 EST
Lines: 66

Once again, I need to tap the wisdom of the community.
Here goes:

At Washburn, we have used the UNIX accounting system as
a base for charging customers for work we do for them.

Since our people may be banging away at several different
jobs at one time, we need to know which grep, sort, ls, etc.,
goes with which customer's job.

Since a customer's job related files are always in directory
subtrees, we decided long ago that we needed to know not only
what commands were run, but WHERE ('current' directory) in the
file system they were run. We made minor changes, first in
version 7, later in 4.2, to the definition of the accounting
record (acct(5)), and the kernel routines that fill the record.
We added fields for the device and inode number of the 'current'
directory. A script that runs in off hours decides whether a
given accounting record is chargeable to a customer or not,
based on whether the current directory is in an active list.

Well, this has worked very well for years. But now we would like
to distribute some of our work to another system (Sun 3). We
don't have source. Even if we did, the same changes might not
be as simple, given vnode vs. inode problems. In any case, a
system based purely on user code would be preferable.

I'm sure some members of the community have had similar problems.

I am very interested in ideas for a better way.

Some important design considerations:

1. The existing accounting system has a lot going for it. The kernel
writes a record for every process transparently. All the interesting
numbers for the process are already there (user time, system time, etc.).

2. Our current system (device/inode added to records) is totally
transparent to the users. They don't have to do anything to make it
work. An idea that may occur to some is to have users log into and
out of jobs. This gets a big thumbs down from our users, as they
hop around among many jobs at once.

3. The current system requires no modifications to user programs.
Our in-house programs, as well as standard utilities don't have to
know about the accounting system.

A nice extension to the system that would neatly solve my problem
would be a user definable field in the accounting record, set
by an non-privileged primitive. The job number could be set by
the parent shell after each directory change, and would be inherited
by all child processes. I bet people would think of lots of interesting
uses for such a thing. Alas, for now, I need a user code solution.

My questions to you all:
Does this situation ring any familiar bells?
Who has a better way?
Any ideas for discussion?

Many thanks for your attention.

Fred Toth
Washburn Graphics, Inc.
Charlotte, NC
decvax!mcnc!unccvax!wgivax!fpt
704-334-5371