deamon help

[John F Haugh II]

In article <2304 at inews.intel.com> bhoughto at hopi.intel.com (Blair P. Houghton) writes:
>In article <BZS.91Feb5105600 at world.std.com> bzs at world.std.com (Barry Shein) writes:
>>For a problem like this I'll bet you a nickel crafting the whole thing
>>in C using /dev/kmem etc will not be much faster than the above
>>described script, and will take a week to get right instead of 30 minutes.
>
>Better, use popen(3) and top(1).  Top usually gets the data
>much faster than ps.  Why?  Who knows?  Could be anything
>from superior skills among public-domain software developers
>to abuse of /dev/null.

Hmmm.  I'm half tempted to take that bet.  One problem I envision with
the PS approach is that the CPU resolution is to the full second, and
there are many processes which lurk about in the background and don't
use much more than a second in a days time.  Here's the PS output from
this system with those processes selected -

    UID   PID  PPID  C    STIME TTY  TIME COMMAND
   root    30     1  0  Jan 24    ?  0:00 /etc/syslogd /usr/adm/syslog 
     lp    35     1  0  Jan 24    ?  0:00 /usr/lib/lpsched 

I'd wager that it is fairly easy to write a program that would do
a considerable amount of work and never record a single CPU tick.

PER PROCESS USER AREA:
USER ID's:	uid: 0, gid: 0, real uid: 0, real gid: 0
PROCESS TIMES:	user: 6, sys: 17, child user: 0, child sys: 0
PROCESS MISC:	proc slot: 8, cntrl tty: maj(4) min(2)
IPC:		locks: unlocked
FILE I/O:	user addr: 25708343, file offset: 357, bytes: 0,
		segment: user, umask: 26, ulimit: 2097152
ACCOUNTING:	command: syslogd, memory: 931552, type: fork
		start: Thu Jan 24 19:30:02 1991
OPEN FILES:	file desc:     0   1   2   3
		file slot:     9   9   9   8

This is most of the user structure for the "syslogd" process which I
PS'd above.  It has logged 23 ticks in 13 days of running, yet it
at a minimum produces a log record once an hour.  You can't log a
fraction of a tick, so it would appear there is about a 1 in 13 chance
of the hourly timestamp logging a tick.  The implication of this is
that a process which does work (even "does work every hour") may still
log clock ticks so slowly that even after a month of furious light
activity (interesting use of the word "furious" ;-), it still has yet
to log a single full second of time.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh at rpp386.cactus.org
"I've never written a device driver, but I have written a device driver manual"
                -- Robert Hartman, IDE Corp.