[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: not starting a daemon upon installation

* jnqnfe@gmail.com <jnqnfe@gmail.com> [200308 10:58]:
> On Sat, 2020-03-07 at 21:30 +0100, Tomas Pospisek wrote:
> > The problem is that installing the package will automatically start
> > the
> > daemon cluster in a "default" configuration.
> > 
> > [1]
> > https://askubuntu.com/questions/74061/install-packages-without-starting-background-processes-and-services#
> i can't comment on what might be considered an "official" solution.
> how live-build achieves this is essentially the same as happens to be
> discussed in the linked page for Debian's debootstrap package (the tool
> for building the base filesystem).
> that is to use dpkg-divert to temporarily replace the /sbin/start-stop-
> daemon binary with something that essentially just exits with success
> (i.e. 0). This could be an empty shell script (or one that prints a
> warning about the diversion being in place as in the linked discussion)
> or a symlink to /bin/true.
> enabling diversion:
> ```
> dpkg-divert --add --rename /sbin/start-stop-daemon
> ln -fs /bin/true /sbin/start-stop-daemon
> ```
> removing diversion:
> ```
> rm -f /sbin/start-stop-daemon
> dpkg-divert --remove --rename /sbin/start-stop-daemon
> ```

I'm surprised that live-build does this and that debootstrap does as
well.  Note that the link above, farther down the page, gives what I
thought was the "correct" answer, which is to create a script,
/usr/sbin/policy-rc.d, which simply invokes exit 101.  This is also the
method described in the Debian wiki page for chroot [2].

live-build and debootstrap may have been doing this since before the
policy-rc.d API was defined, and they may also have more strict needs
than is defined by policy-rc.d (e.g. handling misbehaving packages).

However, for the OP's original purpose described in this thread, I
believe the policy-rc.d approach is the correct solution, and
dpkg-divert should be avoided.

[2] https://wiki.debian.org/chroot


Reply to: