A server is a running instance of an application (software) capable of accepting requests from the client and giving responses accordingly. Servers can run on any computer including dedicated computers, which individually are also often referred to as “the server”. Servers operate within a client-server architecture. Servers are computer programs running to serve the requests of other programs, the clients. Thus, the server performs some tasks on behalf of clients. It facilitates the clients to share data, information or any hardware and software resources. The clients typically connect to the server through the network but may run on the same computer. In the context of Internet Protocol (IP) networking, a server is a program that operates as a socket listener. Servers often provide essential services across a network, either to private users inside a large organization or to public users via the Internet. Typical computing servers are database server, file server, mail server, print server, web server, gaming server, and application server. Numerous systems use this client server networking model including Web sites and email services. An alternative model, peer-to-peer networking enables all computers to act as either a server or client as needed.
xinetd – the extended Internet services daemon
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 multi-threaded
and they require the forking of a new server process for each new con-
nection 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 ser-
vices for which the service daemon is responsible for handling 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 con-
serve system resources by avoiding to fork a lot of processes which
might be dormant for most of their lifetime. While fulfilling this
function, xinetd takes advantage of the idea of a super-server to pro-
vide 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.
-d Enables debug mode. This produces a lot of debugging output, and
it makes it possible to use a debugger on xinetd.
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 sys-
log.conf(5) for their meanings). This option is ineffective in
debug mode since all relevant messages are sent to the terminal.
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 since all relevant messages are sent to the terminal.
Determines the file that xinetd uses for configuration. The
default is /etc/xinetd.conf.
The process ID is written to the file. This option is ineffec-
tive in debug mode.
Tells xinetd to stay in the foreground rather than detaching
itself, to support being run from init or daemontools. This
option automatically sets -stayalive (see below).
Tells xinetd to stay running even if no services are specified.
This option places a limit on the number of concurrently running
processes that can be started by xinetd. Its purpose is to pre-
vent process table overflows.
This option places a limit on the number of concurrently running
servers for remote userid acquisition.
This option causes xinetd to print out its version information.
This option causes xinetd to read /etc/inetd.conf in addition to
the standard xinetd config files. /etc/inetd.conf is read after
the standard xinetd config files.
This option instructs xinetd to perform periodic consistency
checks on its internal state every interval seconds.
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
xinetd performs certain actions when it receives certain signals. The
actions associated with the specific signals can be redefined by edit-
ing config.h and recompiling.
SIGHUP causes a hard reconfiguration, which means that xinetd
re-reads the configuration file and terminates the
servers for services that are no longer available.
Access control is performed again on running servers by
checking the remote location, access times and server
instances. If the number of server instances is lowered,
some arbitrarily picked servers will be killed to sat-
isfy the limit; this will happen after any servers are
terminated because of failing the remote location or
access time checks. Also, if the INTERCEPT flag was
clear and is set, any running servers for that service
will be terminated; the purpose of this is to ensure
that after a hard reconfiguration there will be no run-
ning servers that can accept packets from addresses that
do not meet the access control criteria.
SIGQUIT causes program termination.
SIGTERM terminates all running servers before terminating
SIGUSR1 causes an internal state dump (the default dump file is
/var/run/xinetd.dump; to change the filename, edit con-
fig.h and recompile).
SIGIOT causes an internal consistency check to verify that the
data structures used by the program have not been cor-
rupted. When the check is completed xinetd will gener-
ate a message that says if the check was successful or
On reconfiguration the log files are closed and reopened. This allows
removal of old log files.
/etc/xinetd.conf default configuration file
/var/run/xinetd.dump default dump file
Panos Tsirigotis, CS Dept, University of Colorado, Boulder Rob Braun