Chapter 9. The Operating System

65

The two runlevels 0 (halt) and 6 (reboot) are slightly different. In these runlevels, the links

with an

S

prefix are still called after those with a

K

prefix, but they too are called with the

single argument

stop

.

Also, if the script name ends

.sh

, the script will be sourced in runlevel

S

rather that being run

in a forked subprocess, but will be explicitly run by

sh

in all other runlevels.

9.3.2 Writing the scripts

Packages that include daemons for system services should place scripts in

/etc/init.d

to

start or stop services at boot time or during a change of runlevel. These scripts should be

named

/etc/init.d/

package

, and they should accept one argument, saying what to do:

start

start the service,

stop

stop the service,

restart

stop and restart the service if it's already running, otherwise start the service

reload

cause the configuration of the service to be reloaded without actually stopping and

restarting the service,

force reload

cause the configuration to be reloaded if the service supports this, otherwise

restart the service.

The

start

,

stop

,

restart

, and

force reload

options should be supported by all scripts

in

/etc/init.d

, the

reload

option is optional.

The

init.d

scripts should ensure that they will behave sensibly if invoked with

start

when the service is already running, or with

stop

when it isn't, and that they don't

kill unfortunately named user processes. The best way to achieve this is usually to use

start stop daemon

.

If a service reloads its configuration automatically (as in the case of

cron

, for example), the

reload

option of the

init.d

script should behave as if the configuration has been reloaded

successfully.

The

/etc/init.d

scripts must be treated as configuration files, either (if they are present in

the package, that is, in the .deb file) by marking them as

conffile

s, or, (if they do not exist

in the .deb) by managing them correctly in the maintainer scripts (see `Configuration files' on

page

81

). This is important since we want to give the local system administrator the chance to

adapt the scripts to the local system, e.g., to disable a service without de installing the package,

or to specify some special command line options when starting a service, while making sure

their changes aren't lost during the next package upgrade.

These scripts should not fail obscurely when the configuration files remain but the package has

been removed, as configuration files remain on the system after the package has been removed.

Only when

dpkg

is executed with the

  purge

option will configuration files be removed. In