When to Use Each Startup Method

With so many different startup methods available, it's not always easy to decide which one to use. Most servers packaged for specific Linux distributions ship in such a way that they immediately work with one startup method. For instance, the server may ship in a package that includes a SysV startup script or a xinetd configuration file in /etc/xinetd.d . You need not be bound by the defaults, however; in most cases, you can start a server in any of the ways mentioned. There are a few exceptions, and there are more cases in which servers are almost always run in a particular way because the benefits of that method are overwhelming. Table 4.2 summarizes the pros and cons of each of the three methods of starting servers.

Most distributions start most servers (and many nonserver services, such as sound card configurations) through SysV startup scripts. Many servers are important enough that you don't want to impose delays as a super server launches the server program, and SysV scripts are superior to local startup scripts from a distribution maintainer's point of view because it's easy to add and delete SysV startup scripts as part of a server's package file. Some servers, such as Samba's nmbd , tend to be unreliable when run from a super server. Sometimes this is related to a need of the server to maintain information from one call to another ”for instance, nmbd may keep information on the names and addresses of other computers on the network, and that information will be lost if it's run from a super server.

Table 4.2. Pros and Cons of Server Startup Methods

Startup method	Advantages	Disadvantages
SysV startup script	Custom server sets in different runlevels; fast server responses; server startup configurable by renaming files; easy manual start and stop of servers	Large memory footprint for large servers; fewer outside access controls possible
Super server	Low memory footprint for seldom-used servers; opportunity to add access controls	Slow server responses; some servers don't work well from this environment; servers can't as easily maintain state across calls
Local startup script	Fast server responses; easy to add server if it doesn't include SysV scripts	Poor integration with configuration tools ( chkconfig , ksysv , and so on); startup scripts vary across distributions

Super servers have their place, though. Many distributions use them by default for small servers that can load and run quickly, such as Telnet and FTP servers. You might also be willing to take the speed hit on large servers like Apache or sendmail if these servers aren't called very often. Some distributions, such as Debian, give you the option of running such servers from SysV startup scripts or via a super server when you install the server. Even if you're not given this choice, though, you can change your configuration after installation by disabling the SysV startup scripts and adding appropriate super server configurations.

In most cases, it's simplest to use the super server that comes with your distribution (either inetd or xinetd ). If you find that you need a feature of one particular super server (probably xinetd , since it's more sophisticated), you can replace your distribution's standard super server with the new one. You may need to modify the super server's SysV startup script or launch the new one through a local startup script. After you've done this, you can configure the new super server as described earlier in this chapter.

Local startup scripts are best reserved for cases when you would ordinarily run the server through a SysV script, but you lack a normal SysV startup script or it doesn't work correctly. If you're a new administrator, this is likely to occur when you install a server intended for one distribution on another one. As noted earlier, in the section "Using Local Startup Scripts," it's generally possible to create a custom SysV startup script, but if you're in a hurry or are inexperienced with such matters, adding a simple call to a local startup script can be a faster way to accomplish the goal.

NOTE

One additional method of starting servers is by hand; you can usually type the server's name to launch it. This method is useful mainly for testing, though. In most cases, you'll want to configure the server to start automatically, so that's what this chapter has emphasized .