Online Book Reader

Home Category

Running Linux, 5th Edition - Matthias Kalle Dalheimer [337]

By Root 1119 0
doing anything else.

rc Files

Linux stores startup commands in files with rc in the name, using an old Unix convention. The commands do all the things necessary to have a fully functioning system, such as starting the servers or daemons mentioned in "Processes" in Chapter 10. Thanks to these commands, the system comes up ready with logging facilities, mail, a web server, or whatever you installed and asked it to run. As explained in the previous section, the files are invoked from /etc/inittab. The commands are standard shell commands, and you can simply read the various rc files to see what they do.

In this section, we describe the structure of the rc files so that you can understand where everything starts, and so that you can start or stop servers manually in the rare case that they don't do what you want them to do. We use SUSE as our model, but once you get the idea of what to look for, you can find the corresponding files on any Linux distribution. SUSE is pretty good at sticking with the FHS, so other distributions are likely to look fairly similar, or at least will converge to look fairly similar. The Linux FHS is a distribution-neutral initiative to define standard directory names and filenames for important system files. Any Linux distribution that wants to be a good Linux citizen should follow this standard. Debian is another example of a distribution that does so. On Red Hat, the top-level rc script is /etc/rc.d/rc.

In the previous section, you saw how /etc/inittab invokes the script under a variety of circumstances with different numbers from 0 to 6 as arguments. The numbers correspond to runlevels, and each one causes the rc files to invoke a different set of scripts. So our next step is to find the scripts corresponding to each runlevel.

According to the FHS, scripts for each runlevel are stored in the directory /etc/init.d/rcN.d, where N is the runlevel being started. Thus, for runlevel 3, scripts in /etc/rc.d/rc3.d would be used. Again, slightly different conventions are the rule in other distributions.

Take a look in one of those directories; you will see a number of filenames of the form Snnxxxx or Knnxxxx where nn is a number from 00 to 99, and xxxx is the name of some system service. The scripts whose names begin with K are executed by /etc/rc.d/rc first to kill any existing services, and then the scripts whose names begin with S are executed to start new services.

The numbers nn in the names are used to enforce an ordering on the scripts as they are executed: scripts with lower numbers are executed before those with higher numbers. The name xxxx is simply used to help you identify to which system service the script corresponds. This naming convention might seem odd, but it makes it easy to add or remove scripts from these directories and have them automatically executed at the appropriate time by /etc/rc.d/rc. For customizing startup scripts, you'll find it convenient to use a graphical runlevel editor, such as KSysV in KDE (discussed later in this chapter). Some distributions also include a graphical runlevel editor as part of their administration tool.

For example, the script to initialize networking might be called S10network, while the script to stop the system logging daemon might be called K70syslog. If these files are placed in the appropriate /etc/init.d/rcN.d directories, /etc/init.d/rc will run them, in numerical order, at system startup or shutdown time. If the default runlevel of your system is 3, look in /etc/init.d/rc3.d to see which scripts are executed when the system boots normally.

Because the same services are started or stopped at different runlevels, the SUSE distribution uses symbolic links instead of repeating the same script in multiple places. Thus, each S or K file is a symbolic link that points to a central directory that stores startup or shutdown scripts for all services, typically /etc/init.d. On Debian and SUSE, the directory contains a script called skeleton that you can adapt to start and stop any new daemons you might write.

Knowing the location of

Return Main Page Previous Page Next Page

®Online Book Reader