inetd.conf(4)inetd.conf(4)NAMEinetd.conf - configuration file for inetd
DESCRIPTION
On invocation, the daemon reads its configuration information from the
configuration file, and possibly at some later time in response to a
signal (see inetd(1M)).
Each line in the file is treated either as a comment or as configura‐
tion information for a given service Comments are denoted by a at the
beginning of a line. Noncomment lines contain seven or nine required
fields, depending on the service name specified in the first field.
Fields are separated by tabs and/or spaces. A line can be continued if
it terminates with a Each configuration line in the file contains the
following fields in the order indicated:
· service name
· socket type
· protocol
·
· user
· server program
· program number (NFS RPC services only)
· version number (NFS RPC services only)
· server program arguments
Fields are constructed as follows:
service name if the server is RPC-based (NFS); otherwise,
the name of a valid service in file For
example, for the service (see remsh(1)), for
the service (see rlogin(1)), and for the
service (see telnet(1)).
socket type or depending on whether the server socket is
a stream or a datagram socket, or intended
for a program built using the XTI API.
protocol Must be a valid protocol as given in for
example, or For an XTI service, the protocol
field is treated as:
· A network_ID for an RPC service, (see
netconfig(4)).
· A device name in the directory for a non-
RPC service. For example, if is speci‐
fied, the path will be used.
For IPv6 applications the protocol is speci‐
fied as either or
Specifies whether should act as a single- or multi-threaded
server.
Instructs to start one server to handle an
incoming request, and cease lis‐
tening for new requests for the
same service until the server that
started has exited.
Same as but instructs to expect the server
to accept the incoming request.
Instructs to start one server for each
incoming request.
Most UDP-based services use for this field,
while TCP-based services use
user User ID to be used when the server is run‐
ning.
server program Absolute path name of the program executed
by when it finds a request on the server's
socket.
server program arguments
Arguments to the server program. The same
as in normal use, starting with which is the
name of the program.
If service name is (NFS RPC services), two extra fields are required.
They must appear between the server program field and the server pro‐
gram arguments field:
program number Defines a particular service grouping and is
unique.
version number Version supported by the RPC service. This
number can be a single value, or a range, if
the program handles multiple versions; for
example, or Ranges are separated by a hyphen
Version numbers allow RPC protocols to be
extended and modified, and make it possible
for old and new protocols to share the same
server process.
Built-in inetd Services
The daemon provides several "trivial" services internally by use of
built-in routines (see inetd(1M) for a list of these services). To
configure an internal service, specify as the server program name, and
omit the server program arguments field.
EXAMPLES
Configure the service to use TCP protocol, and run the server as user
The above is an example of the remsh utility run in the IPv4 mode. To
run the above utility in the IPv6 mode, the protocol must be changed to
Thus the above configuration is re-written as below to run in mode.
Configure the FTP server to timeout an inactive session after 75 sec‐
onds.
The above ftp service can be run in IPv6 mode using the configuration
shown below:
Configure an RPC-based service. Note that the service name field con‐
tains and two more fields are used: the program number (100008) and
version number (1).
Configure to use the built-in TCP service.
AUTHOR
was developed by the University of California, Berkeley.
NFS was developed by Sun Microsystems, Inc.
SEE ALSOinetd(1M), exec(2), fork(2), inetd.sec(4), protocols(4), services(4).
inetd.conf(4)
