Find enclosed the procstatd sources:
   README (this file)
   README.watchman
   README.GPL (the slightly modified GPL)
   Makefile
   procstatd.h
   procstatd.c
   procstats.c
   parsecl.c
   parse.c
   watchman

README.watchman: Read carefully to see what perl/tk resources are required
by watchman.

README.GPL:  Note well the "Beverage" modification to the standard GPL.
I think you'll find it amusing and some of you may well adopt it for
your own GPL source trees.

Makefile:  Very simple; this isn't a complicated program.

procstatd.h:  All the includes and declarations required that need to be
shared between program components.

procstatd.c:  The main source module, including the socket code.

procstats.c:  Reads the /proc stuff and builds statistics.  The
statistics generated are basically those used by procstat, although I've
pretty much completely rewritten the parsing code to add features and
make it extensible.

parsecl.c:  A command line parser.  I use several of these.  Probably
not necessary, but it makes it easy for me to drop in options without
worrying about getopt conformance.

parse.c:  A generic line parser.  Breaks line into tokens for
postprocessing.  This makes writing procstats.c MUCH simpler.  If the
daemon were written in perl, of course, this wouldn't be necessary.  On
the other hand, the code would be ten times slower and more expensive
and one would have to have perl installed...

watchman: A Tkperl monitor program that lets you monitor and to some
extent control a LAN, a parallel cluster, or a dedicated beowulf.  It
talks to procstatd to obtain per-node statistics with some
user-selectable update granularity.  It has lots of buttons and features
that are constantly changing, but like all GUI-driven applications it is
pretty much self-documenting.  That is, crank it up and try it out;
you'll see quickly what it does and whether it is useful to you.

The program basically works like the following:

You build it.  You can build it as root or as yourself, it won't really
matter.  Let's assume that you build it as root.  

You install it, changing the destination in the Makefile to reflect your
system.  I'm assuming installation in /usr/local, but if I ever build an
RPM for this it will probably get installed in /usr instead.

You arrange for it to run at boot time.  This can be done by adding the
following fragment (suitably modified for install path) to e.g.
/etc/rc.d/rc.local:

if [ -x /usr/local/sbin/procstatd ]
then
   /usr/local/sbin/procstatd [time granularity]
fi

or by building an /etc/rc.d/initd/procstatd to start/stop/restart the
daemon and running one of the Red Hat utilities (e.g. tksysv) to build
symlinks to start/stop it at the appropriate runlevels at boot time.
Because of limitations in the update cycle of e.g. sensor information in
/proc, it is recommended that the time granularity be kept greater than
or equal to five seconds.  The program will permit time granularity to
be set as low as one second, though.  At this time, I don't plan to make
the time granularity resettable on the fly, but this might change in the
future if there is any real need.

Reboot (or start the daemon by hand), and you're done!  procstatd will
then dutifully sleep, come awake just long enough to collect information
and build statistics from /proc (and elsewhere, actually), and then spit
them out in a single broadcast packet.  This packet can be collected and
parsed by a variety of clients.

The program is deliberately constructed to be "lightweight" (to avoid
loading either network or node CPU).  It is therefore somewhat
minimalist: it doesn't provide any information about running processes,
for example.  In the future the program will probably be modified to
return the name/pid/runtime/cpuavg/memory of the actual running
processes (basically the information returned by ps auxrww less the
daemon itself) but it will probably approximately double both node
burden and network burden and require that I "borrow" a bunch of code
from procps, so for the moment I'm leaving it out.

In a separate project, a tkperl monitor GUI ("watchman") is being
developed that can passively monitor and display the collective results
from the node/client broadcasts.  However, the procstatd itself
basically constitutes a node/client monitoring API and I encourage the
development of both procstatd extensions (the API format should be
obvious) and additional user or system interfaces to be developed that
use the API. For example, a beoproc kernel module could easily be
written to collect the node/client broadcast results and put them into
the /proc structure on the master system of a beowulf (or the master
host of a LAN being monitored).

The procstatd code itself is also not quite as modular as I'd like it to
be.  It would really be desirable, for example, for it to be possible to
develop a "plug-in" monitoring component and simply link it into the
existing procstatd shell to add a statistic to the broadcast packet.
Since I'm forced to do a major rewrite of the daemon by three things:

   a) I dropped three weeks of key procstatd source changes when I
converted to Red Hat (the damn zip disk got full and I didn't notice!).
I'm way too old to make stupid mistakes like this.  Makes me feel young
again.

   b) Don Becker's remark that the daemon should broadcast the results.
I'd written an inetd or standalone connection oriented version of the
daemon.  Connectionless is so overwhelmingly obviously better (more
secure, less network traffic if there are multiple monitors, etc.) that
I'm amazed I didn't think of it myself.  Of course, I DID want the
daemon to be useable across WANs (for a monitor on one site to be able
to "watch" a second site) but this can either be handled by making the
daemon have a connection option or by adding a connection service to a
monitor daemon running within the broadcast domain.

   c) A whole discussion on the beowulf list on procd's and their ilk in
general.  It is clear that the project is timely, and several people's
remarks (Jacek Radajewski's, for example) made remarks or suggestions
that would have necessitated a rewrite anyway.

...I may (remember, the three items are embedded in a rather long sentence
made longer still by this silly parenthetical inclusion -- see the
"Since..." fifteen or twenty lines above:-) try to make the code
somewhat "object" structured with each statistic group represented by
its own code module.  You can follow the evolution of this process as
far as it gets by looking at the CVS source tree, since I'm restarting
CVS from my last procd revision plus a bit of reorganization right NOW.
