BoF Protocol

[Michael Biebl]

> ---
> Often there are some variables in the init.d scripts whose values
> control the behavior of the scripts, and which a system administrator
> is likely to want to change. As the scripts themselves 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.
> ---
> That's another reason why so many packages use /etc/default/foobar for
> disabling: the init scripts tend to be changed more often by the
> maintainer, and it's nice if people can upgrade without having to
> understand a large diff output.

Whoever conceived and introduced this idea of disabling services via
/etc/default/$package deserves to be tarred and feathered. It is a
horribly broken idea. Unfortunately quite a few people adopted this
scheme.

There is a clear and defined way to disable sysv init scripts from
being started a bootup:
Remove the S?? symlink from the runlevel and create a corresponding K?? symlink.
Tools like sysv-rc-conf or guis like bum will easily manage that for you.

update-rc.d will correctly handle this case and not restore the S??
symlinks. So there are no upgrade hassles!

Why is using /etc/default/$package bad:
- Because it makes your init script useless if it is disabled via
/etc/default/. You aren't able any more to start it manually.
- It makes the init system inconsistent and ambiguous
- It breaks graphical frontends. Imagine a user, that tries to
start/stop a service via a GUI, but nothing happens, because the init
script just exits.


Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?