Re: Request for Comments: Standardize enabling/disabling of system services
Adam Borowski <kilobyte@angband.pl> writes:
> On Wed, Apr 01, 2009 at 05:03:27PM +0200, Patrick Schoenfeld wrote:
>> the question: "Shall a service started once its installed or not?" The
>> current state of affairs is that some packages start after beeing
>> installed, some don't, because they don't have a reasonable default
>> configuration and some don't, because the maintainer does not like this
>> approach.
> Please, DON'T.
> If a service shouldn't be run, there is a good command to disable it:
> dpkg --remove
>
> Anything else is superfluous. There are multiple ways to disable the
> service already. No need to add a yet another one.
The problem is, they all suck:
* Removing the service, when what you may want to do is run the service in
a different way (via supervise or runit, for example, or via separate
init scripts because you're running multiple instances on different
ports or different IP addresses).
* Renaming init script links, for which we have no adequate tool and which
is not an easily reversible process because nothing remembers what the
init script links were originally and what runlevels they were enabled
in. This is particularly a problem if you have a custom runlevel
configuration, want to disable an init script, and then want to put it
back where you had it.
* Using policy-rc.d, which is at least underdocumented. I've used Debian
for a long time and I still have difficulty figuring out just what I'm
supposed to put where to disable a specific init script for a specific
service using the policy-rc.d layer and how that interacts with the
system boot process.
* Adding DISABLE=y or DONT_RUN=y or DONT_NOT_RUN=no or similar unintuitive
stuff in configuration files, with all the problems of maintaining
configuration file differences when there are other parameters for which
you want to accept updates, and which disables the init script.
I think that renaming and/or removing the init script symlinks is the
Right Thing To Do, but the tools we have for doing this are awful. I
think it would be a great solution if update-rc.d gained the following
features:
* An option intended for use by automated processes that reports the
current status of the init script (enabled or disabled) and the current
run levels and sequence information in an easy-to-parse fashion.
* A way to disable an init script while retaining the current runlevel and
sequence information so that when it's re-enabled, it goes back where it
was.
* A way to move an init script at a particular sequence to a different
sequence without breaking the rest of the world, overriding local
policy, or killing puppies. (Unless dependency-based boot takes over
the world in time for squeeze and renders sequence information obsolete,
which would be lovely.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: