On Wed, 22 Apr 2020 at 14:20:13 +0200, Lorenzo wrote:
> In bug #950851 the reporter says that runit is not policy compliant
> because during boot it does not check the policy-rc.d hack before
> starting sysv services.
>
> However I read policy 9.3.3 as referring to maintainer scripts (
> install, upgrade, remove) but I can't find anything about
> boot or shutdown.
You are correct. Other init systems do not consult policy-rc.d during
boot, and runit probably shouldn't either.
policy-rc.d only determines what happens when a package with a service
is installed or upgraded, most importantly during initial installation:
- install a machine/VM/container/chroot/thing with some init system
(historically sysvinit/sysv-rc) and without, for example, apache2
- install apache2
- is apache2 running now? The answer should depend on policy-rc.d.
For systemd, this logic is implemented by deb-systemd-invoke - but it's
rarely needed, because chroots that were not "booted" in the usual
way don't have systemd running, even if it is installed, so there is
no systemd instance that could take responsibility for starting the
service anyway.
For sysv-rc, this logic is implemented by invoke-rc.d - but it's rarely
needed now, because invoke-rc.d does not normally start services when it
detects that it is running in a chroot or with no init system installed,
which was the most common reason to want policy-rc.d in the past.
When a machine gets *rebooted*, the services that get started are
determined by the init system's concept of whether a service is "enabled"
or not. For sysv-rc and systemd, update-rc.d and deb-systemd-helper
work together to make sure that if /etc/init.d/apache2 is enabled in
/etc/rc*.d, then the corresponding systemd unit
/lib/systemd/system/apache2.service is enabled in /etc/systemd/system/,
and vice versa.
Services that get started manually by a sysadmin, either via the
init-agnostic service(8) or an init-system-specific mechanism like
'systemctl start', do not check policy-rc.d either.
Container frameworks vary in whether they behave like a more powerful
version of a chroot, with no init system or boot procedure (Docker is
designed to be used like this); or whether they behave like a lightweight
virtual machine, with a full init system and a real-machine-like boot
procedure (lxc is designed to be used like this); or whether it is
user-defined (systemd-nspawn is designed to work either way, and Docker
technically can too, although the full-machine-like mode is usually
discouraged for Docker containers).
> In my mind the severity of that bug ranges from
> wishlist ("please implement this new feature") to important (policy-rc.d
> is part of an interface that is defined in policy and has a should for
> maintainer scripts)
The reporter of #950851 describes a use-case that might be useful (being
able to install runit in a container and use it to launch selected
services, without having it manage or start *all* the services that
would normally run at boot-time, such as LSB init scripts). Having a
way to make that happen is a valid wishlist bug. However, I don't think
policy-rc.d is a good way to implement that feature.
In a systemd-based system, I would achieve the equivalent of #950851
by telling systemd to start a restricted target that only contains the
services I specifically want, instead of the default 'graphical.target'
(targets are analogous to sysvinit runlevels, but you can have any number
of them). Perhaps runit has, or could have, something similar?
smcv
