Advanced.Linux.Networking..Roderick.Smith [Electronic resources] نسخه متنی

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. href="http:// /JVXSL.asp?x=1&mode=section&sortKey=insertDate&sortOrder=desc&view=&xmlid=0-201-77423-2/ch04lev1sec6&open=true&title=New%20This%20Week&catid=&s=1&b=1&f=1&t=1&c=1&u=1#ch04table02#ch04table02"> 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 anotherfor 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.

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 " href="http:// /?xmlid=0-201-77423-2/ch04lev1sec4#ch04lev1sec4"> 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

align=left border=0>

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.