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
33 .\" $FreeBSD: src/usr.sbin/rwhod/rwhod.8,v 1.13.2.4 2003/03/11 22:31:33 trhodes Exp $
34 .\" $DragonFly: src/usr.sbin/rwhod/rwhod.8,v 1.6 2006/02/17 19:40:26 swildner Exp $
41 .Nd system status server
52 utility is the server which maintains the database used by the
56 programs. Its operation is predicated on the ability to
60 messages on a network.
64 utility operates as both a producer and consumer of status information,
67 (listen mode) option is specified, in which case
68 it acts as a consumer only.
69 As a producer of information it periodically
70 queries the state of the system and constructs
71 status messages which are broadcasted or multicasted on a network.
72 As a consumer of information, it listens for other
74 servers' status messages, validating them, then recording
75 them in a collection of files located in the directory
80 option enables insecure mode, which causes
82 to ignore the source port on incoming packets.
86 option allows for the broadcast
90 to be reduced below 3 minutes. This enables for more 'real' time statistics
94 operand can be given as 30 (30 seconds) or 1m (1 minute), for example.
102 interfaces. This is useful if you do not wish to keep dial on demand
103 interfaces permanently active.
107 option enables listen mode, which causes
109 to not broadcast any information.
110 This allows you to monitor other machines'
112 information, without broadcasting your own.
118 to use IP multicast (instead of
119 broadcast) on all interfaces that have
120 the IFF_MULTICAST flag set in their "ifnet" structs
121 (excluding the loopback interface). The multicast
122 reports are sent with a time-to-live of 1, to prevent
123 forwarding beyond the directly-connected subnet(s).
127 argument is supplied with the
131 will send IP multicast datagrams with a
134 via a SINGLE interface rather
137 must be between 0 and
138 32 (or MAX_MULTICAST_SCOPE). Note that
144 specifies transmission on one interface only.
150 argument, the program accepts multicast
152 reports from all multicast-capable interfaces. If a
154 argument is given, it accepts multicast reports from only one interface, the
155 one on which reports are sent (which may be controlled via the host's routing
156 table). Regardless of the
158 option, the program accepts broadcast or
159 unicast reports from all interfaces. Thus, this program will hear the
160 reports of old, non-multicasting
162 but, if multicasting is used,
165 won't hear the reports generated by this program.
167 The server transmits and receives messages at the port indicated
168 in the ``who'' service specification; see
170 The messages sent and received, are of the form:
171 .Bd -literal -offset indent
173 char out_line[8]; /* tty name */
174 char out_name[8]; /* user id */
175 long out_time; /* time on */
184 char wd_hostname[32];
188 struct outmp we_utmp;
190 } wd_we[1024 / sizeof (struct whoent)];
194 All fields are converted to network byte order prior to
195 transmission. The load averages are as calculated by the
197 program, and represent load averages over the 5, 10, and 15 minute
198 intervals prior to a server's transmission; they are multiplied by 100
199 for representation in an integer. The host name
200 included is that returned by the
202 system call, with any trailing domain name omitted.
203 The array at the end of the message contains information about
204 the users logged in to the sending machine. This information
205 includes the contents of the
207 entry for each non-idle terminal line and a value indicating the
208 time in seconds since a character was last received on the terminal line.
210 Messages received by the
212 server are discarded unless they originated at an
216 option was specified. In addition, if the host's name, as specified
217 in the message, contains any unprintable
220 message is discarded. Valid messages received by
222 are placed in files named
226 These files contain only the most recent message, in the
227 format described above.
229 Status messages are generated by default approximately once every
236 every 30 minutes to guard against
237 the possibility that this file is not the system
238 image currently operating.
248 Status information should be sent only upon request rather than continuously.
249 People often interpret the server dying
250 or network communication failures
251 as a machine going down.