encountered that fsck cannot simply repair, the boot process stops, and the system reboots in single-user mode. You then must run fsck manually, and repair the disk problems yourself. When you finish the repairs, exit the single-user shell. The system will then attempt to restart the interrupted boot process from where it left off. The initialization script mounts the /proc filesystem and, after the fsck completes, mounts the root filesystem as read-write. Recall that the root filesystem was initially mounted as read-only. The root must be remounted as read-write before the system can be used. The script also mounts other local filesystems listed in the /etc/fstab file. (The fstab file is described in Chapter 9, “File Sharing.”) The rc.sysinit script finishes up by loading the loadable kernel modules. Other initialization scripts may look different from Red Hat’s, but they perform very similar functions. The order may be different, but the major functions are the same: initialize the swap file, and check and mount the local filesystems. Runlevel Initialization After the system initialization script is run, init runs a script for the specific runlevel. On Red Hat, Mandrake, and Caldera systems, this is done by running a control script and passing it the runlevel number. The control script, /etc/rc.d/rc, then runs all of the scripts that are appropriate for the runlevel. It does this by running the scripts that are stored in the directory /etc/rcn.d, where n is the specified runlevel. For example, if the rc script is passed a 5, it runs the scripts found in the directory /etc/rc.d/rc5.d. A listing of that directory from a Red Hat system shows that there are lots of scripts: Listing 1.5: Runlevel Initialization Scripts $ 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 $ ls /etc/rc.d/rc3.d K03rhnsd K35smb K74ntpd S05kudzu S25netfs S85httpd K16rarpd K45arpwatch K74ypserv S06reconfig S26apmd S90crond K20nfs K45named K74ypxfrd S08ipchains S28autofs S90xfs K20rstatd K50snmpd K75gated S09isdn S40atd S95anacron K20rusersd K50tux K84bgpd S10network S55sshd S99linuxconf K20rwalld K55routed K84ospf6d S12syslog S56rawdevices S99local K20rwhod K61ldap K84ospfd S13portmap S56xinetd K28amd K65identd K84ripd S14nfslock S60lpd K34yppasswdd K73ypbind K84ripngd S17keytable S80sendmail K35dhcpd K74nscd K85zebra S20random S85gpm The scripts that begin with a K are used to kill processes when exiting a specific runlevel. In Listing 1.5, the K scripts are used when terminating runlevel 5. The scripts that start with an S are used when starting runlevel 5. None of the items in rc5.d, however, is really a startup script. They are logical links to the real scripts, which are located in the /etc/rc.d/init.d directory. For example, S80sendmail is linked to /etc/init.d/sendmail. This raises the question of why the scripts are executed from the directory rc5.d instead of directly from init.d, where they actual reside. The reasons are simple. The same scripts are needed for several different runlevels. Using logical links, the scripts can be stored in one place and still be accessed by every runlevel from the directory used by that runlevel. Additionally, the order in which the scripts are executed is controlled by the script name. The scripts are executed in alphabetical order, based on name. Thus, S10network is executed 30
Note: If you are looking for reliable and quality webspace company to host and run your servlet application check Actions servlet hosting services
September 2006
Sat 30 Sep 2006
Sat 30 Sep 2006
This line starts and when necessary, restarts the X application used for the X-based console logon required by runlevel 5. Every line in the inittab file handles some important task. However, the real heart of the inittab file consists of the seven lines that follow the comment “System initialization” near the beginning of the inittab file (refer to Listing 1.4.) They are the lines that invoke the startup scripts. The first of these is the si entry: si::sysinit:/etc/rc.d/rc.sysinit This entry tells init to initialize the system by running the boot script located at /etc/rc.d/rc.sysinit. This script, like all startup scripts, is an executable file that contains Linux shell commands. Notice that the entry shows the full path to the startup script. One of the most common complaints about different Linux distributions is that the key files are stored in different locations in the filesystem. Don’t worry about memorizing these differences just look in the /etc/inittab file. It tells you exactly where the startup scripts are located. The six lines that follow the si entry in inittab are used to invoke the startup scripts for each runlevel. Except for the runlevel involved, each line is identical: l5:5:wait:/etc/rc.d/rc 5 This line starts all of the processes and services needed to provide the full multiuser support defined by runlevel 5. The label is l5, which is symbolic of level 5. The runlevel is, of course, 5. init is directed to wait until the startup script terminates before going on to any other entries in the inittab file that relate to runlevel 5. init executes the script /etc/rc.d/rc, and passes that script the command-line argument 5. Startup Scripts Anything that can be run from a shell prompt can be stored in a file and run as a shell script. System administrators use this capability to automate all kinds of processes; Linux uses this capability to automate the startup of system services. Two main types of scripts are used: the system initialization script and the runlevel initialization script. System Initialization The system initialization script runs first. On a Red Hat system, this is a single script named /etc/ rc.d/rc.sysinit. Other Linux distributions might use a different filename, but all versions of Linux use script files to initialize the system. The rc.sysinit script performs many essential system initialization tasks, such as preparing the network and the filesystems for use. The rc.sysinit script begins the network initialization by reading the /etc/sysconfig/network file, which contains several network configuration values set during the initial installation. If the file is not found, networking is disabled. If it is found, the script assigns the system the hostname stored there. The initialization script performs many small but important tasks, such as setting the system clock, applying any keyboard maps, and starting USB and PnP support. The bulk of the script, however, is used to prepare the filesystem for use. The script activates the swap file, which is necessary before the swap space is used. The rc.sysinit script also runs the filesystem check, using the fsck command to check the structure and integrity of the Linux filesystems. If a filesystem error is 29
Note: If you are looking for reliable and quality webspace company to host and run your servlet application check Actions servlet hosting services
Sat 30 Sep 2006
sysinit Runs before any boot or bootwait processes. wait Runs the process upon entering the run mode, and init waits for the process to complete. The last field in an inittab entry is the process field. It contains the process that init executes. The process appears in the exact format that is used to execute the process from the command line. Therefore, the process field starts with the name of the process that is to be executed, and follows it with the arguments that will be passed to that process. For example, /sbin/shutdown t3 r now, which is the process executed when Ctrl+Alt+Del is pressed, is the same command that could be typed at the shell prompt to reboot the system. Special-Purpose Entries Using what you have just learned about the syntax of the inittab file, take a closer look at the sample in Listing 1.4. You can ignore most of the file; more than half of it consists of comments. Many of the other lines are entries that are used only for special functions: The id entry defines the default runlevel, which is usually 3 for a text console or 5 for an X console. The ud entry calls the /sbin/update process, which cleans up the I/O buffers before disk I/ O starts in order to protect the integrity of the disks. The pf, pr, and ca entries are invoked only by special interrupts. Warning Some administrators are tempted to change the ca entry to eliminate the ability to reboot the system with the three-finger salute. This is not a bad idea for server systems, but don’t do it for desktop systems. Users need to have a method to force a graceful shutdown when things go wrong. If it is disabled, the user might resort to the power switch, which can result in lost data and other disk troubles. Six of the lines in the inittab file start and when necessary, restart the getty processes that provide virtual terminal services. One example from Listing 1.4 explains them all: 3:2345:respawn:/sbin/mingetty tty3 The label field contains a 3, which is the numeric suffix of the device, tty3, to which the process is attached. This getty is started for runlevels 2, 3, 4, and 5. When the process terminates (for example, when a user terminates the connection to the device), the process is immediately restarted by init. The pathname of the process that is to be started is /sbin/mingetty. Red Hat uses mingetty, which is a minimal version of getty that is specifically designed for virtual terminal support. On a Caldera 2.2 system, the pathname would be /sbin/getty with the VC command-line option, which tells getty that it is servicing a virtual terminal. The result, however, would be the same: to start a virtual terminal service process for tty3. Every runlevel that accepts terminal input uses getty. Runlevel 5 has one additional entry in the inittab file to start an X terminal: x:5:respawn:/etc/X11/prefdm -nodaemon 28
Note: If you are looking for reliable and quality webspace company to host and run your servlet application check Actions servlet hosting services
Sat 30 Sep 2006
terse and somewhat arcane. An inittab entry has this general format: label:runlevel:action:process The label is a one- to four-character tag that identifies the entry. Some systems support only two-character labels. For this reason, most people limit all labels to two characters. The labels can be any arbitrary character string, but in practice, certain labels are commonly used. The label for a getty or other login process is usually the numeric suffix of the tty to which the process is attached. Other labels used in the Red Hat Linux distribution are id for the line that defines the default runlevel used by init si for the system initialization process ln where n is a number from 1 to 6 that indicates the runlevel being initialized by this process ud for the update process ca for the process run when Ctrl+Alt+Del is pressed pf for the process run when the UPS indicates a power failure pr for the process run when power is restored by the UPS before the system is fully shut down x for the process that turns the system into an X terminal The runlevel field indicates the runlevels to which the entry applies. For example, if the field contains a 3, the process identified by the entry must be run for the system to initialize runlevel 3. More than one runlevel can be specified, as illustrated in the sample file by the pr entry. Entries that have an empty runlevel field are not involved in initializing specific runlevels. For example, an entry that is invoked by a special event, such as the three-finger salute (Ctrl+Alt+Del), does not have a value in the runlevel field. The action field defines the conditions under which the process is run. Table 1.1 lists all of the valid action values and the meaning of each one. Table 1.1: Valid Action Values Action Meaning Boot Runs when the system boots. Ignores runlevel. Bootwait Runs when the system boots, and init waits for the process to complete. Runlevels are ignored. Ctrlaltdel Runs when Ctrl+Alt+Del is pressed, which passes the SIGINT signal to init. Runlevels are ignored. Initdefault Doesn’t execute a process. It sets the default runlevel. Kbrequest Runs when init receives a signal from the keyboard. This requires that a key combination be mapped to KeyBoardSignal. Off Disables the entry so the process is not run. Once Runs one time for every runlevel. Ondemand Runs when the system enters one of the special runlevels A, B, or C. Powerfail Runs when init receives the SIGPWR signal. Powerokwait Runs when init receives the SIGPWR signal and the file /etc/ powerstatus contains the word OK. Powerwait Runs when init receives the SIGPWR signal, and init waits for the process to complete. Respawn Restarts the process whenever it terminates. 27
Note: If you are looking for inexpensive but high quality provider to host and run your jsp application check Astra jsp hosting services
Sat 30 Sep 2006
ca::ctrlaltdel:/sbin/shutdown -t3 -r now # When our UPS tells us power has failed, schedule a shutdown for 2 minutes. pf::powerfail:/sbin/shutdown -f -h +2 “Power Failure; System Shutting Down” # If power was restored before the shutdown, 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 # xdm is now a separate service x:5:respawn:/etc/X11/prefdm -nodaemon Note The comments in this sample file were edited slightly to better fit on a book page. They are a reduced version of the actual comments from the Red Hat inittab file. Understanding Runlevels To understand the init process and the inittab file, you need to understand runlevels, which are used to indicate the state of the system when the init process is complete. There is nothing inherent in the system hardware that recognizes runlevels; they are purely a software construct. init and inittab are the only reasons why the runlevels affect the state of the system. Because of this, the way runlevels are used varies from distribution to distribution. This section uses Red Hat Linux as an example. The Linux startup process is very similar to the startup process used by System V Unix. It is more complex than the initialization on a BSD Unix system, but it is also more flexible. Like System V, Linux defines several runlevels that run the full gamut of possible system states from not-running (halted) to running multiple processes for multiple users. The comments at the beginning of the sample inittab file describe the runlevels: Runlevel 0 causes init to shut down all running processes and halt the system. Runlevel 1 is used to put the system in single-user mode. Single-user mode is used by the system administrator to perform maintenance that cannot be done when users are logged in. This runlevel may also be indicated by the letter S instead of the number 1. Runlevel 2 is a special multiuser mode that supports multiple users but does not support file sharing. Runlevel 3 is used to provide full multiuser support with the full range of services. It is the default mode used on servers that use the “text only” console logon. Runlevel 4 is unused by the system. You can design your own system state and implement it through runlevel 4. Runlevel 5 initializes the system as a dedicated X Windows terminal. This runlevel is widely used as an alternative for systems configured to launch an X desktop environment at startup. In fact, runlevel 5 is the default runlevel for most Red Hat systems because most systems are desktop clients that use an X Windows console logon. Runlevel 6 causes init to shut down all running processes and reboot the system. All of the lines in the inittab file that begin with a sharp sign (#) are comments. A liberal dose of comments is needed to interpret the file because the syntax of actual inittab configuration lines is 26
Note: If you are looking for inexpensive but high quality provider to host and run your jsp application check Astra jsp hosting services
Sat 30 Sep 2006
NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 1024 buckets, 8Kbytes TCP: Hash tables configured (established 16384 bind 16384) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Reading the kernel messages helps you understand what occurs when the system starts up. Don’t read these messages word for word too many details will just bog you down. What you should do is look at the messages to gain a sense of how the system works. Of course, there are slight variations among the messages displayed on various systems, but the messages give you a very good idea of what is going on as the kernel initializes the hardware. After the kernel concludes its portion of the boot process, the kernel starts the init program, which controls the rest of the startup. Loading Linux Services The init Process The init process, which is process number one, is the mother of all processes. After the kernel initializes all of the devices, the init program runs and starts all of the software. The init program is configured by the /etc/inittab file. Listing 1.4 shows the inittab file that comes with Red Hat 7.2: Listing 1.4: The inittab File # # inittab This file describes how the INIT process should set up # the system in a certain run-level. # # Author: Miquel van Smoorenburg,
Note: If you are looking for inexpensive but high quality provider to host and run your jsp application check Astra jsp hosting services
Sat 30 Sep 2006
modules for device drivers. If your Ethernet card is not recognized during the boot, it may be that its module is not loaded. The first step is to check the module’s configuration. Note See the “Loadable Modules” section later in this chapter for information about managing modules and for specific examples of loadable modules used for Ethernet device drivers. This section has barely touched upon the very large number of arguments that can be entered at the boot prompt. See the “BootPrompt-HOWTO” document, by Paul Grotmaker, for the details of all of them. Most Linux systems include the HOWTO documents in /usr/doc. Hardware Device Driver Initialization When the system boots, several things happen. You have already seen the part that LILO and GRUB play in loading the operating system, but that is only the beginning. These loaders start the Linux kernel running, and then things really begin to happen. The kernel is the heart of Linux. It loads into memory and initializes the various hardware device drivers. Most of the possible boot prompt arguments are intended to help the kernel initialize hardware, and the messages the kernel displays during startup help you determine what hardware is installed in the system and whether it is properly initialized. Use the dmesg command to display the kernel startup messages; combine it with the less command or with grep to examine the startup messages more effectively. less allows you to scroll through the messages, one screenful at a time; grep permits you to search for something specific in the dmesg output. For example, combine dmesg and grep to locate kernel messages relating to the initialization of the Ethernet device eth0: $ dmesg | grep eth0 loading device ‘eth0′… eth0: SMC Ultra at 0×340, 00 00 C0 4F 3E DD, IRQ 10 memory 0xc8000-0xcbfff. This message clearly shows the type of Ethernet adapter used (SMC Ultra) and the Ethernet MAC address assigned to the adapter (00 00 C0 4F 3E DD). Additionally, because the SMC Ultra is an ISA bus adapter, the bus interrupt (IRQ 10), the adapter memory address (0xc8000-0xcbfff), and the I/O port address (0×340) are shown. All of this information is useful for debugging a hardware configuration problem. Most systems use Ethernet for all network communications, although some use other devices, such as serial ports for this purpose. When the kernel initializes the serial ports, it displays the device name, I/O port address, and IRQ of each serial port. It also displays the model of Universal Asynchronous Receiver Transmitter (UART) that is used for the serial interface. Old systems used 8250 UARTs, which are inadequate for use with modems and a problem for systems that need to run PPP. As this example shows, current systems use the faster 16550A UARTs: ttyS00 at 0×03f8 (irq = 4) is a 16550A ttyS02 at 0×03e8 (irq = 4) is a 16550A Also of interest for a network server are the kernel components of TCP/IP. These components include the fundamental protocols, such as IP (Internet Protocol), and the network sockets interface. Sockets is an application protocol interface developed at Berkeley for BSD Unix. It provides a standard method for programs to talk to the network. The TCP/IP initialization messages from a Red Hat 7.2 system are 24
Note: If you are looking for high quality webhost to host and run your jsp application check Vision jsp hosting services
Sat 30 Sep 2006
Handling undetected hardware is the second reason for entering data at the boot prompt, and it is the most common reason for doing so during the initial installation. Sometimes, the system has trouble detecting hardware or properly detecting the hardware’s configuration. In those cases, the system needs your input at the boot prompt to properly handle the unknown hardware. A large number of the boot input statements pass parameters to device driver modules. For example, there are about 20 different SCSI host adapter device drivers that accept boot parameters. In most cases, the system detects the SCSI adapter configuration without a problem. But if it doesn’t, booting the system may be impossible. An example of passing kernel parameters to Linux to identify an undetected SCSI adapter device is boot: linux aha152x=0×340,11,7 All hardware parameters begin with a driver name. In this case, it is the aha152x driver for Adaptec 1520 series adapters. The data after the equal sign is the information passed to the driver. In this case, it is the I/O port address, the IRQ, and the SCSI ID. Another boot argument that is directly related to the configuration of device drivers is the reserve argument. reserve defines an area of I/O port address memory that is protected from auto-probing. To determine the configuration of their devices, most device drivers probe those regions of memory that can be legitimately used for their devices. For example, the 3COM EtherLink III Ethernet card is configured to use I/O port address 0×300 by default, but it can be configured to use any of 21 different address settings from 0×200 to 0×3e0. If the 3c509 driver did not find the adapter installed at address 0×300, it could legitimately search all 21 base address regions. Normally, this is not a problem. On occasion, however, auto-probing can return the wrong configuration values. In extreme cases, poorly designed adapters can even hang the system when they are probed. I have never personally seen an adapter hang the system, but some years ago I had an Ethernet card that returned the wrong configuration. In that case, I combined the reserve argument with device driver input, as in this example: boot: linux reserve=0×210,16 ether=10,0×210,eth0 This boot input prevents device drivers from probing the 16 bytes starting at memory address 0×210. The second argument on this line passes parameters to the ether device driver. It tells that driver that the Ethernet adapter uses interrupt 10 and I/O port address 0×210. This specific adapter will be known as device eth0, which is the name of the first Ethernet device. Of course, you’ll want to use the Ethernet adapter every time the system boots. Once you’re sure this boot input fixes the Ethernet problem, store it as a kernel-specific option in the lilo.conf file. For example: image = /boot/vmlinuz-2.2.5-15 label = linux root = /dev/hda3 read-only append = “reserve=0×210,16 ether=10,0×210,eth0″ The ether argument is also used to force the system to locate additional Ethernet adapters. Suppose that the system detects only one Ethernet adapter, and you have two Ethernet devices installed: eth0 and eth1. Use this boot input to force the system to probe for the second device: ether=0,0,eth1 Old Ethernet cards are a major reason for boot prompt input. If you have an old card and experience a problem, read the Ethernet-HOWTO for configuration advice on your specific card. New PCI Ethernet cards do not usually require boot input. Most current Ethernet cards use loadable 23
Note: If you are looking for high quality webhost to host and run your jsp application check Vision jsp hosting services
Sat 30 Sep 2006
select an optional menu item, or interrupt the boot process. Interrupt the boot by pressing the Escape key. If a password is defined in the grub.conf file, press P, and enter the GRUB password. Then, press C for command mode, and a command line prompt appears. This is the boot prompt that allows arguments to be sent to the kernel using the kernel command interactively. The format of the kernel command is kernel file arguments where kernel is the command, file is the name of the file that contains the Linux kernel, and arguments are any optional arguments you wish to pass to the kernel. In the preceding kernel command example, ro root=/dev/hda3 are arguments that change the default boot behavior so that the root filesystem is mounted read-only. The possible arguments depend on the kernel, not on whether GRUB or LILO is used to control the boot process. Any of the kernel arguments described in this section can be sent to the kernel in this manner on a system that uses GRUB. The LILO boot prompt is different, but the function is the same. When the system is booted by LILO, the string boot: is displayed as the boot prompt. The operator can boot any operating system defined in the lilo.conf file by entering its name at the prompt (for example, linux, or dos). Arguments are passed to the selected operating system by placing them on the command line after the operating system name. An example of passing kernel parameters on a system booted by LILO is boot: linux panic=60 In this example, boot: is the prompt, linux is the kernel name, and panic=60 is the parameter passed to that kernel. The keyword linux is the label assigned to the Linux kernel in the LILO configuration. Use the label to tell LILO which kernel should receive the parameter. The panic argument changes the boot behavior after a system crash. It is possible for the Linux kernel to crash from an internal error, called a kernel panic. If the system crashes from a kernel panic, it does not automatically reboot it stops at the boot prompt waiting for instructions. Normally, this is a good idea. The exception is an unattended server. If you have a system that does not have an operator in attendance and that remote users rely on, it might be better to have it try an automatic reboot after it crashes. The example shown previously tells the system to wait 60 seconds and then reboot. Note This might surprise Windows administrators, but I have never had a Linux system crash. In fact, I had one specialized system (collecting network measurement data, and providing Web access to that data) that ran continuously for more than a year without a single problem. In a normal boot process, the kernel starts the /sbin/init program. Using the init argument, it is possible to tell the kernel to start another process instead of /sbin/init. For example, init=/bin/sh causes the system to run the shell program, which then can be used to repair the system if the / sbin/init program is corrupted. Booting directly to the shell looks very much like booting to single-user mode with the single argument, but there are differences. init=/bin/sh does not rely on the init program. single, on the other hand, is passed directly to init so that init can perform selected initialization procedures before placing the system into single-user mode. In both of these cases, the person who boots the computer is given password-free access to the shell unless password and restrict are defined in the lilo.conf file, as described in the previous section. 22
Note: If you are looking for high quality webhost to host and run your jsp application check Vision jsp hosting services
Fri 29 Sep 2006
The following example includes restricted password protection for booting the Linux kernel. The example is based on the lilo.conf file you saw earlier, with a few lines removed that contain default values to show that you can remove those lines and still boot without a problem. Listing 1.3 uses cat to list the new configuration file and lilo to process it. Listing 1.3: Adding Password Protection to LILO [root]# cat lilo.conf # global section boot=/dev/hda3 prompt timeout=50 message=/boot/message default=linux # the Linux boot image image=/boot/vmlinuz-2.4.2-2 label=linux read-only root=/dev/hda3 password=Wats?Watt? restricted # additional boot images other=/dev/hda1 optional label=dos [root]# lilo Added linux * Added dos After running /sbin/lilo, reboot. Note that you don’t have to enter the password at the boot prompt because the configuration includes the restrict option. However, if you attempt to boot the system and provide optional input at the boot prompt, you will be asked for the password. The Linux Boot Prompt The LILO and GRUB processes are modified through their configuration files. The kernel boot process is modified through input to the boot prompt. As with the LILO append option and the GRUB kernel command, the boot prompt is used to pass parameters to the kernel. The difference, however, is that the boot prompt is used to manually enter kernel parameters, whereas the append and kernel commands are used to automate the process when the same parameters must be passed to the kernel for every boot. Use the boot prompt for special situations, such as repairing a system or getting an unruly piece of equipment running; or to debug input before it is stored in the lilo.conf or grub.conf file. You rarely need to pass parameters to the kernel through the boot prompt. When you do, it is either to change the boot process or to help the system handle a piece of unknown hardware. The kernel command from the grub.conf file shown in Listing 1.1 is an example of using boot input to change the boot process: kernel /boot/vmlinuz-2.4.7-10 ro root=/dev/hda3 This line comes from the grub.conf file, but it also can be entered interactively during the boot process. When the GRUB menu is displayed at boot time, the operator is given 10 seconds to 21
Note: If you are looking for cheap and inexpensive provider to host and run your tomcat application check Actions tomcat hosting services