The Remote Uptime (RU)
I started using Unix systems
in approximately 1984 at Colorado State University. At
time, Unix was BSD or SysV. TCP/IP was new as was networking
computers in general. Needless to say, I found Unix to be really
cool. Just to date myself, in 1984, the Big Computer on
Campus was a CDC Cyber, and the primary computer that ran the Computer
Science Departement was a Digital VAX 11/750 (not even a 780!).
The computing facilities were HP 9000/300 series workstations/servers
with a blazing 16Mhz
68020 CPU and 8 megabytes of memory and HP/IB storage. Needless
to say, these weren't powerful machines.
When assignments were due, the systems got horribly
busy. The computing system assigned to a paticular class (if only
one) got so slow that it literally was seconds between typing a
seeing it on the screen. Due to this, the idea of using an idle
system from another class became attractive. I would find a
non-busy system, do my editing there, and rcp/rlogin to the primary
host, do my compiles and go back to editing.
As part of this, I found the 'ruptime'
command. It was very handy for figuring out what systems were on
the network and how busy those systems were.
After I left college, I eventually became a Systems
Administrator (SysAdmin). I liked the 'ruptime' functionality for
watching the systems in my environment. However, as soon as I
turned on the ruptime function, I found that the program had a few
Due to the problems above, I ended up turning off
rwhod on all of the clients. However, I still wanted
something similar so that I could quickly see system status.
- The 'rwhod' daemon that collected the information used
broadcasts, which meant that it didn't work across subnets.
client must run rwhod to show up in the 'ruptime' list. This
means that every so often (5 seconds?) each client sent a broadcast
declaring it's current status. This caused a HUGE number of
broadcasts for any network larger than 10-15 clients.
- rwhod stores the information for each client locally. That
that each client has its own list of rwho status. This
a large amount of wasted storage, as I was the only one looking at the
data, and I was looking from a single workstation.
- maintaining the rwho daemon and storage was a time-waster.
It took time to keep it going.
RU is Born
Around this time, I asked a co-worker
of mine, Dave Farnham, whether he had a way to implement
similar to ruptime, but without the nasty edges. Dave spent a
weekend (he's a wiz) and came up with an RPC based system that operated
in a client-server mode. By using RPC, the solution was very
portable, and easily ported to pretty much everywhere. The
initial version reported only system uptime by using a RPC call from
the client to a centralized server that ran a collection daemon written
in Perl. This initial version appeared in the 1994-1995 timeframe.
Over the next year or two, Dave added history
reporting, system load graphing, and availability reporting.
Around this time, Dave decided to leave the company, and went on to
position at another company.
I then took over the maintenance of the ru
source. Over time, I've added a number of features until I
consider it to be a mature, easy to use system status reporting
I find it very handy to simply type 'ru'
periodically to see what is going on in the environment. ru is
very useful for detecting 'just not right' server problems, such as
runaway jobs, high loads, etc.
What is RU?
In the above picture the program 'ru' has been
executed against a larger environment of servers. Immediately,
you can see the system name, the system uptime, the load average, and
the number of logged in users. In addition, the coloring of the
text shows a number of additional items. The server 'handies1'
has been booted only 14 minutes ago. It is shown in yellow to
attract attention that the server has booted in the last 24
Server 'jaguar' has a * in front of it, which
indicates that the system hasn't reported in two minutes. This
actually indicates that the clock on jaguar is out of sync with the
master server, and that the system in question is really more than two
minutes different than the host system. If you deploy ru, you
need to synronize your system clocks with NTP (or something
similar). It's a good idea to synchronize your clocks for
security purposes anyway.
Below represents many (but not all) of the features
of the ru system:
- Clients run a daemon called 'rucd' (ru client daemon). This
client sends a single RPC packet to the central server 'ruserver' once
per minute reporting:
- System Uptime
- Number of users of the system
- Load average of the system
- On Linux only, system paging and cpu %
central server 'ruserver' runs 3 daemons:
- collects the client reports
- processes client requests for information
- ru client daemon (for the server to report its own status)
central sever runs a nightly cron job to clean up the daily infomation
and to build the availability reports.
the central system, a program called 'avail' can be run to document
perl program 'ru' can be run from anywhere with network reachability to
the server to report on the data collected by ru.
system runs itself. It needs no interaction, and cleans up after
system will use gnuplot (if installed) to plot system(s) load average
over a 24 hour period. This is handy for comparing loading information
over time. This works by default if run on a Linux system with
system has groups to allow segmentation of the clients into:
(implict segementation in italic)
- Operating system
group (firewall, production, lab, etc.)
system runs on every Unix I've found with minimal changes.
The following are known to work:
10 and 11
Detailed instructions are found in the download
tarball. However, the below represents a simple overview of the
Note that the current solution is focused towards a
particular production environment. It should be easily possible
to redefine flags any way desired with the use of a text editor.
- Install the server daemons and create the data directories.
- Add startup scripts to the server.
- Start the services.
- Add a dns alias to your server of 'ruserver'.
- Add a single line to the inittab of each client to start the rucd
- Start the client via a 'init q'.
If you should have questions, see the forums, or
contact me at shaw at fmsoft
like to change a few things about how ru works to make it truly
- Change the server configuration to look up the client group
automatically so that changing the client group can be centralized.
- Switch from RPC to a dedicated socket via Perl (major rewrite).
Thanks to SourceForge.net for hosting this