Re: documenting on how not starting a daemon upon installation
* Simon Richter <sjr@debian.org> [200309 12:33]:
> On Mon, Mar 09, 2020 at 04:02:52PM +0100, Tomas Pospisek wrote:
> > In my logic, finding out how "not to start services on install" should
> > be documented in `man dpkg` or referenced from that man page. As far as
> > I could see there is absolutely no trace of any hint on how to do that
> > in that man page.
>
> I'd expect to find this information in Policy, since it's a matter of
> system integration and package-to-package interaction. Dpkg has no control
> over whether a postinst starts a daemon or not.
>
> For init.d based init systems, policy 9.3.3.1 indeed documents exactly what
> you need to do to install a daemon that is disabled by default. This
> section should be extended to document the interface for systemd.
I think the OP's question was not about creating a package with a daemon
that is disabled by default, but about preventing an existing package,
that would otherwise start its daemon, from starting it.
My understanding (and I might very well be wrong) was that, due to the
historical evolution of systemd in Debian, even packages that only
include systemd service files and not init scripts still use
invoke-rc.d, and systemd provides its own implementation that obeys
policy-rc.d (if it exists) and then either invokes systemctl start or
the init script, as appropriate.
I was under the impression that the init-system-agnostic method to
prevent dpkg from automatically starting daemons was to create an
appropriate policy-rc.d file.
This is definitely not clear from the current policy document, and
policy should define an init-system-agnostic way to do this.
As for the other poster who seems to be advocating an approach which
combines policy-rc.d and diverting or replacing files in /bin and
/usr/bin, I believe that is neither necessary nor appropriate in the
general case. For the specific cases of debootstrap and live-build,
there might very well be other reasons for diverting system binaries (or
it could be left over from before the implementation of policy-rc.d),
but let's not cargo-cult this into inappropriate situations.
...Marvin
Reply to: