Understanding run-level scripts in Fedora 11 and RHEL

Solutions providers can use run-level scripts in Fedora 11 and Red Hat Enterprise Linux (RHEL) to start certain services and execute various commands.

Solutions provider takeaway:
Knowing what each specific run-level script does and how to manage them collectively will help increase how much assistance you can provide customers if they are having issues starting up or shutting down their systems.

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

Run-Level Scripts

What Does It Do?

acpid

Controls the Advanced Configuration and Power Interface daemon, which monitors events in the kernel and reports them to user level.

anacron

Runs cron jobs that were not run at their intended times due to the system being down.

apmd

Controls the Advanced Power Management daemon, which monitors battery status, and which can safely suspend or shut down all or part of a machine that supports it.

atd

Starts or stops the at daemon to receive, queue, and run jobs submitted via the at or batch commands. (The anacron run-level script runs at and batch jobs that were not run because the computer was down.)

autofs

Starts and stops the automount daemon, for automatically mounting file systems (so, for example, a CD can be automatically mounted when it is inserted).

bluetooth

Starts services such as authentication, discovery, and human interface devices for communicating with Bluetooth devices.

ConsoleKit

Maintains a list of user sessions.

crond

Starts or stops the cron daemon to periodically run routine commands.

cups

Controls the printer daemon (cupsd) that handles spooling printing requests.

dhcpd

Starts or stops the dhcpd daemon, which automatically assigns IP addresses to computers on a LAN.

dovecot

Starts the dovecot IMAP server, which allows e-mail clients to request and view their mail messages from the mail server.

firstboot

Checks to see if firstboot needs to be run and, if so, runs it. This is typically done after Fedora or RHEL is first installed.

gpm

Controls the gpm daemon, which allows the mouse to interact with console- and text-based applications.

haldaemon

Starts hald daemon to discover and set up hardware. Used to mount removable media, manage power, or auto-play multimedia.

halt

Terminates all processes, writes out accounting records, removes swap space, unmounts all file systems, and either shuts down or reboots the machine (depending on how the command was called).

hplip

Starts the HP Linux Imaging and Printing (HPLIP) service for running HP multi-function peripherals.

httpd

Starts the httpd daemon, which allows your computer to act as an HTTP server (that is, to serve Web pages).

iptables

Starts the iptables firewall daemon, which manages any iptables-style firewall rules set up for your computer.

keytable

Loads the predefined keyboard map.

killall

Shuts down any subsystems that may still be running prior to a shutdown or reboot.

ldap

Starts the Lightweight Directory Access Protocol daemon (sldap), which listens for LDAP requests from the network.

messagebus

Runs the dbus-daemon for broadcasting system message to interested applications.

mysqld

Runs the MySQL database daemon (mysqld) to listen for request to MySQL databases.

named

Starts and stops the BIND DNS server daemon (named) to listen for and resolve domain name system requests.

netfs

Mounts or unmounts network (NFS, SMB, and NCP) file systems.

network

Starts or stops all configured network interfaces and initializes the TCP/IP and IPX protocols.

NetworkManager

Switches automatically to the best available network connections.

nfs

Starts or stops the NFS-related daemons (rpc.nfsd, rpc.mountd, rpc.statd, and rcp.rquotad) and exports shared file systems.

ntpd

Runs the Network Time Protocol daemon (ntpd), which synchronizes system time with Internet standard time servers.

openvpn

Runs the OpenVPN virtual private network service.

portmap

Starts or stops the portmap daemon, which manages programs and protocols that utilize the Remote Procedure Call (RPC) mechanism.

routed

Starts or stops the routed daemon, which controls dynamic-routing table updates via the Router Information Protocol (RIP).

rsyslog

Starts or stops the klogd and rsyslogd daemons that handle logging events from the kernel and other processes, respectively.

rwhod

Starts or stops the rwhod daemon, which enables others on the network to obtain a list of all currently logged-in users.

sendmail

Controls the sendmail daemon, which handles incoming and outgoing SMTP (Simple Mail Transport Protocol) mail messages.

single

Terminates running processes and enters run level 1 (single-user mode).

smb

Starts or stops the smbd and nmbd daemons for allowing access to Samba file and print services.

snmpd

Starts or stops the snmpd (Simple Network Management Protocol) daemon, which enables others to view machine-configuration information.

spamassassin

Starts and stops the spamd daemon to automate the process of checking e-mail messages for spam.

squid

Starts or stops the squid services, which enables proxy service to clients on your network.

sshd

Runs the secure shell daemon (sshd), which listens for requests from ssh clients for remote login or remote execution requests.

vsftpd

Runs the Very Secure FTP server (vsftpd) to provide FTP sessions to remote clients for downloading and uploading files.

inbind

Runs the winbind service for Samba file and print services.

xfs

Starts or stops xfs, the X Window font server daemon.

xinetd

Sets the machine's hostname, establishes network routes, and controls xinetd, the network services daemon that listens for incoming TCP/IP connections to the machine.

yum

Enables you to run automatic nightly updates of your software using the yum facility.

xfs

Regenerates font lists and starts and stops the X font server.

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

NOTE: Always make a copy of a run-level script before you change it. Also, keep track of changes you make to run-level scripts before you upgrade the packages they come from. You need to make those changes again after the upgrade.

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

NOTE: The line chkconfig: 345 82 28 sets the script to start in run levels 3, 4, and 5. It sets start scripts to be set to 82 for those run levels. It sets stop scripts to be set to 28 in all other levels.

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:

/etc/rc0.d/K28my_daemon
/etc/rc1.d/K28my_daemon
/etc/rc2.d/K28my_daemon
/etc/rc3.d/S82my_daemon
/etc/rc4.d/S82my_daemon
/etc/rc5.d/S82my_daemon
/etc/rc6.d/K28my_daemon

Managing xinetd services

There are a bunch of services, particularly network services, which are not handled by separate run-level scripts. Instead, a single run-level script called xinetd (formerly inetd) is run to handle incoming requests for these services. For that reason, xinetd is sometimes referred to as the super-server. The xinetd run-level script (along with the xinetd daemon that it runs) offers the following advantages:

  • Fewer daemon processes -- Instead of one (or more) daemon processes running on your computer to monitor incoming requests for each service, the xinetd daemon can listen for requests for many different services. As a result, when you type ps -ax to see what processes are running, dozens of fewer daemon processes will be running than there would be if each service had its own daemon.
  • Access control and logging -- By using xinetd to oversee the management of services, consistent methods of access control (such as PAM) and consistent logging methods (such as the /var/log/messages file) can be used across all of the services.

When a request comes into your computer for a service that xinetd is monitoring, xinetd uses the /etc/xinetd.conf file to read configuration files contained in the /etc/xinetd.d directory. Then, based on the contents of the xinetd.d file for the requested service, a server program is launched to handle the service request (provided that the service is not disabled).

Each server process is one of two types: single-thread or multithread. A single-thread server handles only the current request, whereas a multithread server handles all incoming requests for the service as long as there is still a client holding the process open. Then the multithread server closes and xinetd begins monitoring that service again.

The following are a few examples of services that are monitored by xinetd. The daemon process that is started up to handle each service is also listed.

  • eklogin (/usr/kerberos/sbin/klogind) -- Kerberos-related login daemon
  • finger (/usr/sbin/in.fingerd) -- Handles incoming finger requests for information from remote users about local users
  • gssftp (/usr/kerberos/sbin/ftpd) -- Kerberos-related daemon for handling file transfer requests (FTP)
  • ntalk (/usr/sbin/in.ntalkd) -- Daemon for handling requests to set up chats between a remote user and a local one (using the talk command)
  • rlogin (/usr/sbin/in.rlogind) -- Daemon for responding to remote login requests (from a remote rlogin command)
  • rsh (/usr/sbin/in.rshd) -- Handles requests from a remote client to run a command on the local computer

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.


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

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

Dig Deeper on MSP business strategy

MicroScope
Security
Storage
Networking
Cloud Computing
Data Management
Business Analytics
Close