BoF Protocol

Erich Schubert erich.schubert at gmail.com
Wed Jun 13 13:28:23 UTC 2007


Hi Michael,
> Whoever conceived and introduced this idea of disabling services via
> /etc/default/$package deserves to be tarred and feathered. It is a

In general I agree with you on that.

> 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.
- it often means the service won't be stopped properly on shutdown
- it requires a shell to parse the settings (!), whereas the symlink
can be verified by any program.

The latter is a major issue IMHO with becoming init-independant.
For example, a smart init system might try to resolve dependencies. So
lets assume we have "service1" depend on "service2". When "service2"
is disabled, "service1" can't be started, and the init system should
be able to tell you that it can't start "service1". But it hardly can,
if it would need to parse the configuration file (which is a shell
script).

I do however have objections to using the symlinks for service
enabling/disabling, because it's very sysv-centric. I'd prefer to have
an init-independant approach.
(However it might even be useful to have different setups in different
inits, so I'd be fine with using this for disabling services on sysv,
as long as we provide some API for users and UIs to disable services
in a non-init-aware fashion, just like update-rc.d does.)

Anyway, we can/should maybe use this meta-init efforts to solve
exactly this issue, and do away with these configuration variables
when switching packages to meta-init; to get this accepted by
maintainers and users we need to make sure there is an easier, cleaner
way of doing that (like adding an 'update-rc.d disable foobar'
command!)

Marco:
Well, certain packages such as rsync or mpd are probably more often
used in user mode than as root. For these it makes perfectly sense to
not start the daemon automatically. (although it would be possible to
make a 'rsyncd' package just containing the rsync init script)
Others can't be automatically started since they need to be configured
(e.g. mpdscribble needs a username and password to access last.fm).

best regards,
Erich Schubert
--
    erich@(mucl.de|debian.org)      --      GPG Key ID: 4B3A135C    (o_
  To understand recursion you first need to understand recursion.   //\
  Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für   V_/_
        eine Stunde wie eine Heimat aus. --- Herrmann Hesse



More information about the initscripts-ng-devel mailing list