Running Services at Bootup

Although most people consider a computer to be either on or off, in Ubuntu there are a number of states in between. Known as runlevels, they control what system services are started upon 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 Ubuntu. 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 Ubuntu 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 Ubuntu) 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 BIOS's allow considerable flexibility in choosing the device used for booting the system.

Note

If the BIOS detects a hardware problem, the boot process will fail and the BIOS will generate 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. 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.

Ubuntu can use a variety of boot loaders, including GRUB (the default for Ubuntu), LILO (a long-time standard but not available with Ubuntu), 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 will expedite 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. Linux 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.

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 have 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 will be printed to the screen, giving you the status of each command. 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.

If the boot process were halted at this point, the system would just sit idle and the screen would be blank. In order 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

The init command uses the Linux system initialization table found in /etc/inittab to boot Ubuntu to a specific system state. The state of the system is commonly referred to as its runlevel.

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.

You will use runlevels to manage the system services running on your computer. All these special files and scripts are set up during your installation of Ubuntu Linux, and they receive their initial values based on your choices during the installationas described in Chapter 3, "Installing Ubuntu," 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 Ubuntu runlevels are defined for the Ubuntu system in /etc/inittab.

Each runlevel tells the init command what services to start or stop. Although runlevels might all have custom definitions, Ubuntu 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 Ubuntu to a root access shell prompt where only the root user may log in. It has networking, X, and multi-user access 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 Ubuntu be booted to a console, or textbased mode, with multi-user 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 Ubuntu to a custom system state.

• Runlevel 5 This runlevel boots Ubuntu to a networking, multi-user 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 only need be changed 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 in which Ubuntu will be when the login prompt is finally presented. For example,

id:5:initdefault:

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

At this point, 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 5

Under the /etc directory are a series of directories that correspond to each runlevel:

rc0.d  rc2.d  rc4.d  rc6.d rc1.d  rc3.d  rc5.d  rcS.d 

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

If Ubuntu is booted to runlevel 1, for example, scripts beginning with the letter K followed by scripts beginning with the letter S under the /etc/rc1.d directory are then executed:

# ls /etc/rc1.d/ K01gdm         K19hplip      K20laptop-mode    K20vsftpd    K80slapd K01usplash         K20acpi-support      K20makedev    k21acpid    K86ppp ...etc... K19cupsys    K20inetutils-inetd    K20ssh    K74-bluez-utils    S20single These scripts are actually symbolic links to system service scripts under the /etc/init.d directory. 

The rc1.d links are prefaced with a letter and number, such as K15 or S10. The (K) or (S) in these prefixes indicate whether or not a particular service should be killed (K) or started (S) and pass a value of stop or start to the appropriate /etc/init.d script. The number in the prefix executes the specific /etc/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 Ubuntu system to attempt, for example, to mount a remote Network File System (NFS) volume without first starting networking and NFS services.

Booting to a Non-Default Runlevel with GRUB

After you select a default runlevel, that runlevel will be 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'll need to follow several specific steps to boot to a non-default runlevel if you use the default boot loader for Ubuntu, GRUB.

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 (Ubuntu 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.

Understanding init Scripts and the Final Stage of Initialization

Each /etc/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 will use this approach, and that other messages might be passed to the service script, such as restart, reload, or status. Also, not all scripts will 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.

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 the Services administrative tool located under the System > Administration menu:

In the Services dialog (shown in Figure 15.1) Ubuntu lists all the services that you can have automatically start at boot time. They are usually all enabled by default, but you can simply uncheck the ones you don't want and click OK.

Figure 15.1. You can enable and disable Ubuntu's boot-up services by toggling the checkboxes in the Services dialog.

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 Ubuntu system. Changing runlevels this way allows system administrators to alter selected parts of a running system in order 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 multi-user 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 will go back to the default runlevel without worrying about using telinit.

Troubleshooting Runlevel Problems

Reordering or changing system services during a particular runlevel is rarely necessary when using Ubuntu unless some disaster occurs. But system administrators should have a basic understanding of how Linux boots and how services are controlled in order to perform troubleshooting or to diagnose problems. By using additional utilities such as the dmesg | less command to read kernel output after booting or by examining system logging with cat /var/log/messages | less, it is possible to gain a bit more detail about what is going on when faced with troublesome drivers or service failure.

To better understand how to troubleshoot service problems in Ubuntu, look at the diagnosis and resolution of a typical service-related issue.

In this example, X will not start: You don't see a desktop displayed, nor does the computer seem to respond to keyboard input. The X server might either be hung in a loop, repeatedly failing, or might exit to a shell prompt with or without an error message.

The X server only attempts to restart itself in runlevel 5, so to determine whether the X server is hung in a loop, try switching to runlevel 3.

Tip

If you are working on a multi-user system and might inadvertently interrupt the work of other users, ask them to save their current work; then change to a safer runlevel, such as single user mode.

Change to runlevel 3 by switching to another virtual console with Ctrl+Alt+F2, logging in as root, and running the command telinit 3. This switch to runlevel 3 will stop the X server from attempting to restart itself.

Now you can easily examine the error and attempt to fix it.

First, try to start the X server "naked" (without also launching the window manager). If you are successful, you will get a gray screen with a large X in the middle. If so, kill X with the Ctrl+Alt+Backspace key combination, and look at your window manager configuration. (This configuration varies according to which window manager you have chosen.)

Let us assume that X won't run "naked." If we look at the log file for Xorg (it's clearly identified in the /var/log directory), we'll pay attention to any line that begins with (EE), the special error code. We can also examine the error log file, .xsessions-error, in our home directory if such a file exists.

If we find an error line, the cause of the error might or might not be apparent to us. The nice thing about the Linux community is that it is very unlikely that you are the first person to experience that error. Enter the error message (or better, a unique part of it) into http://www.google.com/linux and discover what others have had to say about the problem. You might need to adjust your search to yield usable results, but that level of detail is beyond the scope of this chapter. Make adjustments and retest as before until you achieve success.

Fix the X configuration and start X with startx. Repeat as necessary.

Caution

Before making any changes to any configuration file, always make a backup copy of the original, unmodified file. Our practice is to append the extension .original to the copy because that is a unique and unambiguous identifier.

If you need to restore the original configuration file, do not rename it, but copy it back to its original name.