inetd Vs xinetd in linux

The inetd daemon

The inetd daemon is best described as a super-server, created to manage many daemons or services. It listens to multiple ports, and invokes only requested services.

This reduces the load that services place on a system, because it means that network services – such as telnet, File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP) – can be activated on demand rather than having to run continuously.

When a system initializes, the inetd daemon needs to determine its configuration information. To do this, the daemon accesses two files – /etc/services and /etc/inetd.conf.

The /etc/services file contains a list of network services and the ports to which they map.  Network services have standard default ports on which client machines can find them. This enables clients to connect to particular services. For instance, HTTP uses port 80, FTP uses port 21, and telnet uses port 23.

Entries in the /etc/services file are divided into 4 fields,

  • servicename – The servicename field specifies the name of a network service. Typical entries include telnet, File Transfer Protocol (FTP), and Post Office Protocol (POP).
  • port/protocol – The port/protocol field identifies the number of the port and the protocol – or communication standard – that a service uses. The protocol is usually Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). Both port and protocol entries should be included.
  • aliases – The aliases field specifies any alternative names for a network service. For instance, a common alias for www is HTTP. This field is optional.
  • Comment – The comment field is an optional field in which you can enter any additional information about a service.


service-name port/protocol [aliases …] [# comment]
pop2 109/tcp pop-2 postoffice # pop version
pop2 109/udp pop-2
pop3 110/tcp pop-3 postoffice # pop version 3
pop3 110/udp pop-3 postoffice

Another configuration file, /etc/inetd.conf, contains a list of network services that tell inetd which ports to listen to and which server programs to run in response to service requests.  Each entry in the /etc/inetd.conf file consists of seven fields.

  • service_name – The service_name field identifies a network service. The service name should be listed as it is defined in the /etc/services file. Any internal service should be given its official name.
  • socket_type – The socket_type field identifies the type of port or virtual connection – usually stream or dgram (datagram) – that a network service uses. TCP services use stream and UDP services use dgram. Less common socket type values include raw, rdm, and seqpacket.
  • protocol – The protocol field identifies the communication standard that a network service uses. Its value is usually TCP or UDP. This field should contain one of the protocols listed in the /etc/protocols file and should match the protocol field of a service’s entry in the /etc/services file.
  • flags – The flags field specifies the behavior of inetd after it invokes a server in response to a service request. Multithreaded TCP servers free the port after it starts and enable inetd to invoke a new instance of the server to handle new requests. Single-threaded UDP servers cannot free the port until the server has finished running. So you should always set dgram sockets to wait and all other socket types to nowait.
  • user – The user field identifies the user account under which a service must run. The username should be defined in the /etc/passwd file and is often set to root. You can also specify a group name by placing a dot between the user and group names.
  • server_path – The server_path field contains the pathname of the server that the inetd daemon must invoke when it receives a service request. In most cases, this field reads /usr/sbin/tcpd, where tcpd is responsible for controlling access to network services. If the network service is one of inetd’s local services, the entry for this field should also be local.
  • arguments – The arguments field enables you to specify command-line arguments for the server daemon. The first argument, argv[0], is the daemon name and is always present, except in the case of internal services. If the server daemon is tcpd, an argument must specify the name of the service that tcpd must invoke.

ftp stream tcp nowait root /usr/sbin/tcpd
#telnet stream tcp nowait root /usr/sbin/tcpd
shell stream tcp nowait root /usr/sbin/tcpd
#login stream tcp nowait root /usr/sbin/tcpd
talk dgram udp wait nobody.tty /usr
ntalk dgram udp wait nobody.tty /usr
finger stream tcp nowait nobody /usr/sbin/tcpd

TIP: single command to check currently enabled services from /etc/inted.conf

[root@easynomad1 grosetti]# grep -v “^#” /etc/inetd.conf
Whenever we modify the /etc/inetd.conf file, you need to refresh inetd to implement the new settings.

To do this, you can use the stop command and then the start command. Alternatively, you can use either the restart or the reload commands. One drawback of the inetd daemon is that it needs to load and initialize a new process before it can handle a new request. This slows down response times.

So if a service has a high number of connections and requires high data processing, you should run it as a standalone daemon rather than using inetd to invoke it. Suppose that you want inetd to invoke the telnet service. Before you do this, you first need to check which inetd services are currently enabled.

The xinetd daemon

In linux, the extended Internet services daemon (xinetd) replaced inetd. It performs the same function as inetd in that it listens to multiple ports and invokes a requested service. However, it is more secure. Typical xinetd services include Remote Shell (RSH), FTP, telnet, and Post Office Protocol 3 (POP3).
Like the inetd daemon, xinetd needs to load and initialize a new process before it can handle a new request. If a network handles a large volume of e-mail, for example, the xinetd daemon would need to invoke the mail service for each mail request individually, resulting in an extremely slow response time. So it’s preferable to run the network’s mail service as a standalone daemon.

It’s also common to run the HTTP, sendmail, ident, and Samba services as standalone daemons.  Services that xinetd manages are not encrypted. However, each service has its own level of authentication, which limits their use to trusted users and helps prevent denial-of-service (DoS) attacks.

The xinetd daemon is incompatible with inetd because its configuration file has a different format. However, a program is available that converts the inetd file into the required format.
The xinetd daemon uses the /etc/xinetd.conf file to set the parameters for the services that it manages.

The /etc/xinetd.conf file contains six parameters.

  • instances – The instances parameter specifies the maximum number of services that xinetd can invoke at the same time.
  • log_type – The log_type parameter sets xinetd to use the SYSLOG authpriv facility.
  • log_on_success – The log_on_success parameter specifies the logging information when a connection is successful. Typical values include PID, HOST, and USERID.
  • log_on_failure – The log_on_failure parameter specifies the logging information when a connection fails. Typical values include HOST and USERID.
  • cps – The cps parameter controls the rate of incoming connections. The first argument specifies the maximum number of connections. The second argument specifies how long xinetd is disabled.
  • includedir – The includedir parameter specifies the directory that xinetd must read for specific configurations.

Unlike the inetd daemon, the xinetd daemon doesn’t need the services in its configuration file to be listed in the services file. Each service’s configuration file has a disable parameter, which has yes as the default value. You can enable a service by manually changing the value of the disable parameter to no.
You can enable / disable services under xinetd. With below commands

# chkconfig service_name on
# chkconfig service_name off

If you modify the /etx/xinter.conf you need to refresh the service with below command

[root@easynomad1 grosetti]# service xinetd reload
Reloading configuration: [ OK ]
[root@easynomad1 grosetti]#

Configuring  xinted

The /etc/xinetd.conf file sets the basic parameters for all services that xinetd manages. It sets the number of active servers, specifies logging settings, limits the number of incoming connections, and reads all files in /etc/xinetd.d.
For any xinetd managed service to work as required, you need to configure its settings correctly in the /etc/xinetd.d configuration file. Each xinetd service configuration file contains a disable parameter, which is set to yes by default.  To enable a service, you need to set the disable parameter to no.

service telnet
disable = yes
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/telnetd
server_args = -a none
log_on_failure += USERID

Once you’ve modified entries in the /etc/xinetd.conf file, you need to refresh or restart the xinetd daemon to accept the changes. To refresh the xinetd daemon, you can use the following options:
stop – You use the stop option in the following command to shut down the xinetd daemon completely:

#  /etc/rc.d/init.d/xinetd stop

The stop option temporarily interrupts the daemon’s services while it is stopped.
Start – You use the start option in the following command to restart the xinetd daemon after you’ve stopped it:

#  /etc/rc.d/init.d/xinetd start

The start option temporarily interrupts the daemon’s services while it is stopped.

restart – You use the restart option in the following command to stop and start xinetd using one command:

# /etc/rc.d/init.d/xinetd restart

The restart option temporarily interrupts the daemon’s services while it is stopped.

reload – You use the reload option in the following command to refresh the xinetd daemon without interrupting services:

#/etc/rc.d/init.d/xinetd reload

TIP : You can refresh the xinetd daemon by sending it a SIGHUP signal using this command, which forces xinetd to reread its configuration file.with minimal disruption to the services

[root@easynomad1 grosetti]# killall -SIGHUP xinetd
[root@easynomad1 grosetti]#



I have started ( aka in 2009 as my own personal reference blog, and later sometime i have realized that my leanings might be helpful for other unixadmins if I manage my knowledge-base in more user friendly format. And the result is today's' You can connect me at -

3 Responses

  1. May 3, 2012


    […]unix administration @ » inetd Vs xinetd in linux[…]…

  2. September 18, 2015

    […] Read – inetd Vs xinetd in linux […]

What is in your mind, about this post ? Leave a Reply

  Our next learning article is ready, subscribe it in your email

What is your Learning Goal for Next Six Months ? Talk to us