1 .\" Copyright (c) 1985, 1991, 1993, 1994
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 .\" @(#)inetd.8 8.4 (Berkeley) 6/1/94
45 .Op Ar configuration file
50 should be run at boot time by
54 It then listens for connections on certain
55 internet sockets. When a connection is found on one
56 of its sockets, it decides what service the socket
57 corresponds to, and invokes a program to service the request.
58 The server program is invoked with the service socket
59 as its standard input, output and error descriptors.
63 continues to listen on the socket (except in some cases which
64 will be described below). Essentially,
66 allows running one daemon to invoke several others,
67 reducing load on the system.
69 The options available for
75 Specifies the maximum number of times a service can be invoked
76 in one minute; the default is 1000.
81 reads its configuration information from a configuration
82 file which, by default, is
84 There must be an entry for each field of the configuration
85 file, with entries for each field separated by a tab or
86 a space. Comments are denoted by a ``#'' at the beginning
87 of a line. There must be an entry for each field. The
88 fields of the configuration file are as follows:
90 .Bd -unfilled -offset indent -compact
97 server program arguments
100 There are two types of services that
102 can start: standard and TCPMUX.
103 A standard service has a well-known port assigned to it;
104 it may be a service that implements an official Internet standard or is a
105 BSD-specific service.
108 TCPMUX services are nonstandard services that do not have a
109 well-known port assigned to them.
110 They are invoked from
112 when a program connects to the
114 well-known port and specifies
116 This feature is useful for adding locally-developed servers.
120 entry is the name of a valid service in
125 services (discussed below), the service
128 be the official name of the service (that is, the first entry in
129 .Pa /etc/services ) .
130 For TCPMUX services, the value of the
132 field consists of the string
134 followed by a slash and the
135 locally-chosen service name.
136 The service names listed in
141 Try to choose unique names for your TCPMUX services by prefixing them with
142 your organization's name and suffixing them with a version number.
153 depending on whether the socket is a stream, datagram, raw,
154 reliably delivered message, or sequenced packet socket.
155 TCPMUX services must use
160 must be a valid protocol as given in
166 TCPMUX services must use
171 entry specifies whether the server that is invoked by inetd will take over
172 the socket associated with the service access point, and thus whether
174 should wait for the server to exit before listening for new service
176 Datagram servers must use
178 as they are always invoked with the original datagram socket bound
179 to the specified service address.
180 These servers must read at least one datagram from the socket
182 If a datagram server connects
183 to its peer, freeing the socket so
185 can received further messages on the socket, it is said to be
189 it should read one datagram from the socket and create a new socket
190 connected to the peer.
191 It should fork, and the parent should then exit
194 to check for new service requests to spawn new servers.
195 Datagram servers which process all incoming datagrams
196 on a socket and eventually time out are said to be
197 .Dq single-threaded .
202 are both examples of the latter type of
205 is an example of a multi-threaded datagram server.
207 Servers using stream sockets generally are multi-threaded and
211 Connection requests for these services are accepted by
213 and the server is given only the newly-accepted socket connected
214 to a client of the service.
215 Most stream-based services operate in this manner.
216 Stream-based servers that use
218 are started with the listening service socket, and must accept
219 at least one connection request before exiting.
220 Such a server would normally accept and process incoming connection
221 requests until a timeout.
222 TCPMUX services must use
227 entry should contain the user name of the user as whom the server
228 should run. This allows for servers to be given less permission
233 entry should contain the pathname of the program which is to be
236 when a request is found on its socket. If
238 provides this service internally, this entry should
243 .Em server program arguments
244 should be just as arguments
245 normally are, starting with argv[0], which is the name of
246 the program. If the service is provided internally, the
249 should take the place of this entry.
256 services internally by use of
257 routines within itself. These services are
261 (character generator),
263 (human readable time), and
265 (machine readable time,
266 in the form of the number of seconds since midnight, January
267 1, 1900). All of these services are tcp based. For
268 details of these services, consult the appropriate
270 from the Network Information Center.
275 rereads its configuration file when it receives a hangup signal,
277 Services may be added, deleted or modified when the configuration file
279 Except when started in debugging mode,
281 records its process ID in the file
282 .Pa /var/run/inetd.pid
283 to assist in reconfiguration.
287 describes the TCPMUX protocol:
288 ``A TCP client connects to a foreign host on TCP port 1. It sends the
289 service name followed by a carriage-return line-feed <CRLF>. The
290 service name is never case sensitive. The server replies with a
291 single character indicating positive (+) or negative (\-)
292 acknowledgment, immediately followed by an optional message of
293 explanation, terminated with a <CRLF>. If the reply was positive,
294 the selected protocol begins; otherwise the connection is closed.''
295 The program is passed the TCP connection as file descriptors 0 and 1.
297 If the TCPMUX service name begins with a ``+'',
299 returns the positive reply for the program.
300 This allows you to invoke programs that use stdin/stdout
301 without putting any special server code in them.
303 The special service name
307 to list TCPMUX services in
312 Here are several example service entries for the various types of services:
314 ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l
315 ntalk dgram udp wait root /usr/libexec/ntalkd ntalkd
316 tcpmux/+date stream tcp nowait guest /bin/date date
317 tcpmux/phonebook stream tcp nowait guest /usr/local/bin/phonebook phonebook
323 logs error messages using
325 Important error messages and their explanations are:
327 \fIservice\fP/\fIprotocol\fP server failing (looping), service terminated.
329 The number of requests for the specified service in the past minute
330 exceeded the limit. The limit exists to prevent a broken program
331 or a malicious user from swamping the system.
332 This message may occur for several reasons:
333 1) there are lots of hosts requesting the service within a short time period,
334 2) a 'broken' client program is requesting the service too frequently,
335 3) a malicious user is running a program to invoke the service in
336 a 'denial of service' attack, or
337 4) the invoked service program has an error that causes clients
342 as described above, to change the rate limit.
343 Once the limit is reached, the service will be
344 reenabled automatically in 10 minutes.
347 \fIservice\fP/\fIprotocol\fP: No such user '\fIuser\fP', service ignored
348 \fIservice\fP/\fIprotocol\fP: getpwnam: \fIuser\fP: No such user
354 file. The first message
357 (re)reads the configuration file. The second message occurs when the
361 \fIservice\fP: can't set uid \fInumber\fP
362 \fIservice\fP: can't set gid \fInumber\fP
364 The user or group ID for the entry's
381 TCPMUX is based on code and documentation by Mark Lottor.