Many network enabled Linux applications don’t rely on themselves to provide restricted access or bind to a particular TCP port; instead they often offload a lot of this work to a program suite made just for this purpose, xinetd.

Managing xinetd Programs

The xinetd RPM is installed by default in Fedora Linux and uses /etc/xinetd.conf as its main configuration file.You usually don’t have to edit this file so that day to day xinetd operation is frequently limited to only starting and stopping xinetd managed applications.

Controlling xinetd

The starting and stopping of the xinetd daemon is controlled by the by scripts in the /etc/init.d directory and its behavior at boot time is controlled by chkconfig.

You can start/stop/restart xinetd after booting by using the following commands:

# service xinetd start

# service xinetd stop

# service xinetd restart

To get xinetd configured to start at boot you can use the chkconfig command.

# chkconfig xinetd on

Controlling xinetd-Managed Applications

Xinetd-managed applications all store their configuration files in the /etc/xinetd.d directory. Each configuration file has a disable statement that you can set to yes or no. This governs whether xinetd is allowed to start them or not. You don’t have to edit these files to activate or deactivate the application. The chkconfig command does that for you automatically will also stops or starts the application accordingly too!

To establish the connection on a TCP/IP network, a client application needs the IP address of the server and the port number associated with the server daemon. All common TCP/IP applications have a standard port number; some examples are shown below

Typical Tcp/Ip Port Numbers

Port Number









SMTP (outgoing mail)




HTTPS (secure HTTP)


Internet Printing Protocol (CUPS configuration)

If you don’t specify the port number, TCP/IP assumes that you’re using the default port for the specified service. Clients can’t connect unless the corresponding server is running on the remote system. If you are managing a server, you may have a number of server daemons to start when Linux is booted.

The xinetd (which stands for the Extended Internet Services Daemon) service can start a number of these server daemons simultaneously. The xinetd service listens for connection requests for all of the active servers with scripts in the /etc/xinetd.d directory. There’s a generic configuration file for xinetd services, /etc/xinetd.conf. The scripts in the /etc/xinetd.d directory function as service-specific configuration files.

Generic xinetd Configuration

The generic configuration for xinetd services is stored in the /etc/xinetd.conf file.First, a number of default settings are enabled with the following command:


This allows services such as rsync to retain their default TCP/IP ports (873) within the xinetd service.

This is followed by

log_type SYSLOG daemon info

which specifies logging through the syslog daemon, as configured in /etc/syslog.conf.

This is followed by

log_on_failure HOST

which specifies the logging information when a login through an xinetd-controlled service fails. Naturally, this specifies the host name (or IP address) of the client host. It might help to add USERID to the list, which lists the UID number associated with the failed login. This can help you identify compromised accounts.

This line,


specifies the logging information associated with a successful connection. For example, once I logged off a Telnet connection from a remote system, and this led to the following entry in /var/log/messages:

Jul 25 17:54:31 Enterprise5vm xinetd[4618]: EXIT: telnet status=1

pid=4667 duration=472(sec)

The effect from /etc/xinetd.conf is straightforward. The next active line is

cps = 50 10

The cps command prevents attempts to “flood” any xinetd service; this line limits connections to 50 per second. If this limit is exceeded, xinetd waits 10 seconds before allowing a remote user to try again.

The next line,

instances = 50

limits the number of active services for a particular service; in this case, no more than 50 users can be logged into your Kerberos Telnet server simultaneously (less if other xinetd services are running).

This is followed by a related directive:

per_source = 10

This limits the number of connections from each IP address.

The next active directive is almost self-explanatory:

v6only = no

If you changed this to yes, access would be limited to systems with IPv6 addresses.

A couple of environment directives

groups = yes

umask = 002

allow execution with the xinetd group, or one defined with the group directive (singular).

Finally, the last line supports the use of the other configuration files specified in the /etc/xinetd.d directory:

includedir /etc/xinetd.d

Sample xinetd Configuration

Each file in the /etc/xinetd.d directory specifies a particular service you want to allow xinetd to manage. By default, scripts in this directory are disabled. The following code shows a sample of the /etc/xinetd.d/krb5-telnet configuration file, with this service disabled:

# default: off

# description: The kerberized telnet server accepts normal telnet sessions, but can also use Kerberos 5 authentication.

service telnet


     flags           = REUSE

     socket_type     = stream

     wait            = no

     user            = root

     server          = /usr/kerberos/sbin/telnetd

     log_on_failure  += USERID

     disable         = yes


This is a typical /etc/xinetd.d configuration file. The variables are described in table below. This is a versatile configuration file; other fields are described in the man pages for xinetd.conf.

Standard Parameters for xinetd Configuration Files


Description of Field Entry


Supports different parameters for the service; REUSE is a default that supports continuous use of the service.Options include IPv6 to set this as a service for those types of networks.


Specifies the communication stream.


Set to yes for single-threaded applications or no for multithreaded applications.


Account under which the server should run.


Group under which the server should run.


The server program.


Host name or IP address allowed to use the server. CIDR notation (such as is okay.


Host name or IP address not allowed to use the server. CIDR notation is okay.


If there’s a failed login attempt, this specifies the information sent to a log file.


By default, set to yes, which disables the service.

You can enable any xinetd service by changing disable = yes to disable = no.




About Manish Jha

Hi All I am Manish Kumar Jha aka Alex Hunt. I am currently working in VMware Software India Pvt Ltd as Operations System Engineer (vCloud Air Operations). I have around 5 Years of IT experience and have exposure on VMware vSphere, vCloud Director, RHEL and modern data center technologies like Cisco UCS and Cisco Nexus 1000v and NSX. If you find any post informational to you please press like and share it across social media and leave your comments if you want to discuss further on any post. Disclaimer: All the information on this website is published in good faith and for general information purpose only. I don’t make any warranties about the completeness, reliability and accuracy of this information. Any action you take upon the information you find on this blog is strictly at your own risk. The Views and opinions published on this blog are my own and not the opinions of my employer or any of the vendors of the product discussed.
This entry was posted in Linux/CentOS. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s