Home arrow Site Administration arrow Page 2 - Core System Services

CRITICAL SKILL 9.2 Learn the inetd and xinetd Processes - Administration

Every Linux system has five core services which perform fundamental functions. This article discusses each of these services. It is excerpted from chapter nine of Linux Administration A Beginner's Guide, Third Edition, written by Steven Graham and Steven Shah (McGraw-Hill/Osborne, 2004; ISBN: 0072225629).

  1. Core System Services
  2. CRITICAL SKILL 9.2 Learn the inetd and xinetd Processes
  3. Variables and Their Meanings
  4. Project 9-1 Enabling/Disabling the Telnet Service
  5. CRITICAL SKILL 9.4 Learn How to Use the cron Program
By: McGraw-Hill/Osborne
Rating: starstarstarstarstar / 10
October 13, 2005

print this article



The inetd and xinetd programs are daemon processes. You probably know that daemons are special programs that, after starting, voluntarily release control of the terminal from which they started. The only mechanism by which daemons can interface with the rest of the system is through interprocess communication (IPC) channels, by sending entries to the system-wide log file, or by appending to a disk file.

The role of inetd is as a ďsuperserverĒ for other network server-related processes, such as telnet and ftp. Itís a simple philosophy: Not all server processes (including those that accept new telnet and ftp connections) are called upon so often that they require a program to be running in memory all the time. So instead of constantly maintaining potentially dozens of services loaded in memory waiting to be used, they are all listed in inetdís configuration file, /etc/inetd.conf. On their behalf, inetd listens for incoming connections. Thus only a single process needs to be in memory.

A secondary benefit of inetd falls to those processes needing network connectivity but whose programmers do not want to have to write it into the system. The inetd program will handle the network code and pass incoming network streams into the process as its standard-in (stdin). Any of the processís output (stdout) is sent back to the host that has connected to the process.


Unless you are programming, you donít have to be concerned with inetdís stdin/ stdout feature. On the other hand, for someone who wants to write a simple script and make it available through the network, itís worth exploring this very powerful tool.

As a general rule of thumb, low-volume services (such as Telnet) are usually best run through the inetd, whereas higher-volume services (such as Web servers) are better run as a standalone process that is always in memory ready to handle requests.

Current distributions of Red Hat and Mandrake started using a newer version of inetd called xinetd. The xinetd program accomplishes the same task as the regular inetd program, yet it includes a new configuration file format and some additional features.

Unfortunately, xinetd uses a format that is very different than the classic inetd configuration file format. (Most other variants of UNIX, including Solaris and FreeBSD, use the classic inetd format.) This means that if you have an application that relies on inetd, you may need to provide some hand adjustments to make it work. Of course, you should definitely contact the developers of the application and let them know of the change so that they can release a newer version that works with the new xinetd configuration format, as well.

In this section, we will cover the new xinetd daemon. If your system uses inetd, you should be able to read /etc/inetd.conf and see the similarities between inetd and xinetd.

The /etc/xinetd.conf File

The /etc/xinetd.conf file consists of a series of blocks that take the following format:

    variable = value

where blockname  is the name of the block that is being defined, variable is the name of a variable being defined within the context of the block, and value is the value assigned to the variable. Every block can have multiple variables defined within.

One special block exists which is called ďdefaults.Ē Whatever variables are defined within this block are applied to all other blocks that are defined in the file.

An exception to the block format is the includedir directive, which tells xinetd to go read all the files in a directory and consider them to be part of the  /etc/xinetd.conf file.

Any line that begins with a number sign (#) is the start of a comment. The stock /etc/inetd.conf file that ships with Red Hat 7.3 looks like this:

# Simple configuration file for xinetd
# Some defaults, and include /etc/xinetd.d/
       instances         = 60
       log_type          = SYSLOG authpriv
       log_on_success    = HOST PID 
       log_on_failure    = HOST RECORD
includedir /etc/xinetd.d

Donít worry if all of the variables and values arenít familiar to you yet; we will go over those in a moment. Letís first make sure you understand the format of the file.

In this example, the first four lines of the file are comments explaining what the file is and what it does. After the comments, you see the first block: defaults. The first variable that is defined in this block is instances, which is set to the value of 60. Four variables in total are defined in this block, the last one being log_on_failure. Since this block is titled defaults, the variables that are set within it will apply to all future blocks that are defined. Finally, the last line of the file specifies that the /etc/xinetd.d directory must be examined for other files that contain more configuration information. This will cause xinetd to read all of the files in that directory and parse them as if they were part of the /etc/xinetd.conf file.

>>> More Site Administration Articles          >>> More By McGraw-Hill/Osborne

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Coding: Not Just for Developers
- To Support or Not Support IE?
- Administration: Networking OSX and Win 7
- DotNetNuke Gets Social
- Integrating MailChimp with Joomla: Creating ...
- Integrating MailChimp with Joomla: List Mana...
- Integrating MailChimp with Joomla: Building ...
- Integrating MailChimp with Joomla
- More Top WordPress Plugins for Social Media
- Optimizing Security: SSH Public Key Authenti...
- Patches and Rejects in Software Configuratio...
- Configuring a CVS Server
- Managing Code and Teams for Cross-Platform S...
- Software Configuration Management
- Back Up a Joomla Site with Akeeba Backup

Developer Shed Affiliates


Dev Shed Tutorial Topics: