Package: debian-policy
Severity: wishlist
There has been some discussion lately on debian-deval (and a bit on
-policy) about init scripts. One concern that has arisen is that it can
be very annoying to have to modify an init script to change a simple
value in it, and then be forced to maintain your modified init script
each time you upgrade and the package changes it. /etc/default is
already in use by 3 packages (2 of them in base; also, see also bug
#66574 point #3), this just formalizes it.
The thread also brought up the concern that an init script might start
using some new parameter, while the admin has modified its /etc/default/
file, and so the parameter does not have a value set, and this causes
the script to do something unexpected and/or bad. This proposal addresses
that concern as well.
It's late and my wording might be buggy -- patches gladly accpeted. I'm
also looking for seconds, of course.
(I believe this is a simple proposal that is orthagonal to some other
things being thrown around in the init.d thread, so I hope discussion of
this proposal can be limited to this alone and not drag the rest of that
in.)
--- policy.text.orig Sat Jul 8 02:21:49 2000
+++ policy.text Sat Jul 8 02:44:34 2000
@@ -1034,20 +1034,37 @@
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 particular, the init script itself is usually a
configuration file (see Section 3.3.5, `Notes'), and 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 values in the `init.d' scripts that a system
+ administrator will frequently want to change. While the scripts are
+ frequently conffiles, modifying them requires that the administrator
+ merge in their changes each time the package is upgraded and the
+ conffile changes. To ease the burden 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 can be sourced by the script when the script runs. It
+ must contain only variable settings and comments.
+
+ 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 before sourcing the /etc/default/ file. Also, since
+ the `/etc/default/' file is often a conffile, the `init.d' script must
+ behave sensibly without failing if it is deleted.
+
3.3.3. Managing the links
-------------------------
A program is provided, `update-rc.d', to handle the it easier 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 should use this script to make changes to `/etc/rc<n>.d' and
@@ -1113,61 +1130,76 @@
3.3.6. Example
--------------
The `bind' DNS (nameserver) package wants to make sure that the
nameserver is running in multiuser runlevels, and is properly shut
down with the system. It puts a script in `/etc/init.d', naming the
script appropriately `bind'. As you can see, the script interprets
the argument `reload' to send the nameserver a `HUP' signal (causing
it to reload its configuration); this way the user can say
- `/etc/init.d/bind reload' to reload the name server.
+ `/etc/init.d/bind reload' to reload the name server. The script has
+ one configurable value, which can be used to pass parameters to
+ the named program at startup.
#!/bin/sh
#
# Original version by Robert Leslie
# <[EMAIL PROTECTED]>, edited by iwj and cs
test -x /usr/sbin/named || exit 0
+ # Source defaults file.
+ PARAMS=''
+ if [ -e /etc/default/bind ]; then
+ . /etc/default/bind
+ fi
+
case "$1" in
start)
echo -n "Starting domain name service: named"
- start-stop-daemon --start --quiet --exec /usr/sbin/named
+ start-stop-daemon --start --quiet --exec /usr/sbin/named --
$PARAMS
echo "."
;;
stop)
echo -n "Stopping domain name service: named"
start-stop-daemon --stop --quiet \
--pidfile /var/run/named.pid --exec /usr/sbin/named
echo "."
;;
restart)
echo -n "Restarting domain name service: named"
start-stop-daemon --stop --quiet \
--pidfile /var/run/named.pid --exec /usr/sbin/named
- start-stop-daemon --start --verbose --exec /usr/sbin/named
+ start-stop-daemon --start --verbose --exec /usr/sbin/named --
$PARAMS
echo "."
;;
force-reload|reload)
echo -n "Reloading configuration of domain name service: named"
start-stop-daemon --stop --signal 1 --quiet \
--pidfile /var/run/named.pid --exec /usr/sbin/named
echo "."
;;
*)
echo "Usage: /etc/init.d/bind
{start|stop|restart|reload|force-reload}" >&2
exit 1
;;
esac
exit 0
+
+ Complementing the above init script is a file '/etc/default/bind',
+ which contains configurable parameters used by the script.
+
+ # Specified parameters to pass to named. See named(8).
+ # You may uncomment the following line, and edit to taste.
+ #PARAMS="-u nobody"
Another example on which to base your `/etc/init.d' scripts is in
`/etc/init.d/skeleton'.
--
see shy jo, who thinks we overuse the term "orthagonal" in Debian
