Generic init.d script framework to reduce the redundant code in

The goal is to create an init.d script that is Debian and LSB compliant. When the Debian policy conflicts with the LSB, the Debian policy takes precedence.

This is a simple example on how init-d-script can be used to start and stop a daemon with PID file support:

#!/bin/sh /lib/init/init-d-script ### BEGIN INIT INFO # Provides: atd # Required-Start: $syslog $time $remote_fs # Required-Stop: $syslog $time $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: run at jobs # Description: Debian init script to start the daemon # running at jobs. ### END INIT INFO DAEMON=/usr/sbin/atd

The following variables affect behaviour of an init script:

Path to daemon being started. If the init script is not supposed to start any kind of daemon, it should be set to

and the functions

and

should be defined instead.

Additional arguments, passed to daemon during start.

Full name or short description of the daemon, printed on screen. If unset, this variable defaults to the

value.

Additional environment variables are sourced from

If unset, this variable defaults to the basename of the

value.

If this variable is set, it is used as argument to the

option of

It may be useful if the value of the

variable is longer than the command name length supported by the running kernel. If the value is verbatim

the command name will not be used to match the processes. If unset, this variable defaults to the

value.

Path to file where the process identifier of the started daemon will be stored during start. If the value is verbatim

the process identifier will not be stored in any file. If this variable is not set, it gets a sensible default value, so it is rarely necessary to set this variable explicitly.

Signal number or name (without the SIG prefix) that will be sent to the process on

If the daemon performs reload action upon receiving a

signal, this variable should be set to

or

The variables

and

are additional arguments, passed to

during reload, start and stop actions, to override the default options.

Additionally, it is possible to change the behaviour of the resulting shell script by overriding some of the internal functions. To do so, define function with an

suffix. So, for example, to override the

function, one should define a

function. The

to this rule is the

function, whose override should be defined as-is,

the above-mentioned suffix.

Here is a control flow chart that explains what functions are called and when:

/etc/init.d/script start do_start do_start_prepare # no-op do_start_cmd # start-stop-daemon is called here do_start_cleanup # no-op

/etc/init.d/script stop do_stop do_stop_prepare # no-op do_stop_cmd # start-stop-daemon is called here do_stop_cleanup # no-op

/etc/init.d/script status do_status

/etc/init.d/script reload do_reload do_usage exit 3

/etc/init.d/script force-reload do_force_reload do_reload # if overridden do_restart do_restart_prepare do_stop_cmd do_start_cmd do_restart_cleanup

/etc/init.d/script restart do_force_restart /etc/init.d/script try-restart if do_status; then do_restart do_restart_prepare do_stop_cmd # start-stop-daemon is called here do_start_cmd # start-stop-daemon is called here do_restart_cleanup

/etc/init.d/script arg do_unknown arg exit 3

/etc/init.d/script do_usage

As can be seen, by default, the script does not support the

action; it should be implemented by the script writer by defining a

function.

If

is not defined but

is, the latter will be called on

after

and before