Bug#804018: options to avoid service startup on package installation
On Wed, 25 Jul 2018 at 05:11:15 +0100, Ian Jackson wrote:
> ISTM that in days gone by this would have been (should have been) a
> wishlist item for invoke-rc.d. The interface was defined in
> invoke-rc.d(8) and README.policy-rc.d.gz.
...
> Nowadays, there is systemd too. I have no idea whether
> policyrcd-script-zg2 works with systemd.
It should. Packages that have an LSB init script (with or without a
parallel systemd unit) run update-rc.d and invoke-rc.d in their postinst,
as they did before systemd. Packages that have only a systemd unit run
deb-systemd-helper and deb-systemd-invoke instead. Both invoke-rc.d and
deb-systemd-invoke run policy-rc.d to decide whether they should continue.
All of this now lives in the Essential init-system-helpers package, which
took over the init-agnostic scripts from sysvinit.
Some examples:
* LSB init script only: cpufrequtils, ikiwiki-hosting-web, sysfsutils
* Both: apt-cacher-ng, avahi-daemon, uuid-runtime, many more
* systemd only: quake4-server, systemd-cron
policyrcd-script-zg2 is an adapter between the invoke-rc.d-defined API
(which says the policy-rc.d script must be in /usr/sbin) and what that
API should maybe have been all along (additionally looking for the script
in a configurable location, /usr/local/sbin, and /etc).
The policy-rc.d interface seems to have at least two overall objectives,
which shouldn't necessarily be conflated.
Some sysadmins want to stick to the usual Debian setup in general
(services that are installed get started), but disable individual
services: for instance I have various game dedicated servers like
openarena-server installed, but I don't want them to run when my laptop
boots, only on-demand. policy-rc.d is inconvenient for this use-case
because there is only one policy-rc.d script, so the list of services to
run is centralized and written in an imperative rather than declarative
language (unless you write a local policy-rc.d implementation that reads
a ".d"-style configuration directory, but you're still responsible for
writing the script that pulls it all together, because no such script
is packaged).
Other sysadmins (particularly those working with chroots) want a more
Red-Hat-like setup where services are not, in general, started just
because they are installed (possibly with a whitelist of exceptions to
that general policy, which is what happens in Red Hat). policy-rc.d is
fine for this, although somewhat over-engineered for the common trivial
cases "start everything" and "start nothing". sbuild-createchroot is one
example of a tool that provides a policy-rc.d that doesn't start anything,
although this is somewhat obsoleted by the recent change that /sbin/init
is non-Essential and invoke-rc.d doesn't start services when there is
no /sbin/init.
> If systemd has a different way of achieving the same overall objective
> then maybe the answer is just that the admin must configure this
> differently depending on what init system they have.
systemd does have an equivalent of policy-rc.d ("presets",
systemd.preset(5)) with what I personally think is a better configuration
language (declarative files in a .d-style directory instead of a single
imperative script), but it isn't fully supported by Debian packages:
it looks as though deb-systemd-helper (the equivalent of update-rc.d
for systemd units with no LSB equivalent) does respect presets, but
update-rc.d itself does not.
The problem with systemd-specific interfaces (and sysv-rc-specific
interfaces, and other-init-specific interfaces) is that it's hard to
make them meet the goal that switching between init systems preserves
"enabledness". I suspect policy-rc.d is going to be the only "official
Debian" interface to this as long as that goal exists.
An implementation of policy-rc.d that reads systemd presets and applies
them to any Debian-supported init system might be an interesting way to
get declarative configuration for this, if full support for sysvinit
and init-system-switching continues to be a goal.
smcv
Reply to: