Chapter 9. The Operating System

66

particular, as the

/etc/init.d/

package

script itself is usually a

conffile

, it will remain

on the system if the package is removed but not purged. Therefore, you should include a

test

statement at the top of the script, like this:

test  f

program executed later in script

|| exit 0

Often there are some variables in the

init.d

scripts whose values control the behaviour of

the scripts, and which a system administrator is likely to want to change. As the scripts them 

selves are frequently

conffile

s, modifying them requires that the administrator merge in

their changes each time the package is upgraded and the

conffile

changes. To ease the bur 

den on the system administrator, such configurable values should not be placed directly in the

script. Instead, they should be placed in a file in

/etc/default

, which typically will have the

same base name as the

init.d

script. This extra file should be sourced by the script when the

script runs. It must contain only variable settings and comments in POSIX

sh

format. It may

either be a

conffile

or a configuration file maintained by the package maintainer scripts. See

`Configuration files' on page

81

for more details.

To ensure that vital configurable values are always available, the

init.d

script should set

default values for each of the shell variables it uses, either before sourcing the

/etc/default/

file or afterwards using something like the

:

${VAR:=default}

syntax. Also, the

init.d

script must behave sensibly and not fail if the

/etc/default

file is deleted.

9.3.3 Interfacing with the initscript system

Maintainers should use the abstraction layer provided by the

update rc.d

and

invoke rc.d

programs to deal with initscripts in their packages' scripts such as

postinst

,

prerm

and

postrm

.

Directly managing the /etc/rc?.d links and directly invoking the

/etc/init.d/

initscripts

should be done only by packages providing the initscript subsystem (such as

sysv rc

and

file rc

).

Managing the links

The program

update rc.d

is provided for package maintainers to arrange for the proper

creation and removal of

/etc/rc

n

.d

symbolic links, or their functional equivalent if another

method is being used. This may be used by maintainers in their packages'

postinst

and

postrm

scripts.

You must not include any

/etc/rc

n

.d

symbolic links in the actual archive or manually create

or remove the symbolic links in maintainer scripts; you must use the

update rc.d

program

instead. (The former will fail if an alternative method of maintaining runlevel information

is being used.) You must not include the

/etc/rc

n

.d

directories themselves in the archive

either. (Only the

sysvinit

package may do so.)

By default

update rc.d

will start services in each of the multi user state runlevels (2, 3, 4, and

5) and stop them in the halt runlevel (0), the single user runlevel (1) and the reboot runlevel (6).