xref: /freebsd/usr.sbin/rwhod/rwhod.8 (revision 3e0f6b97b257a96f7275e4442204263e44b16686)
1.\" Copyright (c) 1983, 1991, 1993
2.\"	The Regents of the University of California.  All rights reserved.
3.\"
4.\" Redistribution and use in source and binary forms, with or without
5.\" modification, are permitted provided that the following conditions
6.\" are met:
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.
19.\"
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
30.\" SUCH DAMAGE.
31.\"
32.\"     @(#)rwhod.8	8.2 (Berkeley) 12/11/93
33.\"
34.Dd December 11, 1993
35.Dt RWHOD 8
36.Os BSD 4.2
37.Sh NAME
38.Nm rwhod
39.Nd system status server
40.Sh SYNOPSIS
41.Nm rwhod
42.Op Fl m Op Ar ttl
43.Sh DESCRIPTION
44.Nm Rwhod
45is the server which maintains the database used by the
46.Xr rwho 1
47and
48.Xr ruptime 1
49programs.  Its operation is predicated on the ability to
50.Em broadcast
51or
52.Em multicast
53messages on a network.
54.Pp
55.Nm Rwhod
56operates as both a producer and consumer of status information.
57As a producer of information it periodically
58queries the state of the system and constructs
59status messages which are broadcasted or multicasted on a network.
60As a consumer of information, it listens for other
61.Nm rwhod
62servers' status messages, validating them, then recording
63them in a collection of files located in the directory
64.Pa /var/rwho .
65.Pp
66The
67.Fl m
68option causes rwhod to use IP multicast (instead of
69broadcast) on all interfaces that have
70the IFF_MULTICAST flag set in their "ifnet" structs
71(excluding the loopback interface).  The multicast
72reports are sent with a time-to-live of 1, to prevent
73forwarding beyond the directly-connected subnet(s).
74.Pp
75If the optional
76.Ar ttl
77argument is supplied with the
78.Fl m
79flag, rwhod will send IP multicast datagrams with a
80time-to-live of <ttl>, via a SINGLE interface rather
81than all interfaces.  <ttl> must be between 0 and
8232 (or MAX_MULTICAST_SCOPE).  Note that
83.Fl m Ar 1
84is different than
85.Fl m ,
86in that
87.Fl m Ar 1
88specifies transmission on one interface only.
89.Pp
90When
91.Fl m
92is used without a
93.Ar ttl
94argument, the program accepts multicast
95rwhod reports from all multicast-capable interfaces.  If a
96.Ar ttl
97argument is given, it accepts multicast reports from only one interface, the
98one on which reports are sent (which may be controlled via the host's routing
99table).  Regardless of the "-m" option, the program accepts broadcast or
100unicast reports from all interfaces.  Thus, this program will hear the
101reports of old, non-multicasting rwhods, but, if multicasting is used,
102those old rwhods won't hear the reports generated by this program.
103.Pp
104The server transmits and receives messages at the port indicated
105in the ``rwho'' service specification; see
106.Xr services 5 .
107The messages sent and received, are of the form:
108.Bd -literal -offset indent
109struct	outmp {
110	char	out_line[8];		/* tty name */
111	char	out_name[8];		/* user id */
112	long	out_time;		/* time on */
113};
114
115struct	whod {
116	char	wd_vers;
117	char	wd_type;
118	char	wd_fill[2];
119	int	wd_sendtime;
120	int	wd_recvtime;
121	char	wd_hostname[32];
122	int	wd_loadav[3];
123	int	wd_boottime;
124	struct	whoent {
125		struct	outmp we_utmp;
126		int	we_idle;
127	} wd_we[1024 / sizeof (struct whoent)];
128};
129.Ed
130.Pp
131All fields are converted to network byte order prior to
132transmission.  The load averages are as calculated by the
133.Xr w 1
134program, and represent load averages over the 5, 10, and 15 minute
135intervals prior to a server's transmission; they are multiplied by 100
136for representation in an integer.  The host name
137included is that returned by the
138.Xr gethostname 3
139system call, with any trailing domain name omitted.
140The array at the end of the message contains information about
141the users logged in to the sending machine.  This information
142includes the contents of the
143.Xr utmp 5
144entry for each non-idle terminal line and a value indicating the
145time in seconds since a character was last received on the terminal line.
146.Pp
147Messages received by the
148.Nm rwho
149server are discarded unless they originated at an
150.Nm rwho
151server's port.  In addition, if the host's name, as specified
152in the message, contains any unprintable
153.Tn ASCII
154characters, the
155message is discarded.  Valid messages received by
156.Nm rwhod
157are placed in files named
158.Pa whod.hostname
159in the directory
160.Pa /var/rwho .
161These files contain only the most recent message, in the
162format described above.
163.Pp
164Status messages are generated approximately once every
1653 minutes.
166.Nm Rwhod
167performs an
168.Xr nlist 3
169on
170.Pa /kernel
171every 30 minutes to guard against
172the possibility that this file is not the system
173image currently operating.
174.Sh SEE ALSO
175.Xr ruptime 1 ,
176.Xr rwho 1
177.Sh BUGS
178Status information should be sent only upon request rather than continuously.
179People often interpret the server dying
180or network communication failures
181as a machine going down.
182.Sh HISTORY
183The
184.Nm
185command appeared in
186.Bx 4.2 .
187