|
Previous | Table of Contents | Next
Page 655
xinetd—The extended Internet services daemon
SYNOPSIS
xinetd [options]
DESCRIPTION
xinetd performs the same function as inetd: it starts programs that provide Internet services. Instead of having
such servers started at system initialization time, and be dormant until a connection request arrives,
xinetd is the only daemon process started and it listens on all service ports for the services listed in its configuration file. When a
request comes in, xinetd starts the appropriate server. Because of the way it operates,
xinetd (as well as inetd) is also referred to as a super-server.
The services listed in xinetd's configuration file can be separated into two groups. Services in the first group are
called multithreaded and they require the forking of a new server process for each new connection request. The new
server then handles that connection. For such services,
xinetd keeps listening for new requests so that it can spawn
new servers. On the other hand, the second group includes services for which the service daemon is responsible for
handling xinetd all new connection requests. Such services are called single-threaded and
xinetd will stop handling new requests for them until the server dies. Services in this group are usually datagram based.
So far, the only reason for the existence of a super-server was to conserve system resources by avoiding to fork a
lot of processes who might be dormant for most of their lifetime. While fulfilling this function,
xinetd takes advantage of the idea of a super-server to provide features such as access control and logging. Furthermore,
xinetd is not limited to services listed in
/etc/services. Therefore, anybody can use xinetd to start special-purpose servers.
OPTIONS
|
_d
|
Enables debug mode. This produces a lot of
debugging output, and it makes it possible to use a debugger on
xinetd.
| |
_syslog syslog_facility
|
This option enables
syslog logging of xinetd-produced messages using the specified
syslog facility. The following facility names are supported:
daemon, auth, user, local[0-7] (check syslog.conf(5) for their meanings). This option
is ineffective in debug mode because all relevant messages
are sent to the terminal.
| |
_filelog logfile
|
xinetd-produced messages will be placed in the specified
file. Messages are always appended to the file. If the file
does not exist, it will be created. This option is ineffective
in debug mode because all relevant messages are sent to
the terminal.
| |
_f config_file
|
Determines the file that
xinetd uses for configuration. The default is
/etc/xinetd.conf.
| |
_pid
|
The process pid is written to standard error. This option
is ineffective in debug mode.
| |
_loop rate
|
This option sets the loop rate beyond which a service
is considered in error and is deactivated. The loop rate
is specified in terms of the number of servers per second
that can be forked for a process. The speed of your
machine determines the correct value for this option. The
default rate is 10.
| |
_reuse
|
If this option is used, xinetd will set the socket
option SO_REUSEADDR before binding the service socket to
an Internet address. This allows binding of the address even
if there are programs that use it, which happens when
a previous instance of xinetd has started some servers that
are still running. This option has no effect on RPC services.
|
Page 656
|
_limit proc_limit
|
This option places a limit on the number of
concurrently running processes that can be started by
xinetd. Its purpose is to prevent process table overflows.
| |
_logprocs limit
|
This option places a limit on the number of
concurrently running servers for remote user ID acquisition.
| |
_shutdownprocs limit
|
This option places a limit on the number of
concurrently running servers for service shutdown (forked when
the RECORD option is used).
The syslog and filelog options are mutually exclusive. If none is specified, the default is
syslog using the daemon facility. You should not confuse
xinetd messages with messages related to service logging. The latter are logged only if this
is specified via the configuration file.
|
CONFIGURATION FILE
The configuration file determines the services provided by
xinetd. Any line whose first nonwhitespace character is a
# is considered a comment line. Empty lines are ignored.
The file contains entries of the form:
service <service_name>
{
<attribute> <assign_op><value><value> ...
...
}
0The assignment operator, assign_op, can be one of
=, +=, -=. The majority of attributes support only the
simple assignment operator, =. Attributes whose value is a set of values support all assignment operators. For such
attributes, += means adding a value to the set and
-= means removing a value from the set. A list of these attributes is given
after all the attributes are described.
Each entry defines a service identified by the
service_name. The following is a list of available attributes:
|
id
|
This attribute is used to uniquely identify a service. This
is useful because there exist services that can use
different protocols and need to be described with different entries
in the configuration file. By default, the service
id is the same as the service name.
| |
type
|
Possible values are the following:
|
|
RPC
|
If this is an RPC service
| |
INTERNAL
|
If this is a service provided by
xinetd.
| |
UNLISTED
|
If this is a service not listed in
/etc/services.
| |
flags
|
Possible flag values are
| |
REUSE
|
Set the SO_REUSEADDR flag on the
service socket.
| |
INTERCEPT
|
Intercept packets or accepted connections
in order to verify that they are coming from acceptable locations (internal
or multithreaded services cannot be intercepted).
NORETRY Avoid retry attempts in case of fork failure.
| |
socket type
|
Possible values are
| |
stream
|
Stream-based service
| |
dgram
|
Datagram-based service
| |
raw
|
Service that requires direct access to IP
| |
seqpacket
|
Service that requires reliable
sequential datagram transmission
|
Previous | Table of Contents | Next
|
