Home arrow Site Administration arrow Core System Services

Core System Services

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



Regardless of distribution, network configuration, and overall system design, every Linux system has five core services: init, inetd, xinetd, syslogd, and cron. The functions performed by these services may be simple, but they are also fundamental. Without their presence, a great deal of Linux’s power would be missed.

In this module, we’ll discuss each one of the core services, its corresponding configuration file, and the suggested method of deployment (if appropriate). You’ll find that the sections covering these simple services are not terribly long, but don’t neglect this material. We highly recommend taking some time to get familiar with their implications (perhaps during those lovely commutes through traffic every morning). Many creative solutions have been realized through the use of these services. Hopefully, this module will inspire a few more.

CRITICAL SKILL 9.1  Understand the init Service

The init process is the patron of all processes. Always the first process that gets started in any UNIX-based system (such as Linux), init’s process ID is always 1. Should init ever fail, the rest of the system will most definitely follow suit.

The init process serves two roles. The first is being the ultimate parent process. Because init never dies, the system can always be sure of its presence and, if necessary, make reference to it. The need to refer to init usually happens when a process dies before all of its spawned children processes have completed. This causes the children to inherit init as their parent process. A quick execution of the ps -af command will show a number of processes that will have a parent process ID (PPID) of 1.

The second job for init is to handle the various runlevels by executing the appropriate programs when a particular runlevel is reached. This behavior is defined by the /etc/inittab file.

The /etc/inittab File

The /etc/inittab file contains all the information init needs for starting runlevels. The format of each line in this file is as follows:



Lines beginning with the number symbol (#) are comments. Take a peek at your own  /etc/inittab, and you’ll find that it’s already liberally commented. If you ever do need to make a change to /etc/inittab (and it’s unlikely that you’ll ever need to), you’ll do yourself a favor by including liberal comments to explain what you’ve done.

Table 9-1 explains the significance of each of the four items in the /etc/inittab file’s line format.

/etc/inittab Item



A unique sequence of 1–4 characters that identifies this entry in the /etc/inittab file.


The runlevels at which the process should be invoked. Some events are special enough that they can be trapped at all runlevels (for instance, the CTRL-ALT-DEL key combination to reboot). To indicate that an event is applicable to all runlevels, leave runlevels blank. If you want something to occur at multiple runlevels, simply list all of them in this field. For example, the runlevels entry 123 specifies something that runs at runlevels 1, 2, and 3.


Describes what action should be taken. Options for this field are explained in Table 9-2.


Names the process (program) to execute when the runlevel is entered.

Table 9-1  /etc/inittab Line Entry Format

Table 9-2 defines the options available for the action field in the /etc/inittab file.

Values for action Field in /etc/inittab File



The process will be restarted whenever it terminates.


The process will be started once when the runlevel is entered, and init will wait for its completion.


The process will be started once when the runlevel is entered; however, init won’t wait for termination of the process before possibly executing additional programs to be run at that particular runlevel.


The process will be executed at system boot. The runlevelsfield is ignored in this case.


The process will be executed at system boot, and init will wait for completion of the boot before advancing to the next process to be run.


The process will be executed when a specific runlevel request occurs. (These runlevels are a, b, and c.) No change in runlevel occurs.


Specifies the default runlevel for init on startup. If no default is specified, the user is prompted for a runlevel on console.


The process will be executed during system boot, before any of the boot or bootwait entries.

Table 9-2  Options Available for the action Field in
                  the /etc/inittab File

Values for action


Field in /etc/inittab File



If init receives a signal from another process that there are problems


with the power, this process will be run. Before continuing, init will


wait for this process to finish.


Same as powerwait, except that init will not wait for the process


to finish.


If init receives the same type of signal as powerwait, when a file


called /etc/powerstatus exists with the string "OK" in it, this process


will be executed, and init will wait for its completion.


The process is executed when init receives a signal indicating that the


user has pressed CTRL-ALT-DEL. Keep in mind that most X Window System


servers capture this key combination, and thus init will not receive this


signal if the X Window System is active.

Table 9-2  Options Available for the action Field in
                  the /etc/inittab File (continued)

Now let’s look at a sample line from an /etc/inittab file:

# If power was restored before the shutdown kicked in, cancel it. pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"

In this case:

  • pr is the unique identifier
  • 1, 2, 3, 4, and 5 are the runlevels from which this process can be activated
  • powerokwait is the condition under which the process is run
  • The /sbin/shutdown. . . command is the process

    The telinit Command

It’s time to ’fess up: the mysterious force that tells init when to change runlevels is actually the telinit command. This command takes two command-line parameters. One is the desired runlevel that init needs to know about, and the other is -t sec, where sec is the number of seconds to wait before telling init.


Whether init actually changes runlevels is its decision. Obviously, it usually does, or this command wouldn’t be terribly useful.


It is extremely rare that you’ll ever have to run the telinit command yourself. Usually, this is all handled for you by the startup and shutdown scripts.


Under most UNIX implementations (including Linux), the telinit command is really just a symbolic link to the init program. Because of this, some folks prefer running init with the runlevel they want rather than using telinit. Personally, I find that using telinit to change runlevels self-documents much more nicely.


Progress Check

  1. What does the telinit program do?
  2. What is the purpose of the /etc/inittab file?

What is init?


>>> 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: