System Startup and Shutdown

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. The rc 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.)

Table 12-5: Run-Level Scripts Contained in /etc/init.d
Open table as spreadsheet

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.
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.
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.
kudzu	Detects and configures new hardware at boot time.
ldap	Starts the Lightweight Directory Access Protocol daemon (sldap), which listens for LDAP requests from the network.
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.
pcmcia	Loads or unloads modules, drivers, and programs (including the cardmgr daemon) to support PCMCIA cards (Ethernet adapters, modems, memory cards, and so on) in laptop computers.
portmap	Starts or stops the portmap daemon, which manages programs and protocols that utilize the Remote Procedure Call (RPC) mechanism.
random	Loads or saves the current state of the machine's random number generator's random seed to ensure more random randomness.
routed	Starts or stops the routed daemon, which controls dynamic-routing table updates via the Router Information Protocol (RIP).
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 email 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.
syslog	Starts or stops the klogd and syslogd daemons that handle logging events from the kernel and other processes, respectively.
vsftpd	Runs the Very Secure FTP server (vsftpd), to provide FTP sessions to remote clients for downloading and uploading files.
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	Lets you run automatic nightly updates of your software using the yum facility.
xfs	Regenerates font lists and starts and stops the X font server.

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, while humans can readily see that 85 is less than 110, the file S110my_daemon is run before S85gpm . 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/rc X .d directories (where X is replaced by a run-level number) are symbolic links, usually to a file in /etc/init.d . The /etc/rc X .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.

Understanding What Startup Scripts Do

Despite all the complicated rc X s, 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 and nmbd daemons \   # used to provide SMB network services.   .   .   .   start() {   KIND="SMB"   echo -n $"Starting $KIND services: "   daemon smbd $SMBDOPTIONS   RETVAL=$?   echo   KIND="NMB"   echo -n $"Starting $KIND services: "   daemon nmbd $NMBDOPTIONS   RETVAL2=$?   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   KIND="NMB"   echo -n $"Shutting down $KIND services: "   killproc nmbd   RETVAL2=$?   [ $RETVAL -eq 0 -a $RETVAL2 -eq 0 ] && rm -f /var/lock/subsys/smb   echo ""   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 and nmbd servers when the script is run with the start option.

• stop - When run with the stop option, the /etc/init.d/smb script stops the smbd and nmbd servers.

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 ] Starting NMB services: [ OK ] 

To stop the service, type the following command:

 #  service smb stop  Shutting down SMB services: [ OK ] Shutting down NMB 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. 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 -l 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, kudzu, 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/rc X .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 System Settings Server Settings 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.

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

The Service Configuration window lets you reconfigure services for run levels 3, 4, and 5. The run levels that you are currently running and currently editing are displayed near the top of the screen. Services that are available for the run level appear in the middle of the frame, with checkmarks next to the ones configured to start at that level. Here is what you can do from this window:

• Add - Click the check box next to each service you want to start automatically at that run level so that a checkmark appears in the check box.

• Remove - Click the run-level script that you want to remove for a particular run level to remove the checkmark.

• Save - Click File, then Save Changes on the window to save any changes you have made to the run-level scripts.

• Refresh - Click View, then Refresh Service List to refresh the list of services.

• Start, Stop, or Restart - Click a service on the list. Select Actions, then either Start, Stop, or Restart Service. The selected service immediately starts, stops, or restarts.

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 Internet services, that 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 will handle only the current request, whereas a multithread server will handle all incoming requests for the service as long as there is still a client holding the process open. Then the multithread server will close and xinetd will begin 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

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 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 halt 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.