Re: documenting on how not starting a daemon upon installation
Hi,
On Tue, Mar 10, 2020 at 03:50:42PM +0000, jnqnfe@gmail.com wrote:
> - the 'move start-stop-daemon' trick is the old-old solution, kept
> around because some packages failed to get on board with the policy-
> rc.d solution, and could be removed from things like debootstrap/live-
> build if and only if at some point in the future there was certainty
> that there were no such packages left.
It is a bad hack, but it catches a few instances where people have been
following very old packaging guides. Such packages likely don't exist
anymore in Debian, but the Debian tools are often used outside it,
especially in companies building embedded systems.
Removing this hack would not affect Debian, but it might break some users'
setups, so it's left in.
> - the policy-rc.d solition is the old solution, kept around because
> systemd use is not quite 100%, though I'd expect and home that all
> packages are compatible by now, though systemd has a compatibility
> mechanism relating to policy-rc.d to work with users of that.
Please disregard the statistics on systemd usage -- there is no accurate
way to track installations because the vast majority of machines don't
report back to Debian, and with containers, the question of what counts as
a Debian installation is rather muddy anyway.
The policy-rc.d interface is not an official interface according to Debian
Policy, but it is used by invoke-rc.d, which is listed in Policy as the
appropriate way to invoke an init script from a maintainer script, so
"support" is widespread.
With systemd, a lot of these issues do not exist in the first place, as no
systemd is running inside the chroot, so there is no mechanism to start
services through systemd during debootstrap.
Historically, the requirement to start daemons after installation is older
than debootstrap and the idea of installing packages into a chroot. Before
the current debian-installer, the installation system extracted a tar file
into the target file system, made the system bootable and installation then
proceeded from there. Maintainer scripts were seldom run inside a chroot,
and those few that were had special checks.
>From a debootstrap/live-build perspective, policy-rc.d is the only
mechanism that really matters, because it is respected by those packages
that use a mechanism to start a daemon that actually works during
debootstrap time.
> - 'systemctl mask' is the modern systemd solution. the best solution
> for users if they have systemd. probably pointless though for
> debootstrap/live-build use if they're having to keep policy-rc.d
> support and even start-stop-daemon support around anyway after all
> these years.
"systemctl mask" does something else though: it disables a specific service
across reboots by hiding it from systemd, while policy-rc.d asks to be
consulted for every action. After installation, when the policy script is
removed, its effect is gone, but masked services remain disabled.
The equivalent of "systemctl mask" in the init.d world would be
"update-rc.d package defaults-disabled", as described in Debian Policy
section 9.3.3.1.
The systemd compatibility layer for policy-rc.d is not used for
bootstrapping, but to remain compatible with setups that use this mechanism
at runtime to integrate with some site-wide configuration framework.
Simon
Reply to: