Advanced Linux Networking
| AT&T's System V, or SysV, UNIX set many of the standards used on today's UNIX and Linux systems. One of these was a method of starting system services, including servers. In the SysV scheme, each service comes with a script that can be used to start or stop the service by passing the script the start or stop parameter, respectively. Many of these startup scripts support additional parameters, such as restart to shut down the server and start it up again (say, to implement a changed configuration).
NOTE
The SysV startup scheme is closely tied to the runlevel of the computer. Each runlevel is associated with a specific set of startup scripts, and hence with a specific set of services that the system runs. (SysV scripts can start more than just network servers; they can start system loggers, filesystem handlers, and so on.) Thus, configuring servers to start via SysV scripts is closely related to configuring these runlevels. This is done by altering the names of links to the startup scripts, as stored in directories associated with each runlevel. Startup Script Locations and Naming Conventions
Although the basic outline of SysV startup scripts is the same across most distributions, there are differences in many details. Most importantly, different distributions place the startup scripts in different locations. They may also call scripts by different names, although these differences are usually not too extreme. Table 4.1 summarizes these SysV layout differences for several major Linux distributions. Note that distributions differ in where they place the actual scripts, where they place the links to the scripts that are associated with specific runlevels, and where they place local startup scripts (which are discussed in more detail shortly, in the section "Using Local Startup Scripts"). In the case of script links, a ? in the directory name refers to a number from 0 to 6 corresponding to the runlevel. Table 4.1. Startup Script Locations in Major Linux Distributions
NOTE
NOTE
Several distributions (notably Red Hat, Mandrake, TurboLinux, and to a lesser extent Caldera) are quite similar to each other, particularly in their placement of SysV scripts ( /etc/rc.d/init.d ) and the links to those scripts ( /etc/rc.d/rc ? .d ). Others place the scripts in slightly different locations. Slackware is the most unusual in this respect. Rather than running individual scripts in a directory named after a runlevel, Slackware uses a single script for each runlevel. For instance, the /etc/rc.d/rc.4 script controls the startup of runlevel 4. For most Linux distributions (Slackware being the major exception), the links in the SysV startup script link directories are named in a very particular way. Specifically , the filename takes the form C##name , where C is a character ( S or K ), ## is a two-digit number, and name is a name that's traditionally the same as the corresponding script in the SysV script directory. For instance, the link filename might be S10network or K20nfs ”filenames that correspond to the network and nfs scripts, respectively. As you might guess, this naming scheme isn't random. The name portion of the link filename helps you determine what the script does; it's usually named after the original script. The leading character indicates whether the computer will start or kill (for S and K , respectively) the script upon entering the specified runlevel. Thus, S10network indicates that the system will start whatever the network script starts (basic networking features, in fact), and K20nfs shuts down whatever the nfs script controls (the NFS server, in reality). The numbers indicate the sequence in which these actions are to be performed. Thus, S10network starts networking before S55sshd starts the secure shell (SSH) server. Similar rules apply for shutdown ( K ) links. The names and numbers of the startup and shutdown links vary from one distribution to another. For instance, Mandrake uses S10network to start its basic networking features, but Debian uses S35networking for this function. Similar differences may exist for the scripts that launch specific servers. What's important is that all the necessary servers and processes are started in the correct order. Many networking tools must be started after basic networking features are started, for instance. It's generally not wise to change the order in which startup and shutdown scripts execute, unless you understand this sequence and the consequences of your changes. One additional wrinkle requires mention: SuSE uses the /etc/rc.config file to control the SysV startup process. This file contains sections pertaining to major servers that can be started via the SysV process, and if a server is not listed for startup (via a line of the form START_ SERVERNAME ="yes" ), SuSE doesn't start that server, even if its link name begins with S . Caldera uses a similar scheme for a few servers, but uses files in /etc/sysconfig/daemons named after the servers in question. The ONBOOT line in each of these files determines whether the system starts the server. Many startup scripts ignore this option in Caldera, though. Manually Enabling or Disabling Startup Scripts
If you find that you need to enable or disable a server that's started through a SysV startup script, one way to proceed is to adjust the startup scripts or the links to them. One approach to disabling a server is to remove the startup script from the SysV script directory. This is a quick fix that affects all runlevels, but it's rather inelegant. It also doesn't help you if you want to start a server rather than disable one. A more elegant solution is to rename the link to the startup script in the SysV link directory that corresponds to your current runlevel. For instance, to disable a server, rename it so that it starts with K rather than S ; to enable it, reverse this process. The difficulty with this procedure is that the sequence number isn't likely to be the same when killing the server as when starting it. One way around this potential pitfall is to locate all the links to the script in all the runlevels. If any of the other runlevels sport the configuration you want, you've found the sequence number. For instance, the following command finds all the links for the Postfix mail server startup scripts on a Mandrake system: $ find /etc/rc.d -name "*postfix" /etc/rc.d/rc0.d/K30postfix /etc/rc.d/rc1.d/K30postfix /etc/rc.d/rc2.d/S80postfix /etc/rc.d/rc3.d/S80postfix /etc/rc.d/rc4.d/S80postfix /etc/rc.d/rc5.d/S80postfix /etc/rc.d/rc6.d/K30postfix /etc/rc.d/init.d/postfix This sequence shows that Postfix is started with a sequence number of 80 in runlevels 2 through 5, and shut down with a sequence number of 30 in runlevels 0, 1, and 6. If you wanted to disable Postfix in runlevel 3, you could do so by renaming S80postfix to K30postfix in that runlevel's directory. If you want to temporarily start or stop a server, or if you want to initiate a change immediately without restarting the computer or adjusting the runlevel, you can do so by running the startup script along with the start or stop parameters. For instance, to stop Postfix immediately, you could type the following command on a Mandrake system: # /etc/rc.d/init.d/postfix stop Most Linux distributions display a message reporting the attempt to shut down the server, and the success of the operation. When starting a SysV script, a message about the startup success appears. (In fact, you may see these messages scroll across your screen after the kernel startup messages when you boot your computer.) In the case of Slackware, instead of renaming, adding, or deleting startup scripts or their links, you should edit the single startup script file for the runlevel in question. For instance, if you want to change the behavior of runlevel 4, you'd edit /etc/rc.d/rc.4 . Most servers, though, aren't started in these runlevel-specific scripts; they're started in /etc/rc.d/rc.inet2 , with very basic network tools started in /etc/rc.d/rc.inet1 . To change your configuration, you'll have to manually modify these scripts as if they were local startup scripts, as described in the section "Using Local Startup Scripts." Using Startup Script Utilities
Some distributions include utilities that help you control startup scripts. These tools can be very useful because they reduce the chance of misnaming a script. For instance, an automated tool won't mistype S80postfix as s80postfix (using a lowercase s instead of an uppercase S ). Unfortunately, not all distributions support these tools ”they're most common on Red Hat and its derivatives, such as Mandrake. Installing one of these tools from one distribution for use on another is unlikely to work because of the differences in SysV script locations and startup sequence numbers.
NOTE
Using chkconfig
The SysV startup script tool with the crudest user interface is chkconfig . This program is a non-interactive command ”you must provide it with the information it needs to do its job on a single command line. The syntax for the command is as follows : chkconfig <listadddel> [ name ] chkconfig [level levels ] name [onoffreset] The first format of this command is used to obtain information on the current configuration (using ”list ) or to add or delete links in the SysV link script directory (using ”add or ”del , respectively). The second format is used to enable or disable a script in some or all runlevels by changing the name of the SysV link, as described earlier. Some examples will help clarify the use of this command. Suppose you want to know how Postfix is configured. If you know the Postfix startup script is called postfix , you could enter the following command to check its configuration: # chkconfig list postfix postfix 0:off 1:off 2:on 3:on 4:on 5:on 6:off This output shows the status of Postfix in each of the seven runlevels. You can verify this by using the find command described earlier. When chkconfig shows an on value, the startup link filename should start with S , and when chkconfig shows an off value, the startup link filename should start with K . If you type chkconfig ”list without specifying a particular startup script filename, chkconfig shows the status for all the startup scripts, and possibly for servers started through xinetd as well, if your system uses xinetd . The ”add and ”del options add links if they don't exist or delete them if they do exist, respectively. Both these options require that you specify the name of the original startup script. For instance, chkconfig ”del postfix removes all the Postfix SysV startup script links. The result is that Linux won't start the server through a SysV startup script, or attempt to change a server's status when changing runlevels. You might do this if you wanted to start a server through a super server or local configuration script. You might use the ”add parameter to reverse this change. You'll probably make most chkconfig changes with the on , off , or reset options. These enable a server, disable a server, or return the server to its default setting for a specified runlevel. (If you omit the ”level option, the change applies to all runlevels.) For instance, suppose you want to disable Postfix in runlevel 3. You could do so by typing the following command: # chkconfig level 3 postfix off This command won't return any output, so if you feel the need to verify that it's worked, you should use the ”list option or look for a changed filename in the startup script link directory. You can enable a server by using on rather than off . If you want to affect more than one runlevel, you can do so by listing all the runlevels in a single string, as in 345 for runlevels 3, 4, and 5. If you've experimented with settings and want to return them to their defaults, you can use the reset option: # chkconfig postfix reset This command will reset the SysV startup script links for Postfix to their default values. You can reset the default for just one runlevel by including the ”level levels option as the first parameter to the command. Although chkconfig is generally thought of as a way to manage SysV startup scripts, it can also work on xinetd configurations on many systems. If chkconfig is configured to treat, say, your FTP server as one that's launched via a super server, you can use it to manipulate this configuration much as if the FTP server were launched through SysV startup scripts. The difference is that the ”level levels parameter won't work, and the ”list option doesn't show runlevel information. Instead, any server started through a super server will run in those runlevels in which xinetd runs. Furthermore, the ”add and ”del options work just like on and off , respectively; the /etc/xinetd.d configuration files aren't deleted, only disabled, as described in the upcoming section, "Using xinetd." When you change the SysV configuration with chkconfig , it does not automatically alter the servers that are running. For instance, if you reconfigure your system to disable sshd , that server will not be immediately shut down without manual intervention of some sort , such as running the SysV startup script with the stop option to stop the server. Using ntsysv
The ntsysv program provides a text-based menu environment for manipulating server startup. To run the program, type its name, optionally followed by ”level levels , where levels is one or more runlevels you want to modify. If you omit this parameter, ntsysv modifies the configuration only for the current runlevel. Either way, the result should resemble Figure 4.1. Figure 4.1. The ntsysv program provides an easy-to-use interface for SysV configuration.
The ntsysv display shows all the servers that have SysV startup scripts. Some versions also display servers started through xinetd . To enable or disable a server, use the arrow keys on your keyboard to move the cursor to the server you want to adjust, then press the spacebar to toggle the server on or off. An asterisk ( * ) in the box to the left of the server name indicates that the server is active; an empty box indicates that the server is disabled. When you're done making changes, use the Tab key to highlight the OK button, then press the Enter key to exit from the program and save your changes. As with chkconfig , you can't adjust the specific runlevels in which servers mediated by a super server are run, except by changing the runlevels for the super server itself. Also, disabling a server won't cause it to shut down immediately; you must do that by manually shutting the server down, as described earlier, or by restarting the super server, if your target server is handled by the super server. Setting and Changing the Runlevel
The preceding discussion has referred to the runlevel, but with only a minimal description of what it is. The runlevel and SysV startup scripts are tied together quite intimately. When the computer boots, it enters a specific runlevel. Ultimately, what this means is that the computer executes the startup scripts to which the links in the SysV script link directories point. More specifically, Linux passes the start parameter to the scripts whose links start with S , and passes the stop parameter to those whose links begin with K . How does Linux know what runlevel to enter when it boots, though? That's set in the /etc/inittab file, which is the configuration file for init , which is the first process that Linux runs and the progenitor of all other processes. Specifically, /etc/inittab contains a line such as the following: id:5:initdefault: The leading id is the key to identifying this line, but the following number ( 5 in this example) is what you'll use to permanently set the runlevel. If you change this value and reboot, the computer will come up in a different runlevel. Runlevels 0, 1, and 6 have special meanings ”they correspond to a system shutdown, a single-user mode, and a system reboot, respectively. Runlevels 2 through 5 are normal runlevels, but their precise meanings vary from one distribution to another. For Caldera, Red Hat, Mandrake, SuSE 7.3, and TurboLinux, runlevel 3 is a normal text-mode startup (X is not started), and runlevel 5 is a GUI login mode (X is started, and a GUI login program is run). Earlier versions of SuSE use runlevels 2 and 3 instead of 3 and 5, and Slackware uses 3 and 4 for text-mode and GUI logins. By default, Debian doesn't run any SysV scripts differently in different normal operational runlevels, although it runs fewer text-mode login tools in runlevels above 3 (this detail is handled by subsequent lines of /etc/inittab ). Most distributions include a series of comments in their /etc/inittab files describing the function of each runlevel, so look for that if you need more information or are using a distribution I don't discuss in this book.
WARNING
If you want to change the runlevel temporarily, you can do so with the telinit command ( init also works on most systems). The syntax for this command is as follows: telinit [-t seconds ] [ runlevel ] When you change runlevels, it's possible that certain processes will have to be killed . Linux can do this through either a SIGTERM or a SIGKILL signal. The former is a more polite way of doing the job; it lets the program close its own files and so on. SIGKILL , by contrast, unceremoniously kills the program, which can lead to file corruption. When you change runlevels, telinit first tries to use a SIGTERM . Five seconds later, if a process hasn't quit, telinit sends a SIGKILL . If specified, the -t seconds parameter changes this interval. In most cases, the default five seconds is adequate. The runlevel specification is a single-character code for the runlevel. Most obviously, you can provide a runlevel number. There are certain other characters you can pass that have special meaning, however:
Why would you want to change the runlevel? Changing the default runlevel allows you to control which servers start up by default. On most distributions, the most important of these is the X server. This is usually started by a special line towards the end of /etc/inittab , not through a SysV startup script, although some use a SysV startup script for XDM to do the job. Changing the runlevel while the computer is running allows you to quickly enable or disable a set of servers, or change out of GUI mode if you want to temporarily shut down X when your system is configured to start it automatically. |