xref: /freebsd/usr.sbin/rwhod/rwhod.8 (revision a8445737e740901f5f2c8d24c12ef7fc8b00134e)
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
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
69.Nm
70to use IP multicast (instead of
71broadcast) on all interfaces that have
72the IFF_MULTICAST flag set in their "ifnet" structs
73(excluding the loopback interface).  The multicast
74reports are sent with a time-to-live of 1, to prevent
75forwarding beyond the directly-connected subnet(s).
76.Pp
77If the optional
78.Ar ttl
79argument is supplied with the
80.Fl m
81flag,
82.Nm
83will send IP multicast datagrams with a
84time-to-live of
85.Ar ttl ,
86via a SINGLE interface rather
87than all interfaces.
88.Ar ttl
89must be between 0 and
9032 (or MAX_MULTICAST_SCOPE).  Note that
91.Fl m Ar 1
92is different than
93.Fl m ,
94in that
95.Fl m Ar 1
96specifies transmission on one interface only.
97.Pp
98When
99.Fl m
100is used without a
101.Ar ttl
102argument, the program accepts multicast
103.Nm
104reports from all multicast-capable interfaces.  If a
105.Ar ttl
106argument is given, it accepts multicast reports from only one interface, the
107one on which reports are sent (which may be controlled via the host's routing
108table).  Regardless of the
109.Fl m
110option, the program accepts broadcast or
111unicast reports from all interfaces.  Thus, this program will hear the
112reports of old, non-multicasting
113.Nm rwhod Ns s ,
114but, if multicasting is used,
115those old
116.Nm rwhod Ns s
117won't hear the reports generated by this program.
118.Pp
119The server transmits and receives messages at the port indicated
120in the ``who'' service specification; see
121.Xr services 5 .
122The messages sent and received, are of the form:
123.Bd -literal -offset indent
124struct	outmp {
125	char	out_line[8];		/* tty name */
126	char	out_name[8];		/* user id */
127	long	out_time;		/* time on */
128};
129
130struct	whod {
131	char	wd_vers;
132	char	wd_type;
133	char	wd_fill[2];
134	int	wd_sendtime;
135	int	wd_recvtime;
136	char	wd_hostname[32];
137	int	wd_loadav[3];
138	int	wd_boottime;
139	struct	whoent {
140		struct	outmp we_utmp;
141		int	we_idle;
142	} wd_we[1024 / sizeof (struct whoent)];
143};
144.Ed
145.Pp
146All fields are converted to network byte order prior to
147transmission.  The load averages are as calculated by the
148.Xr w 1
149program, and represent load averages over the 5, 10, and 15 minute
150intervals prior to a server's transmission; they are multiplied by 100
151for representation in an integer.  The host name
152included is that returned by the
153.Xr gethostname 3
154system call, with any trailing domain name omitted.
155The array at the end of the message contains information about
156the users logged in to the sending machine.  This information
157includes the contents of the
158.Xr utmp 5
159entry for each non-idle terminal line and a value indicating the
160time in seconds since a character was last received on the terminal line.
161.Pp
162Messages received by the
163.Nm rwho
164server are discarded unless they originated at an
165.Nm rwho
166server's port.  In addition, if the host's name, as specified
167in the message, contains any unprintable
168.Tn ASCII
169characters, the
170message is discarded.  Valid messages received by
171.Nm
172are placed in files named
173.Pa whod.hostname
174in the directory
175.Pa /var/rwho .
176These files contain only the most recent message, in the
177format described above.
178.Pp
179Status messages are generated approximately once every
1803 minutes.
181.Nm Rwhod
182performs an
183.Xr nlist 3
184on
185.Pa /kernel
186every 30 minutes to guard against
187the possibility that this file is not the system
188image currently operating.
189.Sh SEE ALSO
190.Xr ruptime 1 ,
191.Xr rwho 1
192.Sh BUGS
193Status information should be sent only upon request rather than continuously.
194People often interpret the server dying
195or network communication failures
196as a machine going down.
197.Sh HISTORY
198The
199.Nm
200command appeared in
201.Bx 4.2 .
202