[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

* 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

* 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: