On Mon, 11 Sep 2017 14:41:12 +0100 Ian Jackson
<ijack...@chiark.greenend.org.uk> wrote:
> Sean Whitton writes ("Steps towards a patch to document disabling a daemon
> upon installation"):
> > [draft policy text]
> > > +The default behaviour is to enable autostarting your package's daemon.
> > > +If the daemon should not be autostarted unless the local administrator
> > > +has explicitly requested this, use instead add to your ``postinst``
> > > +script
> > > +
> > > +::
> > > +
> > > + update-rc.d package defaults
> > > + update-rc.d package disable
>
> This has a bug: after the first rune, but before this second, starting
> the daemon is enabled. (This is a regression compared to the previous
> approach.)
>
> To make this work correctly, I think we need a new update-rc.d
> mechanism which provides, in one go, the equivalent of
> update-rc.d DAEMON defaults && update-rc.d DAEMON disable
>
> Something like
> update-rc.d DAEMON add-disabled
> maybe.
I'd agree with this as a starting point, for setting a daemon-specific
default. However, I also think we need a system-wide policy mechanism to
allow the sysadmin to say "start things by default" or "don't start
things by default". Similar to systemd's "preset" mechanism, and ideally
using that under systemd, but providing the same level of control for
non-systemd init systems.
> > > +An older practice, which should not be used, was to include a line
> > > +like ``DISABLED=yes`` in the package's ``/etc/default`` file. The
> > > +package's init script would not start the service until the local
> > > +system administrator changed this to ``DISABLED=no``, or similar.
> ...
> > 1. Is the 'should not' for the /etc/default practice too strong? I
> > don't know an efficient way to find out how many packages this would
> > make buggy. But given that we have very strong reasons against the
> > old practice, we might want to use a 'should not' regardless.
>
> On sysvinit systems, using update-rc.d disable/defaults are rather
> more awkward:
>
> * Enabling and disabling cannot, in practice, be conveniently made
> without using the update-rc.d tool.
Why is this an issue? We have update-rc.d to do this.
> * Enabling and disabling generates a tremendous amount of noise in
> /etc (especially visible when using etckeeper).
This seems like an artifact of sysvinit's choice of storage format for
runlevel configuration. (And I never found that noise particularly
excessive in etckeeper; it's a handful of symlink deletions/creations.)
> > 2. Do we need to include any text saying *why* the /etc/default practice
> > is a bad idea? I couldn't come up with a succinct way to state it.
> > In general, I think we can err on the side of not including the text,
> > since we have policy bugs that document the reasons.
>
> How about this text:
>
> Setting a value in /etc/default/PACKAGE is nowadays troublesome
> because supporting that pattern is very hard due to inflexibility in
> systemd, which is usually the default init system.
>
> This also makes it clear that this pattern is perfectly fine if for
> any reason the package does not support systemd.
Which (among many other reasons) is precisely why we shouldn't use this
text, because many people have been very reasonably arguing for the
elimination of /etc/default and *especially* mechanisms like
"DISABLED=true" in it for longer than systemd has existed.
/etc/default is Debian-specific, and things like DISABLED=true break the
ability to *manually* start services. They also make it difficult to
programmatically configure services, such as by dropping in a
configuration .d file from a configuration package.
