Re: documenting on how not starting a daemon upon installation

[jnqnfe@gmail.com]

On Tue, 2020-03-10 at 18:48 +0100, Simon Richter wrote:
> 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
> 

interesting. thankyou. :)