Fedora 11 and RHEL init scripts and processes

Learning Fedora 11 and Red Hat Enterprise Linux (RHEL) init scripts and processes will help you assist your customers when they have issues booting up their systems.

Solutions provider takeaway:
Solutions providers should know the basic facts when running init scripts and processes, such as how to approach an upstart or the run levels that most applicable to their environment.

System Initialization

About the book:
This chapter excerpt on Automating System Tasks (download PDF) is taken from the Fedora 11 and Red Hat Enterprise Linux Bible. This book appeals to all types of Linux users and details the top ways to install and manage the newest version of Fedora and Red Hat Enterprise Linux (RHEL), including system administration, automating system tasks and dealing with security issues.

When you turn on your computer, a lot happens even before Fedora or RHEL starts up. Here are the basic steps that occur each time you boot up your computer to run Fedora or RHEL:

  1. Boot hardware -- Based on information in the computer's read-only memory (referred to as the BIOS), your computer checks and starts up the hardware. Some of that information tells the computer which devices (floppy disk, CD, hard disk, and so on) to check to find the bootable operating system.
  2. Start boot loader -- After checking that no bootable operating system is ready to boot in your floppy, CD, or DVD drive, typically, the BIOS checks the master boot record on the primary hard disk to see what to load next. With Fedora or RHEL installed, the GRUB boot loader is started, allowing you to choose to boot Fedora, RHEL, or another installed operating system.
  3. Boot the kernel -- Assuming that you selected to boot Fedora or RHEL, the Linux kernel is loaded. That kernel mounts the basic file systems and transfers control to the init process. The rest of this section describes what happens after the kernel hands off control of system startup to the init process.

Starting init

In the boot process, the transfer from the kernel phase (the loading of the kernel, probing for devices, and loading drivers) to init is indicated by the following lines:

Welcome to Fedora
Press "I" to enter interactive startup.

The init program, part of the upstart RPM package, is now in control. The output from ps always lists init (known as "the father of all processes") as PID (process identifier) 1.

Prior to Fedora 9, a special script, /etc/inittab, directed the actions of the init program. Starting in Fedora 9, a new initialization system called upstart replaced the older SysV Unix-style init program.

With upstart, the /etc/inittab file controls only the default run level. Everything else gets run from a special script for each run level, for example, /etc/event.d/rc5 for run level 5. Upstart is based on the concept of launching programs based on events rather than run levels. Upstart can restart services that terminate, and isn't as fragile as the older SysV init system.

Since so many Linux programs make assumptions about the init system, though, upstart operates under a compatibility mode. In addition, to understand upstart, you need to understand the older Linux and Unix run levels, described in the following section. Over a number of Fedora releases, upstart will gradually phase out older means to initialize Linux. For now, though, the following concepts still apply.

The inittab file

The following example shows the contents of the /etc/inittab file as it is delivered with Fedora and RHEL in versions prior to Fedora 9:

#
# inittab This file describes how the INIT process should set up
# the system in a certain run level.

.

.

.

id:5:initdefault:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

10:0:wait:/etc/rc.d/rc 0
11:1:wait:/etc/rc.d/rc 1
12:2:wait:/etc/rc.d/rc 2
13:3:wait:/etc/rc.d/rc 3
14:4:wait:/etc/rc.d/rc 4
15:5:wait:/etc/rc.d/rc 5
16:6:wait:/etc/rc.d/rc 6

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes
# of power left. Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

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

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
x:5:once:/etc/X11/prefdm -nodaemon

The plain-text inittab file consists of several colon-separated fields in the format:

id:runlevels:action:command

The id field is a unique identifier, one to four alphanumeric characters in length, that represents a particular action to take during system startup. The runlevels field contains list of run levels in which the command will be run. Common run levels are 0, 1, 2, 3, 4, 5, and 6 (s and S represent single-user mode, which is equivalent to 1). Run levels 7, 8, and 9 can also be used as the special run levels associated with the on-demand action (a, b, and c, which are equivalent to A, B, and C). The next field represents the type of action to be taken by init (valid actions and the results of those actions are listed in Table 12-3), and the last field is the actual command that is to be executed.

Table 12-3: Valid init Actions

Action

How the Command Is Run

once

The command is executed once when entering the specified run level

wait

The same as once, but init waits for the command to finish before continuing with other inittab entries.

respawn

The process is monitored, and a new instance is started if the original process terminates.

powerfail

The command is executed on receiving a SIGPWR signal from software associated with a UPS unit. This assumes a few minutes of power are left so, by default, the system can shut down the system in two minutes.

powerwait

The same as powerfail, but init waits for the command to finish

powerokwait

The command is executed on receiving a SIGPWR signal if the /etc/powerstatus file contains the word OK. This is generally accomplished by the UPS software and indicates that a normal power level has been restored.

powerfailnow

The local system may be able to detect that an external UPS is running out of power and is about to fail almost immediately.

ondemand

The command is executed when init is manually instructed to enter one of the special run levels a, b, or c (equivalent to A, B, and C, respectively). No change in run level actually takes place. The program is restarted if the original process terminates.

sysinit

The command is executed during the system boot phase; the runlevels field is ignored.

boot

The command is executed during the system boot phase, after all sysinit entries have been processed; the runlevels field is ignored.

bootwait

The same as boot, but init waits for the command to finish before continuing with other inittab entries; the runlevels field is also ignored.

initdefault

The run level to enter after completing the boot and sysinit actions.

off

Nothing happens (perhaps useful for testing and debugging).

ctrlaltdel

Traps the Ctrl+Alt+Del key sequence and is typically used to gracefully shut down the system.

kbrequest

Used to trap special key sequences, as interpreted by the keyboard handler.

Because the inittab file is a configuration file, not a sequential shell script, the order of lines is not significant. Lines beginning with a hash (#) character are comments and are not processed.

The first non-commented line in the preceding sample inittab file sets the default run level to 5. A default of 5 (which is the common run level for desktop systems) means that, following the completion of all commands associated with the sysinit, boot, and bootwait actions, run level 5 is entered (booting to a text-based login). The other common initdefault level is run level 3 (often used for servers that boot up in text mode and often have no GUI). Table 12-4 describes each of the run levels and helps you choose the run level that is best suited as the default in your environment.

Table 12-4: Possible Run Levels

Run Level

What Happens in This Run Level

0

All processes are terminated and the machine comes to an orderly halt. As the inittab comments point out, this is not a good choice for initdefault because as soon as the kernel, modules, and drivers are loaded, the machine halts.

1, s, S

This is single-user mode, frequently used for system maintenance and instances where it may be preferable to have few processes running and no services activated. In single-user mode, the network is nonexistent, the X server is not running, and it is possible that some file systems are not mounted

2

Multiuser mode. Multiple user logins are allowed, all configured file systems are mounted, and all processes except X, the at daemon, the xinetd daemon, and NIS/NFS are started. If your machine doesn't have (or perhaps doesn't need) a permanent network connection, this is a good choice for initdefault.

3

Multiuser mode with network services. Run level 3 is the typical value for initdefault on a Fedora or RHEL server.

4

Run level 4 is available as a user-defined run level. It is nearly identical to runlevel 3 in a default Fedora or RHEL configuration.

5

Multiuser mode with network services and X. This run level starts the X server and presents a graphical login window, visually resembling any of the more expensive UNIX-based workstations. This is a common initdefault value for a Fedora or RHEL workstation or desktop system.

6

All processes are terminated and the machine is gracefully rebooted. Again, the comments in the inittab file mention that this is not a good choice for initdefault, perhaps even worse than run level 0. The effect is a possibly infinite cycle of booting, followed by rebooting.

7, 8, 9

Generally unused and undefined, these run levels have the potential to meet any needs not covered by the default options.

a, b, c, A, B, C

Used in conjunction with the ondemand action. These don't really specify a run level but can launch a program or daemon "on demand" if so instructed.

NOTE: If there is no initdefault specified in theinittab file, the boot sequence will be interrupted and you will be prompted to specify a default run level into which the machine will boot.

The next line in the inittab file instructs init to execute the /etc/rc.d/rc.sysinit script before entering the default run level. This script performs many initialization routines such as choosing a keymap file, checking and mounting root and proc file systems, setting the clock and hostname, configuring swap space, cleaning up temp files, and loading modules.

The seven following lines control the commands executed within each major run level. In each, the /etc/rc.d/rc script is called, using the desired run level as an argument. In turn, it descends into the appropriate directory tree (for example, the /etc/rc3.d directory is entered for run level 3).

About the author:
Christopher Negus spent several years working with UNIX operating system at the AT&T labs and in recent years has focused on Fedora and RHEL. His other Linux content includes the Linux Bible 2009 Edition: Boot up Ubuntu, Fedora, KNOPPIX, Debian, openSUSE, and more.

The ctrlaltdel action in the inittab file tells init to perform exactly what PC users would expect if the Ctrl, Alt, and Delete keys were pressed simultaneously. The system reboots itself in an orderly fashion (a switch to run level 6) after a three-second delay.

The next two lines (with their comments) deal with graceful shutdowns if you have an uninterruptible power supply (UPS) and software installed. The first line initiates a halt (a switch to run level 0) two minutes after receiving a signal from the UPS indicating a power failure. The second line cancels the shutdown in the event that power is restored.

The six getty lines start up virtual consoles to allow logins. These processes are always running in any of the multiuser run levels. When someone connected to a virtual console logs out, that getty process dies, and then respawn action tells init to start a new getty process. You can switch between virtual consoles by pressing Ctrl+Alt+F1, Ctrl+Alt+F2, and so on.

The last line indicates that as long as the system is in run level 5, the "preferred display manager" (xdm, gnome, KDE, and so on) will be running. This presents a graphical login prompt rather than the usual text-based login, and eliminates the need to run startx to start the GUI.

Starting with Fedora 10, the inittab file contains a simple one-line setting to define the default run level:

id:5:initdefault

This file specifies run level 5 as the default.


Automating System Tasks
  Fedora 11 and RHEL init scripts and processes
  Understanding run-level scripts in Fedora 11 and RHEL
  Scheduling system tasks in Fedora 11 and RHEL

Printed with permission from Wiley Publishing. Copyright 2009. Fedora 11 and Red Hat Enterprise Linux Bible by Christopher Negus. For more information about this title and other similar books, please visit http://www.wiley.com/.
This was first published in December 2009

Dig deeper on Server Operating Systems: Windows, Linux and Unix

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

MicroscopeUK

SearchCloudProvider

SearchSecurity

SearchStorage

SearchNetworking

SearchCloudComputing

SearchConsumerization

SearchDataManagement

SearchBusinessAnalytics

Close