Unique process id (not pid) and accounting daemon

[Alfred Perlstein]

* cronfy <cronfy at gmail.com> [100124 15:59] wrote:
> Hello.
> 
> Sorry for the crosspost, I intended to post this to freebsd-hackers@, but
> sent first copy to freebsd-questions@ by mistake.
> 
> 
> I am trying to create an accounting daemon that would be more precise
> than usual BSD system accounting. It should read the whole process
> tree from time to time (say, every 10 seconds) and log changes in
> usage of CPU, I/O operations and memory per process. After daemon
> notices process exit, it should read /var/account/acct to get a last
> portion of accounting data and make a last entry for the process. Also
> daemon should read /var/account/acct to find information about
> processes that had been running between taking process tree snapshots.
> 
> There is a problem: it is not always possible to link a process in a
> process tree against matching process in an accounting file. Only
> command name, user/group id  and start time will match, but:
> 
>  * start time may change (i. e. after ntpdate);
>  * command name saved in /var/account/acct is 15 characters max
> (AC_COMM_LEN in sys/sys/acct.h), while command name in the process
> tree is 19 characters max (MAXCOMLEN in sys/sys/param.h).
> 
> To ensure that process in the process tree and process in the
> accounting file are the same, I want to add unique process identifier
> (uint64_t) to 'proc' struct in sys/sys/proc.h and increment it for
> every process fork. I see it is possible to do this just before
> sx_sunlock() in fork1() in sys/kern/kern_fork.c. I'll have to add
> saving of this identifier in kern_acct.c, of course.
> 
> This way I will be extremely easy to remember a process in the process
> tree and find a matching one in the accounting file after it finishes.
> 
> Am I looking in a right direction or should I try some other way?
> Thanks in advance.

I've thought of this a few times, specifically how to ensure
not sending a signal to a process by accident, specifically adding
a version of kill(2) that took process start time.

It's interesting that you bring up that start time can change, I 
did not know this.

Now that I know this, I would suggest simply recording the start
time as the serial number, then using pid+recorded_start_time as
your serial number.

Just an idea.

-- 
- Alfred Perlstein
.- AMA, VMOA #5191, 03 vmax, 92 gs500, 85 ch250
.- FreeBSD committer