INETD(1M) INETD(1M)
inetd - Internet ``super-server''
/usr/etc/inetd [ -R rate ] [ -d ] [ -l qlen ] [ -s ]
[ configuration-file ]
When inetd is started at boot time by /etc/init.d/network, it reads its
configuration information from the /etc/inetd.conf and listens for
connections on certain internet sockets. When a connection is found on
one of its sockets, it decides what service the socket corresponds to,
and invokes a program to service the request. After the program is
finished, it continues to listen on the socket (except in some cases
which will be described below). Essentially, inetd allows running one
daemon to invoke several others, reducing load on the system.
-R This option controls the maximum number of times a service can be
invoked in one minute; the default is 1000.
-d This option turns on debugging information. Note that this can
confuse some applications; use this cautiously.
-f This option is no longer supported and will simply cause a warning
message to be included in the syslog if used.
-l This option changes the listen queue length used for TCP sockets.
By default this value is 255.
-s Causes inetd to just parse the configuration file (default is
/etc/inetd.conf) and report any errors. Do not need superuser
privileges to run inetd using this option.
To specify a different configuration file, put its pathname in the file
/etc/config/inetd.options.
Each line of the configuration file must be a valid service or a comment.
Comments are denoted by a ``#'' at the beginning of a line. Each field
in a line must be specified, with values for each field separated by a
tab or a space. The fields are as follows:
service name
socket type
protocol
wait/nowait
user
server program
server program arguments
Page 1
INETD(1M) INETD(1M)
There are three types of services that inetd can start: standard, RPC and
TCPMUX. A standard service has a well-known port assigned to it and is
listed in /etc/services or the NIS services map (see services(4)); it may
be a service that implements an official Internet standard or is a BSD
Unix-specific service. RPC services use the Sun RPC calls as the
transport; such services are listed in /etc/rpc or the NIS rpc map (see
rpc(4)). TCPMUX services are nonstandard services that do not have a
well-known port assigned to them. They are invoked from inetd when a
program connects to the ``tcpmux'' well-known port and specifies the
service name. This feature is useful for adding locally-developed
servers.
For standard Internet services, the service name field is the name of a
valid service in the services(4) database. For ``internal'' services
(discussed below), the service name must be the official name of the
service (that is, the first field in /etc/services). For RPC services,
the value of the service name field consists of the RPC service name,
followed by a slash and either a version number or a range of version
numbers (e.g., mountd/1). For TCPMUX services, the value of the service
name field consists of the string ``tcpmux'' followed by a slash and the
locally-chosen service name. If the service name begins with a ``+'', it
indicates inetd will handle the initial handshake with the requesting
program, otherwise the service is responsible for the handshake. (The
handshake is described in the inetd section in the IRIX Network
Programming Guide.) The service names listed in /etc/services and the
name ``help'' are reserved. The ``help'' name causes inetd to list
available TCPMUX services. Private protocols should use a service name
that has a high chance of being unique. A good practice is to prefix the
service name with the name of your organization. Multiple versions of a
protocol can suffix the service name with a protocol version number.
The socket type should be one of ``stream'', ``dgram'', or ``raw'',
depending on whether the socket is a stream, datagram, or raw socket.
TCPMUX services must use ``stream.''
The protocol must be a valid protocol as given in /etc/protocols (see
protocols(4)). Examples might be ``tcp'' or ``udp''. For RPC services,
the field consists of the string ``rpc'' followed by a slash and the name
of the protocol (e.g., rpc/tcp or rpc/udp for an RPC service using the
TCP or UDP protocol as a transport mechanism. If 2 RPC services use the
same server program with different protocol such as tcp or udp, the 2
services need to be based on protocol lexicographic order). TCPMUX
services must use ``tcp.''
The wait/nowait entry specifies whether the server that is invoked by
inetd will take over the socket associated with the service access point,
and thus whether inetd should wait for the server to exit before
listening for new service requests. Datagram servers must use wait, as
they are always invoked with the original datagram socket bound to the
specified service address. These servers must read at least one datagram
from the socket before exiting. If a datagram server connects to its
peer, freeing the socket so inetd can received further messages on the
Page 2
INETD(1M) INETD(1M)
socket, it is said to be a ``multi-threaded'' server; it should read one
datagram from the socket and create a new socket connected to the peer.
It should fork, and the parent should then exit to allow inetd to check
for new service requests to spawn new servers. Datagram servers which
process all incoming datagrams on a socket and eventually time out are
said to be single-threaded. Talkd(8) is an example of the singlethreaded
datagram server. Tftpd(8) is an example of a multi-threaded
datagram server.
Servers using stream sockets generally are multi-threaded and use the
nowait entry. Connection requests for these services are accepted by
inetd, and the server is given only the newly-accepted socket connected
to a client of the service. Most stream-based services operate in this
manner. Stream-based servers that use wait are started with the
listening service socket, and must accept at least one connection request
before exiting. Such a server would normally accept and process incoming
connection requests until a timeout. RPC services usually wait. TCPMUX
services must use nowait.
The user field should contain the user name of the user as whom the
server should run. This allows for servers to be given less permission
than root.
The server program field should contain the pathname of the program which
is to be executed by inetd when a request is found on its socket. If
inetd provides this service internally, this field should be
``internal''. For non-internal services, the arguments to the server
program should be just as they normally are, starting with argv[0], which
is the name of the program. There is a limit of 11 arguments per program
(including argv[0]). A `?' character, placed just before the server
program pathname, causes inetd to suppress error logging of a missing
server. As shipped, /etc/inetd.conf uses `?' to suppress error logging
for servers that are included in optional software packages.
Inetd provides several trivial services internally by use of routines
within itself. These services are ``echo'', ``discard'', ``chargen''
(character generator), ``daytime'' (human readable time), ``time''
(machine readable time, in the form of the number of seconds since
midnight, January 1, 1900), and ``tcpmux'' (service multiplexor). All of
these services are TCP-based. For details of these services, consult
RFCs 862, 863, 864, 867, 868, and 1078.
Inetd rereads its configuration file when it receives a hangup signal,
SIGHUP. Services may be added, deleted or modified when the
configuration file is reread. To disable a service, add the comment
character ``#'' at the beginning of the service's line in inetd.conf and
send SIGHUP to inetd with the command
/etc/killall -HUP inetd
Page 3
INETD(1M) INETD(1M)
Inetd logs error messages using syslog(3B). Important error messages and
their explanations are:
service/protocol server failing (looping), service terminated.
The number of requests for the specified service in the past minute
exceeded the limit. The limit exists to prevent a broken program or a
malicious user from swamping the system. This message may occur for
several reasons: 1) there are lots of hosts requesting the service
within a short time period, 2) a 'broken' client program is requesting
the service too frequently, 3) a malicious user is running a program to
invoke the service in a 'denial of service' attack, or 4) the invoked
service program has an error that causes clients to retry quickly. Use
the -R option, as described above, to change the rate limit. Once the
limit is reached, the service will be reenabled automatically in 10
minutes.
service/protocol: such user 'user', service ignored
service/protocol: getpwnam: user: No such user
No entry for user exists in the passwd file. The first message occurs
when inetd (re)reads the configuration file. The second message occurs
when the service is invoked.
service: can't set uid number
service: can't set gid number
The user or group ID for the entry's user is invalid.
too many services: open-file limit reached.
The number of services in the configuration file exceeds the number of
file descriptors that inetd can keep open. Unnecessary services must be
removed or commented out or the kernel must be reconfigured to increase
the limit (the NOFILES parameter in /var/sysgen/master.d/kernel.)
Here are several example service entries for the various types of
services
ftp stream tcp nowait root /usr/etc/ftpd ftpd -l
ntalk dgram udp wait root /usr/etc/talkd talkd
rusersd/1 dgram rpc/udp wait root /usr/etc/rpc.rusersd rusersd
tcpmux/+date stream tcp nowait guest /bin/date date
Page 4
INETD(1M) INETD(1M)
If NIS is enabled on your system, inetd uses the NIS equivalents of
/etc/services and /etc/rpc. Make sure your NIS server's services and rpc
databases contain the entries listed in these files.
inetd has a limit of 512 characters per line of the configuration file.
Exceeding this limit may cause inetd to terminate abnormally.
If both TCP and UDP services are listed for an RPC service, the TCP
service should be listed first.
ftpd(1M), rexecd(1M), rlogind(1M), rshd(1M), telnetd(1M), tftpd(1M).
sockets programming chapter in the IRIX Network Programming Guide.
RFCs are available from the Network Information Center at SRI
International, Menlo Park, CA.
PPPPaaaaggggeeee 5555 [ Back ]
|
