Running Services at Bootup

Although most people consider a computer to be either on or off, in Fedora there are a number of states in between. Known as runlevels, they control what system services are started at bootup. These services are simply applications running in the background that provide some needed function to your system, such as getting information from your mouse and sending it to the display; or a service could monitor the partitions to see whether they have enough free space left on them. Services are typically loaded and run (also referred to as being started) during the boot process, in the same way as Microsoft Windows services are.

You can manage nearly every aspect of your computer and how it behaves after booting via configuring and ordering boot scripts, as well as by using various system administration utilities included with Fedora. In this chapter, you learn how to work with these boot scripts and system administration utilities. This chapter also offers advice for troubleshooting and fixing problems that might arise with software configuration or the introduction or removal of various types of hardware from your system.

Beginning the Boot Loading Process

Although the actual boot loading mechanism for Linux varies on different hardware platforms (such as the SPARC, Alpha, or PowerPC systems), Intel-based PCs running Fedora most often use the same mechanism throughout product lines. This process is accomplished through a Basic Input Output System, or BIOS. The BIOS is an application stored in a chip on the motherboard that initializes the hardware on the motherboard (and often the hardware that's attached to the motherboard). The BIOS gets the system ready to load and run the software that we recognize as the operating system.

As a last step, the BIOS code looks for a special program known as the boot loader or boot code. The instructions in this little bit of code tell the BIOS where the Linux kernel is located, how it should be loaded into memory, and how it should be started.

If all goes well, the BIOS looks for a bootable volume such as a floppy disk, CD-ROM, hard drive, RAM disk, or other media. The bootable volume contains a special hexadecimal value written to the volume by the boot loader application (likely either GRUB or LILO, although LILO is not provided with Fedora) when the boot loader code was first installed in the system's drives. The BIOS searches volumes in the order established by the BIOS settings (for example, the floppy first, followed by a CD-ROM, and then a hard drive) and then boots from the first bootable volume it finds. Modern BIOSs allow considerable flexibility in choosing the device used for booting the system.

Note

If the BIOS detects a hardware problem, the boot process fails and the BIOS generates a few beeps from the system speaker. These "beep codes" indicate the nature of the problem the BIOS has encountered. The codes vary among manufacturers, and the diagnosis of problems occurring during this phase of the boot process is beyond the scope of this book and does not involve Linux. If you encounter a problem, you should consult the motherboard manual or contact the manufacturer of the motherboard.

Next, the BIOS looks on the bootable volume for boot code in the partition boot sector also known as the Master Boot Record (MBR) of the first hard disk. The MBR contains the boot loader code and the partition tablethink of it as an index for a book, plus a few comments on how to start reading the book. (We cover the MBR in more detail in Chapter 38, "Managing the File System.") If the BIOS finds a boot loader, it loads the boot loader code into memory. At that point, the BIOS's job is completed, and it passes control of the system to the boot loader.

The boot loader locates the Linux kernel on the disk and loads it into memory. After that task is completed, the boot loader passes control of the system to the Linux kernel. You can see how one process builds on another in an approach that enables many different operating systems to work with the same hardware.

Fedora can use a variety of boot loaders, including GRUB (the default for Fedora), LILO (a long-time standard but not available with Fedora), BootMagic (a commercial program), and others.

Note

Linux is very flexible and can be booted from multiple images on a CD-ROM, over a network using PXE (pronounced "pixie") or NetBoot, or on a headless server with the console display sent over a serial or network connection. Work is even underway to create a special Linux BIOS at http://www.linuxbios.org/ that expedites the boot process because Linux does not need many of the services offered by the typical BIOS.

This kind of flexibility enables Linux to be used in a variety of ways, such as remote servers or diskless workstations, which are not generally seen in personal home use.

Loading the Linux Kernel

In a general sense, the kernel manages the system resources. As the user, you do not often interact with the kernel, but instead just the applications that you are using. UNIX refers to each application as a process, and the kernel assigns each process a number called a process ID (PID). First, the Linux kernel loads and runs a process named init, which is also known as the "father of all processes" because it starts every subsequent process. The init process looks for a list of instructions in a file named /etc/rc.d/rc.sysinit. That script issues a number of commands that are only run onceeach time the system is turned on.

Note

Details about the sequence of events that occur when the Linux kernel is loaded can be found in the file /usr/src/linux-2.6/init/main.c if you installed the Linux kernel documentation.

This next step of the boot process begins with a message that the Linux kernel is loading, and a series of messages is printed to the screen, giving you the status of each command in rc.sysinit script language. A failure should display an error message. The -quiet option may be passed to the kernel at boot time to suppress many of these messages.

Although it is not intended that you modify the rc.sysinit script, knowledge of the contents of the file might aid you in diagnosing a problem if the boot process fails during this step. Look at /etc/rc.d/rc.sysinit, and you will discover that it's just a text file filled with shell script language.

After the rc.sysinit script has run, the basic system is configured and the kernel is in control of the system. If the boot process were halted at this point, the system would just sit idle and the screen would be blank. To make the system useful for users, we need to start the system services. Those services are some of the applications that allow us to interact with the system.

System Services and Runlevels

After finishing with rc.sysinit script during the bootloading process, the init command uses the Linux system initialization table found in /etc/inittab to boot Fedora to a specific system state. The state of the system is commonly referred to as its runlevel.

Several different ways of starting and stopping system services exist, and Fedora uses a method derived from System V UNIX. The System V (pronounced "System Five") method uses runlevels and different combinations of services to define different states of operation. Runlevels determine which of the many available system services are started, as well as in which order they start. A special runlevel is used to stop the system, and a special runlevel is used for system maintenance. As you will see, there are other runlevels for special purposes.

Note

The System V method makes extensive use of symbolic links, which are ways to reference a file in another location and make it appear as if it were in two or more places at once. The benefit is that you need to edit only one file to change them all. In addition, any reorganization to be done means that only links need to be changed, not the files themselves.

You use runlevels to manage the system services running on your computer. All these special files and scripts are set up during your installation of Fedora Linux, and they receive their initial values based on your choices during the installationas described in Chapter 3, "Installing Fedora," and Chapter 4, "Post-Installation Configuration." You can change and control them manually, as you learn later in this chapter, using tools of varying sophistication.

Runlevel Definitions

The Fedora runlevels are defined for the Fedora system in /etc/inittab.

Note

Not all Linux distributions use the same runlevel configurations or runlevel definitions! For example, although Fedora uses runlevel 3 for a full, console-based multiuser mode, pre-7.1 versions of SUSE Linux defined this system state as runlevel 2. Red Hat, Fedora, and SUSE now use the same runlevels to conform to the Linux Standards Base, or LSB. As a system administrator, you should be aware of this issue, especially if you have devised any administrative scripts or tools that deal with system states.

Each runlevel tells the init command what services to start or stop. Although runlevels might all have custom definitions, Fedora has adopted some standards for runlevels:

• Runlevel 0 Known as "halt," this runlevel is used to shut down the system.

• Runlevel 1 This is a special runlevel, defined as "single," which boots Fedora to a root access shell prompt where only the root user may log in. Networking, X, and multiuser access are turned off. This is the maintenance or rescue mode. It allows the system administrator to perform work on the system, make backups, or repair configuration or other files.

• Runlevel 2 This runlevel dictates that Fedora be booted to a console, or text-based mode, with multiuser access.

• Runlevel 3 This runlevel is identical to runlevel 2, except that it also starts any networking services.

• Runlevel 4 This runlevel is undefined, and it can readily be configured to boot Fedora to a custom system state.

• Runlevel 5 This runlevel boots Fedora to a networking, multiuser state with an active X session. This is the most common runlevel for home users who want a graphical interface.

• Runlevel 6 This runlevel is used to reboot the system.

Runlevel 1 (also known as single-user mode or maintenance mode) is most commonly used to repair file systems and change the root password on a system when the password has been forgotten. Trespassers with physical access to the machine can also use runlevel 1 to access your system.

Caution

Never forget that uncontrolled physical access is virtually a guarantee of access to your data by an intruder.

Booting into the Default Runlevel

Entries in /etc/inittab use a field-based notation that determines the runlevelwhen to execute the process, whether or not the process is executed when booting, whether or not to wait for the process to complete, and when to execute the process during booting. The default choices are adequate and need be changed only in unique circumstances that the average user is not likely to encounter.

The value of the default entry, or the initdefault line in /etc/inittab, determines the particular system state that Fedora is in when the login prompt is finally presented. For example,

id:5:initdefault:

In this example, Fedora boots to runlevel 5, a network-enabled, multiuser mode with an active X session and a graphical login. The value 5 is forwarded to the script named rc under the /etc/rc.d directory. This script is used when booting or changing runlevels; it also acts as an interpreter when you boot Fedora in Interactive mode by pressing i during the boot.

After /etc/rc.d/rc.sysinit has finished, init uses the corresponding /etc/inittab enTRy that matches the designated default runlevel. Using the previous example, the line in /etc/inittab would then be

l5:5:wait:/etc/rc.d/rc 5

Under the /etc/rc.d directory is a series of directories that correspond to each runlevel:

# ls /etc/rc.d init.d  rc0.d  rc2.d  rc4.d  rc6.d    rc.sysinit rc      rc1.d  rc3.d  rc5.d  rc.local

Assuming that the value is 5, the rc script executes all the scripts under the /etc/rc.d/rc.5 directory and then launches the graphical login.

If Fedora is booted to runlevel 5, for example, scripts beginning with the letter K followed by scripts beginning with the letter S under the /etc/rc.d/rc5.d directory are then executed:

# ls /etc/rc.d/rc5.d/ K01yum         K20bootparamd      K28amd         K45named      K61ldap K74ypxfrd         S05kudzu       S24pcmcia      S85gpm   K05innd K20iscsi           K30sendmail   K46radvd      K65identd   K84bgpd S08ip6tables   S25netfs       S90crond K05saslauthd   K20netdump-server K34dhcrelay   K50netdump    K65kadmin   K84ospf6d         S08ipchains S26apmd        S90FreeWnn   K10psacct      K20nfs             K34yppasswdd K50snmpd      K65kprop    K84ospfd          S08iptables    S28autofs S90xfs  K10radiusd     K20rstatd          K35atalk      K50snmptrapd K65krb524   K84ripd           S10network     S40smartd      S92lisa K12canna       K20rusersd         K35dhcpd      K50tux        K65krb5kdc K84ripngd         S12syslog      S44acpid       S95anacron  K12mailman K20rwalld          K35smb        K50vsftpd     K70aep1000  K85zebra S13irqbalance  S55cups        S95atd  K12mysqld      K20rwhod K35vncserver  K54dovecot    K70bcm5820  K90isicom         S13portmap S55sshd        S97messagebus K15httpd       K20spamassassin    K35winbind K54pxe        K74ntpd     K91isdn           S14nfslock     S56rawdevices S97rhnsd K15postgresql  K24irda            K40mars-nwe   K55routed K74ups      K95firstboot      S17keytable    S56xinetd       S99local K16rarpd       K25squid           K45arpwatch   K61hpoj       K74ypserv S00microcode_ctl  S20random      S84privoxy     S99mdmonitor

These scripts are actually symbolic links to system service scripts under the /etc/rc.d/init.d directory (yours might look different, depending on whether you are working with a workstation or server installation and the services or software packages installed on your system):

# ls /etc/rc.d/init.d/ acpid     bgpd        firstboot  ip6tables   keytable    mars-nwe        nfs postgresql  ripd       smartd        vncserver  zebra  aep1000   bluetooth FreeWnn    ipchains    killall     mdmonitor       nfslock  privoxy ripngd     smb           vsftpd  amd       bootparamd  functions  iptables kprop       messagebus      nscd     psacct      routed     snmpd         winbind anacron   canna       gkrellmd   irda        krb524      microcode_ctl   ntpd pxe         rstatd     snmptrapd     xfs  apmd      cpqarrayd   gpm irqbalance  krb5kdc     mysqld          ospf6d   radiusd     rusersd spamassassin  xinetd  arpwatch  crond       halt       iscsi        kudzu named           ospfd    radvd       rwalld     squid          ypbind atalk     cups        hpoj       isdn        ldap         netdump          pand random      rwhod      sshd          yppasswdd  atd        dhcpd httpd      isicom      lisa        netdump-server  pcmcia    rarpd saslauthd  syslog        ypserv  autofs    dhcrelay    identd      kadmin lm_sensors  netfs           portmap  rawdevices  sendmail    tux ypxfrd  bcm5820   dovecot     innd       kdcrotate   mailman network         postfix  rhnsd       single     ups            yum

The rc5.d links are prefaced with a letter and number, such as K15 or S10. The (K) or (S) in these prefixes indicates whether a particular service should be killed (K) or started (S), and passes a value of stop or start to the appropriate /etc/rc.d/init.d script. The number in the prefix executes the specific /etc/rc.d/init.d script in a particular order. The symlinks have numbers to delineate the order in which they are started. Nothing is sacred about a specific number, but some services need to be running before others are started. You would not want your Fedora system to attempt, for example, to mount a remote Network File System (NFS) volume without first starting networking and NFS services.

After all the system services are started for our runlevel, init starts the graphical login (because we are in runlevel 5). The graphical login's definition appears toward the end of /etc/inittab and looks like this:

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

This example shows that the shell script named prefdm executes the proper X11 display manager when Fedora is booted to runlevel 5.

Booting to a Nondefault Runlevel with GRUB

After you select a default runlevel, that runlevel is selected every time you restart the system from a power-off state. There might come a time when you do not want to boot into that runlevel. You might want to enter the maintenance mode or start the system without an active X server and graphical login in order to modify or repair the X server or desktop manager. You have to follow several specific steps to boot to a nondefault runlevel if you use GRUB, the default boot loader for Fedora.

Note

If you have enabled a GRUB password, you must first press p, type your password, and then press Enter before using this boot method.

The GRUB boot loader passes arguments, or commands, to the kernel at boot time. These arguments are used, among other things, to tell GRUB where the kernel is located and also to pass specific parameters to the kernel, such as how much memory is available or how special hardware should be configured.

To override the default runlevel, you can add an additional kernel argument to GRUB as follows:

At the graphical boot screen, press e (for edit), scroll down to select the kernel, and press e again.

Press the spacebar, type single or 1 (Fedora allows S and s as well), and press Enter.

Finally, press b to boot, and you'll boot into runlevel 1 instead of the default runlevel listed in /etc/inittab.

Fedora includes several command-line and graphical system administration utilities you can use to start, stop, reorder, or restart various services in different runlevels. These commands (discussed later in this chapter) work by renaming, removing, or creating symbolic links from /etc/rc.d/init.d to /etc/rc.d/rc.* as appropriate. Many administrators use these commands to change the symbolic links to the scripts under each /etc/rc.d/rc* directory rather than do it by hand.

The locations of symbolic links can also be confusing. Red Hat (and now Fedora) has traditionally kept them in one place, and the Linux Standards Base (LSB) requires that they now be located elsewhere. Because other scripts reference these files and it would be difficult to change them all, Fedora places symbolic links in the places specified by the LSB.

As you might surmise, symbolic links are very powerful tools in the system administrator's toolbox.

Understanding init Scripts and the Final Stage of Initialization

Each /etc/rc.d/init.d script, or init script, contains logic that determines what to do when receiving a start or stop value. The logic might be a simple switch statement for execution, as in this example:

case "$1" in   start)         start         ;;   stop)         stop         ;;   restart)         restart         ;;   reload)         reload         ;;   status)         rhstatus         ;;   condrestart)         [ -f /var/lock/subsys/smb ] && restart || :         ;;   *)         echo $"Usage: $0 {start|stop|restart|status|condrestart}"         exit 1 esac

Although the scripts can be used to customize the way that the system runs from poweron, absent the replacement of the kernel, this script approach also means that the system does not have to be halted in total to start, stop, upgrade, or install new services.

Note that not all scripts use this approach, and that other messages might be passed to the service script, such as restart, reload, or status. Also, not all scripts respond to the same set of messages (with the exception of start and stop, which they all have to accept by convention) because each service might require special commands.

Tip

You can write your own init scripts using the existing scripts as examples. Sample scripts can also be found in /usr/share/doc/initscripts/sysvinitfiles, along with a brief tutorial written by Red Hat and a brief explanation of all the options available to use in init scripts.

After all the system scripts have been run, your system is configured and all the necessary system services have been started. If you are using a runlevel other than 5, the final act of the init process is to launch the user shellbash, tcsh, zsh, or any of the many command shells available. The shell launches and you see a login prompt on the screen.

Controlling Services at Boot with Administrative Tools

As the master control file for system startup, /etc/inittab and its corresponding system of symbolic links control system services. You can manage /etc/inittab and its symbolic links using these graphical and nongraphical administrative tools:

• chkconfig A small script that helps you configure system services.

• ntsysv A graphical interface for the chkconfig configuration script.

• system-config-services A full graphical services configuration client. This application is found in the System Services/Sever settings menu as the Services menu item.

The following sections explain how to use all these administrative tools to configure and manage services in Fedora.

Using the chkconfig Text-Based Command-Line Tool

Traditionally, the command-line tool chkconfig has been used to effect administration of the services and their associations in the different runlevels. chkconfig was a major improvement over the process of configuring the symbolic links by hand. It is an effective, text-based command-line tool that you can use to display, diagnose, or change the starting or stopping of system services (as available under /etc/rc.d/init.d) in each runlevel.

For example, to list all services that are turned on in runlevel 5, you can pipe the output of chkconfig through the grep command like this:

# /sbin/chkconfig --list | grep '5:on' | sort anacron         0:off   1:off   2:on    3:on   4:on   5:on   6:off apmd            0:off   1:off   2:on    3:on   4:on   5:on   6:off atd             0:off   1:off   2:off   3:on   4:on   5:on   6:off autofs          0:off   1:off   2:off   3:on   4:on   5:on   6:off canna           0:off   1:off   2:on    3:off  4:on   5:on   6:off crond           0:off   1:off   2:on    3:on   4:on   5:on   6:off

Not all the output is shown here, but as you can see, chkconfig can display the value of off or on for each service and each runlevel. The sample output shows only those services that are started in runlevel 5. The chkconfig command can be used to reassign start or stop values for each runlevel and each service. As an example, to alter the scripts to start power management (controlled by the apmd script under /etc/rc.d/init.d) when using Fedora during runlevel 5, use chkconfig like this:

# chkconfig --level 5 apmd on

You can then verify this action by again using grep on chkconfig's output like this:

# chkconfig --list | grep apmd apmd            0:off   1:off   2:on   3:on   4:on   5:on   6:off

The chkconfig command does not start or stop a service; instead, it alters the scripts that start or stop a service, or it can report on the status of a service. Affecting only the current runlevel by default, other runlevels can be modified by using the -levels option. You would use the ntsysv or service commands or run the daemons directly in order to actually start or stop services (as described later in this chapter). All these tools have useful man pages to refresh your memory of all the available options.

ntsysv is a graphical interface you can use to access chkconfig and use a graphical interface. ntsysv is an ncurses-based interface, meaning that it offers crude, block graphics and elements you can tab through and select by pressing the spacebar (see Figure 15.1).

Figure 15.1. The ntsysv utility only manages which services are started in the current runlevel. Use the --level option to modify other runlevels.

When you have the ntsysv application open, you can scroll through the list of services and toggle a service on or off by pressing the spacebar on the keyboard. When finished, use the Tab key to highlight the OK or Cancel button. Your changes are saved and used the next time Fedora is booted.

Note

ntsysv is simple to use and it's an excellent tool for a system without X, but it works for only the runlevel you are currently in. Use the --level option to modify other runlevels.

The Fedora tool setup is an ncurses-based menu for all the available ncurses-based command-line configuration tools (see Figure 15.2). It can be used to access ntsysv and all the other command-line configuration tools.

Figure 15.2. Use the setup command's System Services item to access the ntsysv command.

Using the GUI-Based Service Configuration Tool

Fedora's developers have added GUIs to many text-only, command-line-based system administration tools as Linux has matured. These tools provide an easier-to-use interface and don't require memorization or lookup of command-line options. Fedora provides its own Service Configuration tool for the control and administration of services (see Figure 15.3). You can access the GUI menu selection from the System Settings/Server Settings menu, and then select Services. The command-line name of this tool is system-config-services.

Figure 15.3. The new Service Configuration tool allows you to select runlevels to edit, displays all the available services, and provides an explanation of what the service does.

Running Services Through xinetd

The xinetd daemon is a replacement for inetd; it listens for requests for services on certain ports and starts those services as required. xinetd is called a super server because it controls other servers. Its purpose is to conserve resources by not running services when not needed. The xinetd daemon is more secure than the older inetd, offers better logging facilities than inetd, and can redirect service requests to another machine. It does not require the root user to start any services.

The configuration file for xinetd is found at /etc/xinetd.conf, configuration files for individual services are located in /etc/xinet.d/; the particulars of its format are covered in the man page for xinetd.conf, which also provides a sample file listing. Fedora provides the appropriate server RPM packages already configured to use xinetd if possible. If you are installing servers manually from source code, the included documentation describes the appropriate xinetd configuration. Services run under xinetd cannot be started and stopped in the same manner as the services run from scripts in /etc/rc.d/init.d; you must restart the xinetd service itself and let it control those services.

Here is a sample listing of the rsync file /etc/xinet.d/rsync:

# default: off # description: The rsync server is a good addition to an ftp server, as it \ #       allows crc checksumming etc. service rsync {         disable = yes         socket_type     = stream         wait            = no         user            = root         server          = /usr/bin/rsync         server_args     = --daemon         log_on_failure  += USERID }

The items are straightforward and vary from service to service. Although you can edit this by hand, it can be configured via the command line or graphical service configuration clients.

Changing Runlevels

After making changes to system services and runlevels, you can use the telinit command to change runlevels on-the-fly on a running Fedora system. Changing runlevels this way allows system administrators to alter selected parts of a running system to make changes to the services or to put changes into effect that have already been made (such as reassignment of network addresses for a networking interface).

For example, a system administrator can quickly change the system to maintenance or single-user mode by using the telinit command with its S option like this:

# telinit S

The telinit command uses the init command to change runlevels and shut down currently running services. The command then starts services for the specified runlevel, where in this example, the single-user runlevel is the same as runlevel 2. The init command can only be run from a console, not from an xterm running in an X session.

After booting to single-user mode, you can then return to multiuser mode without X, like this:

# telinit 3

If you have made changes to the system initialization table itself, /etc/inittab, use the telinit command's q command-line option to force init to re-examine the table.

Tip

Linux is full of shortcuts: If you exit the single-user shell by typing exit at the prompt, you go back to the default runlevel without worrying about using telinit.