Understanding run-level scripts in Fedora 11 and RHEL

System Startup and Shutdown

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.

During system startup, a series of scripts are run to start the services that you need. These include scripts to start network interfaces, mount directories, and monitor your system. Most of these scripts are run from subdirectories of /etc/rc.d. The program that starts most of these services up when you boot and stops them when you shut down is the /etc/rc.d/rc script. The following sections describe run-level scripts and what you can do with them.

Starting run-level scripts

As previously mentioned, the /etc/rc.d/rc script is integral to the concept of run levels. Any change of run level causes the script to be executed, with the new run level as an argument. Here's a quick run-down of what the /etc/rc.d/rc script does:

• Checks that run-level scripts are correct -- Therc script checks to find each run-level script that exists and excludes those that represent backup scripts left by rpm updates.
• Determines current and previous run levels -- Determines the current and previous run levels to know which run-level scripts to stop (previous level) and start (current level).
• Decides whether to enter interactive startup -- If the confirm option is passed to the boot loader at boot time, all server processes must be confirmed at the system console before starting.
• Kills and starts run-level scripts -- Stops run-level scripts from the previous level, then starts run-level scripts from the current level.

In Fedora and RHEL, most of the services that are provided to users and computers on the network are started from run-level scripts.

Understanding run-level scripts

A software package that has a service to start at boot time (or when the system changes run levels) can add a script to the /etc/init.d directory. That script can then be linked to an appropriate run-level directory and run with either the start or stop option (to start or stop the service).

Table 12-5 lists many of the typical run-level scripts that are found in /etc/init.d and explains their function. Depending on the Fedora or RHEL software packages you installed on your system, you may have dozens more run-level scripts than you see here. (Later, I describe how these files are linked into particular run-level directories.)

Each script representing a service that you want to start or stop is linked to a file in each of the run-level directories. For each run level, a script beginning with K stops the service, whereas a script beginning with S starts the service.

The two digits following the K or S in the filename provide a mechanism to select the priority in which the programs are run. For example, S12syslog is run before S90crond. However, the file S110my_daemon is run before S85gpm, even though you can readily see that 85 is less than 110. This is because the ASCII collating sequence orders the files, which simply means that one positional character is compared to another. Therefore, a script beginning with the characters S110 is executed between S10network and S15netfs in run level 3.

All of the programs within the /etc/rcX.d directories (where X is replaced by a run-level number) are symbolic links, usually to a file in /etc/init.d. The /etc/rcX.d directories include the following:

• /etc/rc0.d: Run level 0 directory
• /etc/rc1.d: Run level 1 directory
• /etc/rc2.d: Run level 2 directory
• /etc/rc3.d: Run level 3 directory
• /etc/rc4.d: Run level 4 directory
• /etc/rc5.d: Run level 5 directory
• /etc/rc6.d: Run level 6 directory

In this manner, /etc/rc0.d/K05atd, /etc/rc1.d/K05atd, /etc/rc2.d/K05atd, /etc/rc3.d/S95atd, /etc/rc4.d/S95atd, /etc/rc5.d/S95atd, and /etc/rc6.d/K05atd are all symbolic links to /etc/init.d/atd. Using this simple, consistent mechanism, you can customize which programs are started at boot time.

Table 12-5: Run-Level Scripts Contained in /etc/init.d

Understanding what startup scripts do

Despite all the complicated rcXs, Ss, and Ks, the form of each startup script is really quite simple. Because they are in plain text, you can just open one with a text editor to take a look at what it does. For the most part, a run-level script can be run with a start option, a stop option, and possibly a restart option. For example, the following lines are part of the contents of the smb script that defines what happens when the script is run with different options to start or stop the Samba file and print service:

#!/bin/sh
#
# chkconfig: - 91 35
# description: Starts and stops the Samba smbd daemon \
# used to provide SMB network services.

.

.

.

start() {
KIND="SMB"
echo -n $"Starting $KIND services: "
daemon smbd $SMBDOPTIONS
RETVAL=$?
echo

[ $RETVAL -eq 0 -a $RETVAL2 -eq 0 ] && touch /var/lock/subsys/smb || \
RETVAL=1
return $RETVAL

}

stop() {
KIND="SMB"
echo -n $"Shutting down $KIND services: "
killproc smbd

RETVAL=$?
echo

[ $RETVAL -eq 0 -a $RETVAL2 -eq 0 ] && rm -f /var/lock/subsys/smb
return $RETVAL

}

restart() {
stop
start

}

.

.

.

To illustrate the essence of what this script does, I skipped some of the beginning and end of the script (where it checked if the network was up and running and set some values). Here are the actions smb takes when it is run with start or stop:

• start -- This part of the script starts the smbd server when the script is run with the start option.
• stop -- When run with the stop option, the/etc/init.d/smb script stops thesmbd server.

The restart option runs the script with a stop option followed by a start option. If you want to start the smb service yourself, type the following command (as root user):

# service smb start
Starting SMB services: [ OK ]

To stop the service, type the following command:

# service smb stop
Shutting down SMB services: [ OK ]

The smb run-level script is different from other run-level scripts in that it supports several other options than start and stop. For example, this script has options (not shown in the example) that allow you to reload the smb.conf configuration file (reload) and check the status of the service (status).

Changing run-level script behavior

Modifying the startup behavior of any such script merely involves opening the file in a text editor.

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.

For example, the atd daemon queues jobs submitted from the at and batch commands. Jobs submitted via batch are executed only if the system load is not above a particular value, which can be set with a command-line option to the atd command.

The default limiting load factor value of 0.8 is based on the assumption that a single-processor machine with less than 80 percent CPU utilization could handle the additional load of the batch job. However, if you were to add another CPU to your machine, 0.8 would only represent 40 percent of the computer's processing power. So you could safely raise that limit without impacting overall system performance.

You can change the limiting load factor from 0.8 to 1.6 to accommodate the increased processing capacity. To do this, simply modify the following line (in the start section) of the /etc/init.d/atd script:

daemon /usr/sbin/atd

Replace it with this line, using the -1 argument to specify the new minimum system load value:

daemon /usr/sbin/atd -l 1.6

After saving the file and exiting the editor, you can reboot the machine or just run any of the following three commands to begin using the new batch threshold value:

# service atd reload
# service atd restart
# service atd stop ; service atd start

If you are uncomfortable editing startup scripts and you simply want to add options to the daemon process run by the script, there may be a way of entering these changes without editing the startup script directly. Check the /etc/sysconfig directory and see if there is a file by the same name as the script you want to modify. If there is, that file probably provides values that you can set to pass options to the startup script. Sysconfig files exist for apmd, arpwatch, dhcpd, ntpd, samba, squid, and others.

Reorganizing or removing run-level scripts

There are several ways to deal with removing programs from the system startup directories, adding them to particular run levels, or changing when they are executed. From a Terminal window, you can use the chkconfig command. From a GUI, use the Service Configuration window.

CAUTION: You should never remove the run-level file from the/etc/init.d directory. Because no scripts are run from the /etc/init.d directory automatically, it is okay to keep them there. Scripts in /etc/init.d are only accessed as links from the /etc/rcX.d directories. Keep scripts in the init.d directory so you can add them later by re-linking them to the appropriate run-level directory.

To reorganize or remove run-level scripts from the GUI, use the Service Configuration window. Either select System → Administration → Services or log in as root user and type the following command in a Terminal window:

# system-config-services &

Figure 12-1 shows an example of the Service Configuration window.

The Service Configuration window enables you to reconfigure services for run levels 2, 3, 4, and 5. Icons next to each service indicate whether the service is currently enabled (green) or disabled (red) for the current run level and whether or not the service is currently running. Select a service to see a description of that service. Here is what you can do from this window:

• Enable -- With a service selected, click the Enable button to enable the service to start when you start your computer (run levels 2, 3, 4, and 5).
• Disable -- With a service selected, click Disable to not have the service not start when you boot your computer (or otherwise enter run levels 2, 3, 4, or 5).
• Customize -- With a service selected, click Customize and select the run levels at which you want the service to start.
• Start -- Click a service on the list. Select Start to request the service to immediately start.

Figure 12-1: Reorganize, add, and remove run-level scripts from the Service Configuration window.

Some administrators prefer text-based commands for managing run-level scripts and for managing other system services that start automatically. The chkconfig command can be used to list whether services that run-level scripts start, as well as services the xinetd daemon starts, are on or off. To see a list of all system services, with indications that they are on or off, type the following:

# chkconfig --list | less

You can then page through the list to see those services. If you want to view the status of an individual service, you can add the service at the end of the list option. For example, to see whether the nfs service starts in each run level, type the following:

# chkconfig --list nfs
nfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off

This example shows that the nfs service is set to be on for run levels 3, 4, and 5, but that it is set to off for run levels 0, 1, 2, and 6.

Another tool that can be run from the shell to change which services start and do not start at various levels is the ntsysv command. Type the following as root user from the shell:

# ntsysv

A screen appears with a list of available services. Use the up and down arrow keys to locate the service you want. With the cursor on a service, press the Spacebar to toggle the service on or off. Press the Tab key to highlight the OK button, and press the Spacebar to save the change and exit. The ntsysv tool only changes services for the current run level. You can run ntsysv with the --level # option, where # is replaced by the run level for which you want to change services.

Adding run-level scripts

Suppose you want to create and configure your own run-level script. For example, after installing the binaries for the fictitious my_daemon program, it needs to be configured to start up in run levels 3, 4, and 5, and terminated in any other run level. You can add the script to the /etc/init.d directory, then use the chkconfig command to configure it.

To use chkconfig, ensure that the following lines are included in the /etc/init.d/my_daemon script:

# chkconfig: 345 82 28
# description: Does something pretty cool - you really
# have to see it to believe it!
# processname: my_daemon

With those lines in place, simply run the following command:

# chkconfig --add my_daemon

Appropriate links are created automatically. This can be verified with the following command:

# chkconfig --list my_daemon

The resulting output should look like this:

my_daemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off

The script names that are created by chkconfig to make this all work are:

NOTE: You should normally not run finger,rlogin, orrsh due to security concerns with these commands.

Other services that can be launched by requests that come to xinetd include services for remote telnet requests, Samba configuration requests (swat), and Amanda network backups. A short description of each service is included in its /etc/xinetd.d file. Many of the services handled by xinetd are legacy services, including rlogin, rsh, and finger, that are considered insecure by today's security standards because they use clear-text passwords.

Manipulating run levels

Aside from the run level chosen at boot time (usually 3 or 5) and the shutdown or reboot levels (0 and 6, respectively), you can change the run level at any time while you're logged in (as root user). The telinit command (really just a symbolic link to init) enables you to specify a desired run level, causing the termination of all system processes that shouldn't exist in that run level, and starting all processes that should be running.

NOTE: The telinit command is also used to instruct init to reload its configuration file, /etc/inittab. This is accomplished with either the telinit q or the telinit Q commands.

For example, if you encountered a problem with your hard disk on startup, you may be placed in single-user mode (run level 1) to perform system maintenance. After the machine is stable, you can execute the command as follows:

# telinit 5

The init command handles terminating and starting all processes necessary to present you with a graphical login window.

Determining the current run level

You can determine the machine's current run level with the aptly named runlevel command. Using the previous example of booting into single-user mode and then manually changing the run level, the output of the runlevel command would be:

# runlevel
S 5

This means that the previous run level was S (for single-user mode) and the current run level is 5. If the machine had booted properly, the previous run level would be listed as N to indicate that there really wasn't a previous run level.

Changing to a shutdown run level

Shutting down the machine is simply a change in run level. With that in mind, other ways to change the run level include the reboot, halt, poweroff, and shutdown commands. The reboot command, which is a symbolic link to the consolehelper command, which in turn runs the halt command, executes a shutdown -r now, terminating all processes and rebooting the machine. The halt command executes shutdown -h now, terminating all processes and leaving the machine in an idle state (but still powered on).

Similarly, the poweroff command, which is also a link to the consolehelper command, executes a change to run level 0, but if the machine's BIOS supports Advanced Power Management (APM), it will switch off the power to the machine.

NOTE: A time must be given to the shutdown command, either specified as +m (representing the number of minutes to delay before beginning shutdown) or as hh:mm (an absolute time value, where hh is the hour and mm is the minute that you would like the shutdown to begin). Alternatively, now is commonly used to initiate the shutdown immediately.