mbiebl at gmail.com
Wed Jun 13 13:07:29 UTC 2007
> 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
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.
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
More information about the initscripts-ng-devel