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 contains all the information init needs for starting runlevels. The format of each line in this file is as follows:

id:runlevels:action:process

NOTE

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	Description
id	A unique sequence of 1–4 characters that identifies this entry in the /etc/inittab file.
runlevels	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.
action	Describes what action should be taken. Options for this field are explained in Table 9-2.
process	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	Description
respawn	The process will be restarted whenever it terminates.
wait	The process will be started once when the runlevel is entered, and init will wait for its completion.
once	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.
boot	The process will be executed at system boot. The runlevelsfield is ignored in this case.
bootwait	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.
ondemand	The process will be executed when a specific runlevel request occurs. (These runlevels are a, b, and c.) No change in runlevel occurs.
initdefault	Specifies the default runlevel for init on startup. If no default is specified, the user is prompted for a runlevel on console.
sysinit	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	Description
powerwait	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.
powerfail	Same as powerwait, except that init will not wait for the process
	to finish.
powerokwait	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.
ctrlaltdel	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.

NOTE

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.

NOTE

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?

----------------------------------------------------