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).
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 initprocess 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 initever 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 initusually 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 initneeds 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.
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
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.