System Startup Scripts

---

Debian GNU/Linux uses the SysV model for the system init scripts. Chapter 3 first discussed the SysV and BSD init scripts models, and Chapters 4 and 5 described SysV and BSD in detail. Like Red Hat, Debian uses an extensive SysV model, whereas Slackware is primarily BSD based with a few convenience hooks for scripts written to use the SysV model. Essentially, everything mentioned in Chapter 4 in the section "System Startup Scripts" about the init scripts is also true of Debian, with the few exceptions mentioned here.

Locating the SysV Directories

Debian GNU/Linux, like most systems that use the SysV model, has the relevant directories located immediately under the /etc directory. That is, the SysV directories are /etc/init.d for the scripts themselves, and /etc/rc1.d, /etc/rc2.d through /etc/rc6.d for the runlevel-specific directories. The script that manages all these is /etc/rc.d/rc.

Red Hat Linux 7.2, however, places the SysV directories all under the /etc/rc.d directory. That is, rather than /etc/init.d, Red Hat uses /etc/rc.d/init.d. For compatibility, Red Hat Linux has symbolic links from /etc to the corresponding directories in /etc/rc.d. (In a future version, Red Hat Linux will likely switch to the more common practice of putting the directories immediately underneath /etc.) Therefore, all the information in Chapter 4 in the SysV init scripts model also applies to Debian GNU/Linux, except for the change in directory location.

Working with Debian's Tool

Red Hat Linux includes several tools that automate the process of managing SysV init scripts—namely, chkconfig and service. Debian GNU/Linux does not include these tools, but provides similar alternatives: update-rc.d and invoke-rc.d.

Using update-rc.d

Debian's update-rc.d tool is similar to Red Hat's chkconfig. Whereas chkconfig is a binary program, update-rc.d is a Perl script. These tools have very different command-line options, but otherwise they perform very similar functions. Table 6-5 summarizes the usage of update-rc.d, though for complete information you should consult the manual page as always. (Note: To follow this section, it's imperative that you've read Chapter 4's content on the SysV init scripts model.)

Table 6-5: Using updated-rc.d

COMMAND	FUNCTION
update-rc.d -f <service> remove	Removes the service from all runlevels' configuration directories
update-rc.d <service> start <order> <runlevels>	Configures the service to be started with the specified ordering in a list of runlevels
update-rc.d <service> stop <order> <runlevels>	Configures the service to be killed (stopped) with the specified ordering in a list of runlevels

The biggest difference between update-rc.d and Red Hat's chkconfig is that update-rc.d is intended to set up all the runlevels' links to the service scripts in the /etc/init.d directory en masse, whereas chkconfig is capable of configuring services for each runlevel individually. Essentially, this just means that each time you change one runlevel with update-rc.d, you have to change them all. For example, the following sequence of commands is equivalent to the command chkconfig —level 2345 inetd off:

 $ update-rc.d -f inetd remove $ update-rc.d inetd stop 20 0 1 2 3 4 5 6 . 

The first command removes all the runlevels' links to the service script /etc/init.d/inetd; the -f flag causes update-rc.d to proceed even though the ientd script itself is present. The second command then creates stop scripts in each runlevel with a service priority of 20; for example, this will create the symbolic link /etc/rc3.d/K20inetd to disable inetd for runlevel 3. (Note that you have to add the reboot and shutdown runlevels, 0 and 6, explicitly, even though almost all services should always be set to "stop".) As another example, the commands shown next will enable inetd for runlevels 3 through 5, and disable it for all others:

 $ update-rc.d -f inetd remove $ update-rc.d inetd start 20 3 4 5 . stop 20 0 1 2 6 . 

Debian's update-rc.d can be a bit confusing at first, but once you figure it out, you'll see how well it works.

Using invoke-rc.d

Debian's equivalent of Red Hat's service command is invoke-rc.d. As it happens, the two commands are identical for most cases; for example, the commands service inetd start and invoke-rc.d inetd start have the same effect (which is to start the inetd service; the equivalent command to stop it would be invoke-rc.d inetd stop). The invoke-rc.d command does have a few extra command-line parameters that you can look into, but generally the two commands are equivalent.

Differences in /etc/initta

As discussed in Chapter 3, the file that primarily configures the init system process is /etc/inittab. This file governs the scripts that get executed during system bootup. The /etc/inittab that is installed on Debian GNU/Linux systems should look pretty familiar, since it's somewhat similar to Red Hat's, as discussed in Chapter 4.

There are a few important ways in which Debian's /etc/inittab differs from Red Hat's and Slackware's:

• Debian's default runlevel is 2.

• Debian does not configure the X Window System display manager (that is, login widget) from /etc/inittab. (Read the section "Debian GNU/Linux Idio-syncracies" later in this chapter for more information.)

• Runlevels 2 and 3 are identical; runlevels 4 and 5 are identical.

• Runlevels 4 and 5 only launch one virtual console; runlevels 2 and 3 launch six.

By now, you should be able to verify the preceding points by looking at /etc/inittab; for details on how to do that, see Chapters 4 and 5, in which Red Hat's and Slackware's /etc/inittab files are dissected in detail.

Other than those points, Debian is a pretty typical SysV init system. For the nitty-gritty details, see the discussion of Red Hat Linux's SysV init implementation in Chapter 4; most of the details will apply to Debian GNU/Linux, though the contents of the scripts themselves may be different.

---