XPost: linux.debian.bugs.dist

On Mon, 11 Sep 2017 14:41:12 +0100 Ian Jackson <ijackson@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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)