1 .\" Copyright (c) 1983, 1991, 1993
2 .\" The Regents of the University of California. All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\" notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\" notice, this list of conditions and the following disclaimer in the
11 .\" documentation and/or other materials provided with the distribution.
12 .\" 3. All advertising materials mentioning features or use of this software
13 .\" must display the following acknowledgement:
14 .\" This product includes software developed by the University of
15 .\" California, Berkeley and its contributors.
16 .\" 4. Neither the name of the University nor the names of its contributors
17 .\" may be used to endorse or promote products derived from this software
18 .\" without specific prior written permission.
20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
32 .\" @(#)rwhod.8 8.2 (Berkeley) 12/11/93
39 .Nd system status server
44 is the server which maintains the database used by the
48 programs. Its operation is predicated on the ability to
50 messages on a network.
53 operates as both a producer and consumer of status information.
54 As a producer of information it periodically
55 queries the state of the system and constructs
56 status messages which are broadcast on a network.
57 As a consumer of information, it listens for other
59 servers' status messages, validating them, then recording
60 them in a collection of files located in the directory
63 The server transmits and receives messages at the port indicated
64 in the ``rwho'' service specification; see
66 The messages sent and received, are of the form:
67 .Bd -literal -offset indent
69 char out_line[8]; /* tty name */
70 char out_name[8]; /* user id */
71 long out_time; /* time on */
86 } wd_we[1024 / sizeof (struct whoent)];
90 All fields are converted to network byte order prior to
91 transmission. The load averages are as calculated by the
93 program, and represent load averages over the 5, 10, and 15 minute
94 intervals prior to a server's transmission; they are multiplied by 100
95 for representation in an integer. The host name
96 included is that returned by the
98 system call, with any trailing domain name omitted.
99 The array at the end of the message contains information about
100 the users logged in to the sending machine. This information
101 includes the contents of the
103 entry for each non-idle terminal line and a value indicating the
104 time in seconds since a character was last received on the terminal line.
106 Messages received by the
108 server are discarded unless they originated at an
110 server's port. In addition, if the host's name, as specified
111 in the message, contains any unprintable
114 message is discarded. Valid messages received by
116 are placed in files named
120 These files contain only the most recent message, in the
121 format described above.
123 Status messages are generated approximately once every
130 every 30 minutes to guard against
131 the possibility that this file is not the system
132 image currently operating.
137 There should be a way to relay status information between networks.
138 Status information should be sent only upon request rather than continuously.
139 People often interpret the server dying
140 or network communication failures
141 as a machine going down.