Re: documenting on how not starting a daemon upon installation

[Johannes Schauer]

Quoting Marvin Renich (2020-03-11 13:43:50)
>   - policy-rc.d requires manually writing a shell script (a trivial
> one-liner for the "block all" case).

Not quite. From the first answer to OP's original question by Jonas:

Quoting Jonas Smedegaard (2020-03-07 22:36:44)
> Are you familiar with helper packages to do that for you - e.g.
> policy-rcd-declarative and policyrcd-script-zg2?

As by FHS [1] you should not place stuff in /usr/sbin even as a root user. That
directory is managed by your package manager (dpkg). The two packages mentioned
by Jonas solve that conundrum. For a discussion about that issue see this bug:

https://bugs.debian.org/911290.

Thanks!

cheers, josch

[1] https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.txt

signature.asc
Description: signature

Re: documenting on how not starting a daemon upon installation

[Marco d'Itri]

On Mar 11, Marvin Renich  wrote:

>   - it has not been mentioned whether systemd provides any facility to
> block starting _all_ services for a period of time (esp when working
> in a chroot), including services that have not been installed at the
> time the hypothetical "block all services" command is invoked.
systemd cannot start services in a chroot anyway because there is no 
systemd daemon there, so it does not matter for this use case.

>   - policy-rc.d can block individual systemd services and init scripts.
>   - policy-rc.d can block all services and init scripts.
> 
>   - policy-rc.d is not well documented.
>   - policy-rc.d requires manually writing a shell script (a trivial
> one-liner for the "block all" case).
But only if the daemons are started using invoke-rc.d.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: documenting on how not starting a daemon upon installation

[Marvin Renich]

Thanks, Russ, Ansgar, and Marco for the explanations.

So in summary:

* For systems running systemd

  - systemctl mask works well to disable individual daemons until
explicitly re-enabled, regardless of which mechanism the package
uses (systemd service or init script) to start the daemon.

  - systemctl mask requires you to know, prior to installing a package,
the names of all services the package installs.
  - it has not been mentioned whether systemd provides any facility to
block starting _all_ services for a period of time (esp when working
in a chroot), including services that have not been installed at the
time the hypothetical "block all services" command is invoked.

* For systems running either systemd or sysvinit (maybe also runit?)

  - policy-rc.d can block individual systemd services and init scripts.
  - policy-rc.d can block all services and init scripts.

  - policy-rc.d is not well documented.
  - policy-rc.d requires manually writing a shell script (a trivial
one-liner for the "block all" case).

It is also worth noting that systemctl mask works on any systemd
distribution, not just Debian GNU/Linux, but not other Debian ports with
non-Linux kernels.

And, policy-rc.d presumably works on any Debian distribution, not just
Debian GNU/Linux, but not on non-Debian distributions.

It looks to me like policy-rc.d is the best fit for performing package
installations in a chroot (the OP's original question, IIUC), while
systemctl mask is the right choice for manually dealing with maintenance
of individual, already installed packages.

...Marvin

Re: documenting on how not starting a daemon upon installation

[Marco d'Itri]

On Mar 10, Marvin Renich  wrote:

> > The modern and simple solution is "systemctl mask", as long as you do 
> > not need to care about the 0.6% of systems which do not use systemd.
> > If you are doing this for your own systems then you obviously know if 
> > you can rely on systemd or not.
> I don't believe this is correct, though I could be wrong.  I believe
Indeed, others have already explained that you are.

> policy-rc.d is sufficient for both systemd and sysvinit systems, and
It is sufficient, but it is also badly documented and a bit annoying to 
use.
The big point in favour of policy-rc.d is that it can be used to prevent 
starting ALL daemons with a single command. OTOH, the systemd method 
will work no matter what the init script or the local administrator do.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: documenting on how not starting a daemon upon installation

[Ansgar]

Marvin Renich writes:
> * Marco d'Itri  [200310 11:23]:
>> The modern and simple solution is "systemctl mask", as long as you do 
>> not need to care about the 0.6% of systems which do not use systemd.
>> If you are doing this for your own systems then you obviously know if 
>> you can rely on systemd or not.
>
> I don't believe this is correct, though I could be wrong.  I believe
> policy-rc.d is sufficient for both systemd and sysvinit systems, and
> that it is necessary for _packages_ that only ship an init script and
> not a service file, regardless of the init system in use.
>
> Can you tell me,
>
> A)  Does systemctl mask work for packages that do not have a systemd
> service file when systemd is the init system?

It should work: init.d scripts just get a .service file generated that
calls `ExecStart=/etc/init.d/${something} start` (and some somewhat
appropriate settings).  You can find the generated units in
/run/systemd/generator*; see also man:systemd-sysv-generator(8).

You can also change other settings for init-based services by creating a
`/etc/systemd/system/${something}.service.d/local.conf` just like for
native systemd services.

> B)  Can systemctl mask be run on a subdirectory that you are about to
> chroot into, but have not yet done so?

I would expect something like `systemctl --root=/chroot mask
${something}.service` to work.  If it doesn't work, that's probably a
bug.

Ansgar

Re: documenting on how not starting a daemon upon installation

[Russ Allbery]

Marvin Renich  writes:

> I don't believe this is correct, though I could be wrong.  I believe
> policy-rc.d is sufficient for both systemd and sysvinit systems, and
> that it is necessary for _packages_ that only ship an init script and
> not a service file, regardless of the init system in use.

> Can you tell me,

> A)  Does systemctl mask work for packages that do not have a systemd
> service file when systemd is the init system?

> B)  Can systemctl mask be run on a subdirectory that you are about to
> chroot into, but have not yet done so?

I believe both of these are true.

The way systemctl mask works is that it creates a null unit file (a link
to /dev/null) that overrides any installed unit file for that service.
init scripts are supported in systemd by generating units from the init
scripts and are masked by any actual unit file, so the one created by
systemctl mask will also prevent the init script from running.

The implementation creates a file in /etc/systemd, so I don't see any
reason why it wouldn't work with a chroot, although maybe there's some
wrinkle that I've not thought of.

-- 
Russ Allbery (r...@debian.org)  

Re: documenting on how not starting a daemon upon installation

[Marvin Renich]

* Marco d'Itri  [200310 11:23]:
> The modern and simple solution is "systemctl mask", as long as you do 
> not need to care about the 0.6% of systems which do not use systemd.
> If you are doing this for your own systems then you obviously know if 
> you can rely on systemd or not.

I don't believe this is correct, though I could be wrong.  I believe
policy-rc.d is sufficient for both systemd and sysvinit systems, and
that it is necessary for _packages_ that only ship an init script and
not a service file, regardless of the init system in use.

Can you tell me,

A)  Does systemctl mask work for packages that do not have a systemd
service file when systemd is the init system?

B)  Can systemctl mask be run on a subdirectory that you are about to
chroot into, but have not yet done so?

If both these questions are yes, and the system in the chroot is using
(will be using) systemd, than systemctl mask should be sufficient.
Otherwise I think policy-rc.d is necessary.

...Marvin

Re: documenting on how not starting a daemon upon installation

[jnqnfe]

On Tue, 2020-03-10 at 18:48 +0100, Simon Richter wrote:
> Hi,
> 
> On Tue, Mar 10, 2020 at 03:50:42PM +, jnq...@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. :)

Re: documenting on how not starting a daemon upon installation

[Simon Richter]

Hi,

On Tue, Mar 10, 2020 at 03:50:42PM +, jnq...@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

Re: documenting on how not starting a daemon upon installation

[jnqnfe]

On Tue, 2020-03-10 at 16:23 +0100, Marco d'Itri wrote:
> On Mar 10, jnq...@gmail.com wrote:
> 
> > If the policy-rc.d solution is the modern/best/whatever solution,
> > the
> No. policy-rc.d is the old solution which was implemented because
> there 
> was no better way to implement this with init scripts.
> It worked by mandating that maintainer scripts must start and stop 
> daemons only by using invoke-rc.d.
> 
> The modern and simple solution is "systemctl mask", as long as you
> do 
> not need to care about the 0.6% of systems which do not use systemd.
> If you are doing this for your own systems then you obviously know
> if 
> you can rely on systemd or not.
> 
> > fact that live-build/debootstrap also includes the 'moving start-
> > stop-
> > daemon' trick is either indeed a left over from before systemd (I
> > do
> > not know the history of it), or is left to ensure compatibility
> > without
> > systemd?
> It is needed because some buggy maintainer scripts do/did not use 
> invoke-rc.d, so better be safe than sorry.

okay, thankyou.

so as I understand it:
 - 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.
 - 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.
 - '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.

Re: documenting on how not starting a daemon upon installation

[Marco d'Itri]

On Mar 10, jnq...@gmail.com wrote:

> If the policy-rc.d solution is the modern/best/whatever solution, the
No. policy-rc.d is the old solution which was implemented because there 
was no better way to implement this with init scripts.
It worked by mandating that maintainer scripts must start and stop 
daemons only by using invoke-rc.d.

The modern and simple solution is "systemctl mask", as long as you do 
not need to care about the 0.6% of systems which do not use systemd.
If you are doing this for your own systems then you obviously know if 
you can rely on systemd or not.

> fact that live-build/debootstrap also includes the 'moving start-stop-
> daemon' trick is either indeed a left over from before systemd (I do
> not know the history of it), or is left to ensure compatibility without
> systemd?
It is needed because some buggy maintainer scripts do/did not use 
invoke-rc.d, so better be safe than sorry.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: documenting on how not starting a daemon upon installation

[jnqnfe]

On Tue, 2020-03-10 at 19:39 +0500, Andrey Rahmatullin wrote:
> On Tue, Mar 10, 2020 at 02:33:50PM +, jnq...@gmail.com wrote:
> > If the policy-rc.d solution is the modern/best/whatever solution,
> > the
> > fact that live-build/debootstrap also includes the 'moving start-
> > stop-
> > daemon' trick is either indeed a left over from before systemd (I
> > do
> > not know the history of it), or is left to ensure compatibility
> > without
> > systemd?, because of course for a long time systemd has been
> > considered
> > a choice, and perhaps still is (not that I want to start another
> > systemd vs alternatives discussion).
> policy-rc.d is much older than systemd.

oh okay, forgive my ignorance of that matter

if that is so and policy-rc-d is applicable to both systemd and non-
systemd situations, then perhaps live-build and debootstrap should
consider dropping the 'move start-stop-daemon' solution as redundant?
the original author of live-build left the project so can't be asked
why it existed (git hostory did not help much when I previously looked)
and I am ignorant as to whether it serves any other purpose than being
an older (?) secondary solution for the same thing... I could discuss
it with the current maintainers; if anyone has any useful info to
support it being unnecessary that could be helpful in any such proposal
of removal (I'm currently doing a lot of live-build contributing)...

Re: documenting on how not starting a daemon upon installation

[Andrey Rahmatullin]

On Tue, Mar 10, 2020 at 02:33:50PM +, jnq...@gmail.com wrote:
> If the policy-rc.d solution is the modern/best/whatever solution, the
> fact that live-build/debootstrap also includes the 'moving start-stop-
> daemon' trick is either indeed a left over from before systemd (I do
> not know the history of it), or is left to ensure compatibility without
> systemd?, because of course for a long time systemd has been considered
> a choice, and perhaps still is (not that I want to start another
> systemd vs alternatives discussion).
policy-rc.d is much older than systemd.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: documenting on how not starting a daemon upon installation

[jnqnfe]

On Tue, 2020-03-10 at 08:47 -0400, Marvin Renich wrote:
> 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.

That was my understanding also.

> 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.

If you mean me, I was not so much advocating the use of the dpkg-divert 
or policy-rc.d solutions used by live-build/deboostrap, but merely
informing the OP what solutions are in use by these Debian project
tools, wrt. to the mess of hacks found in the provided link.

If the policy-rc.d solution is the modern/best/whatever solution, the
fact that live-build/debootstrap also includes the 'moving start-stop-
daemon' trick is either indeed a left over from before systemd (I do
not know the history of it), or is left to ensure compatibility without
systemd?, because of course for a long time systemd has been considered
a choice, and perhaps still is (not that I want to start another
systemd vs alternatives discussion).

Re: documenting on how not starting a daemon upon installation

[Marvin Renich]

* Simon Richter  [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

Re: not starting a daemon upon installation

[jnqnfe]

On Sun, 2020-03-08 at 11:44 -0400, Marvin Renich wrote:
> * jnq...@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
> 
> ...Marvin

as corrected in an earlier addition to this discussion I amended my
description of live-build's approach to include that it does both the
start-stop-daemon approach _and_ the policy-rc.d approach (which I'd
overlooked).

debootstrap does both also, but avoiding without using dpkg-divert
itself for the move of start-stop-daemon (it just moves the file).

Re: documenting on how not starting a daemon upon installation

[Simon Richter]

Hi,

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.

   Simon

documenting on how not starting a daemon upon installation

[Tomas Pospisek]

> On Sun, 8 Mar 2020, Marc Haber wrote:
>
> On Sat, 7 Mar 2020 21:30:33 +0100, Tomas Pospisek 
>
> >When I duckduckgo "dpkg do not start service on install" first hit is
> >[1] which contains /absurdly involved/ suggestions to achieve "not
> >starting a daemon upon installation".
> >
> >[1]
>
>https://askubuntu.com/questions/74061/install-packages-without-starting-background-processes-and-services#
>
> This is indeed bordering between incredibly funny and disturbing.
> Alas, it's a golden example for the quality of answers one gets in the
> Ubuntu universe.

Not commenting on Askubuntu: it is also an indication, that the "right
way" to do this is "way too badly documented".

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.

It might also be me not having read that man page closely enough to
discern the microbial hint to where to find that info.

So I think it would be proper to improve the documentation here. I as an
"advanced user" should not need to rely on second hand information via
StackOverflow but find it naturally through `man dpkg` and `man apt-get`
IMHO.

Currently I don't have any idea on how to go about this, i.e. where how
to document this and similar things. Suggestions, hints welcome.
*t

PS: sorry for not replying correctly to Marc's message (and thus
breaking threading), I have deleted that message already :-(

Re: not starting a daemon upon installation

[Marvin Renich]

* jnq...@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

...Marvin

Re: not starting a daemon upon installation

[jnqnfe]

On Sun, 2020-03-08 at 18:50 +0100, Marc Haber wrote:
> debootstrap's files don't contain the string "divert". They do,
> however, dump "exit 101" to $TARGET/usr/sbin/poliy-rc.d.

I should issue a small correction to my earlier statement of live-build 
using a dpkg-divert of start-stop-daemon as its _single_ solution;
working on the live-build codebase right now I bumped into its
chroot_sysv-rc module and thus got a reminder that it does in fact also
implement the policy-rc-d solution.

so both debootstrap and livebuild both implement a form of both of
these.

Re: not starting a daemon upon installation

[Tomas Pospisek]

On 07.03.20 21:30, Tomas Pospisek wrote:

> tldr: why is not having a daemon started on install so involved? Can't
> there be a better way?

to which Jonas, Marco & jnqnfe replied (see thread). Thanks a lot Jonas,
Marco & jnqnfe!
*t

Re: not starting a daemon upon installation

[jnqnfe]

On Sun, 2020-03-08 at 18:50 +0100, Marc Haber wrote:
> On Sun, 08 Mar 2020 14:58:01 +, jnq...@gmail.com wrote:
> > 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).
> 
> debootstrap's files don't contain the string "divert". They do,
> however, dump "exit 101" to $TARGET/usr/sbin/poliy-rc.d.

I had not looked at debootstrap's approach until just now. their's is
indeed partially to use the policy-rc.d solution as you say, but also
to do similar to the dpkg-divert solution only without actually using
dpkg-divert, they just move the original file.

extracting from debootstrap's scripts/debian-common:
```
echo \
"#!/bin/sh
exit 101" > "$TARGET/usr/sbin/policy-rc.d"
chmod 755 "$TARGET/usr/sbin/policy-rc.d"

mv "$TARGET/sbin/start-stop-daemon" "$TARGET/sbin/start-stop-
daemon.REAL"
echo \
"#!/bin/sh
echo
echo \"Warning: Fake start-stop-daemon called, doing nothing\"" >
"$TARGET/sbin/start-stop-daemon"
chmod 755 "$TARGET/sbin/start-stop-daemon"
```

I also found the following entry in debootstrap's changelog which is
interesting wrt. this discussion, from v1.0.52 (May 2013):
```
  * scripts/sid, scripts/gutsy: Add a policy-rc.d, matching that in
debian-installer-utils.  This is the primary way to disable daemon
startup.
```

Re: not starting a daemon upon installation

[Marc Haber]

On Sun, 08 Mar 2020 14:58:01 +, jnq...@gmail.com wrote:
>fyi, preventing start/stop of _all_ services on package installation is
>a requirement of Debian's live-build, which if you're not familiar with
>it is a tool to build a Debian live-cd. Building a live environment is
>typically done in a chroot and it involves installing many packages
>which should not impact the host in terms of starting/stopping
>services.
>
>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).

debootstrap's files don't contain the string "divert". They do,
however, dump "exit 101" to $TARGET/usr/sbin/poliy-rc.d.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: not starting a daemon upon installation

[jnqnfe]

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.
> 
> That's a problem for me because etcd differentiates between starting
> the
> cluster for the first time and starting it subsequentially. The first
> time is special as it generates some internal state.
> 
> So I would like to control whether etcd - or for the matter any
> service
> - is started upon package installation.
> 
> I imagine that this would be quite a standard requirement for
> devops/configuration tools aka "please do not run and configure the
> service for me because I want to do it precisely **this way**" (which
> is
> kinda the point of configration automation).
> 
> When I duckduckgo "dpkg do not start service on install" first hit is
> [1] which contains /absurdly involved/ suggestions to achieve "not
> starting a daemon upon installation".
> 
> It /seems/ that the "official" way to achieve "not starting a daemon
> upon installation" is to use `dpkg-divert` to overwrite `policy-rc.d`
> with a script that exits with 101.
> 
> This to me seems again like a awkward, byzantine and brittle way to
> achieve that goal. Also, the only canonical documentation of policy-
> rc.d
> seems to be
> /usr/share/doc/init-system-helpers/README.policy-rc.d.gz, which is
> quite
> cryptic, contains no examples and contains "rc.d" in its name in a
> world
> where systemd is the default, which makes me doubt whether all
> packages
> using systemd will respect policy-rc.d...
> 
> So I'm wondering:
> 
> * is this really the official (twisted ?8-o) way to solve the problem
> of
> not starting a daemon automatically upon installation?
> * why was such an involved method chosen, instead of say setting an
> environment variable DPKG_DONT_START_DAEMON or such?
> 
> [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.

fyi, preventing start/stop of _all_ services on package installation is
a requirement of Debian's live-build, which if you're not familiar with
it is a tool to build a Debian live-cd. Building a live environment is
typically done in a chroot and it involves installing many packages
which should not impact the host in terms of starting/stopping
services.

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
```

someone else has already offered an alternate solution applicable to
individual packages.

if the problem you are experiencing with this particular package you
reference is common, then perhaps a bug should be filed or discussion
take place regarding changing it such that it not try to start its
service upon installation.

Re: not starting a daemon upon installation

[Marc Haber]

On Sat, 7 Mar 2020 21:30:33 +0100, Tomas Pospisek 
>When I duckduckgo "dpkg do not start service on install" first hit is
>[1] which contains /absurdly involved/ suggestions to achieve "not
>starting a daemon upon installation".
>
>[1]
>https://askubuntu.com/questions/74061/install-packages-without-starting-background-processes-and-services#

This is indeed bordering between incredibly funny and disturbing.
Alas, it's a golden example for the quality of answers one gets in the
Ubuntu universe.

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: not starting a daemon upon installation

[Marc Haber]

On Sat, 7 Mar 2020 23:02:23 +0100, Marco d'Itri  wrote:
>There is:
>
># systemctl mask $DAEMON.service
># apt install $DAEMON
>
>That's it. If the package fails to install then file a bug.

For that you need to know how the $DAEMON is called.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: not starting a daemon upon installation

[Marco d'Itri]

On Mar 07, Tomas Pospisek  wrote:

> tldr: why is not having a daemon started on install so involved? Can't
> there be a better way?
There is:

# systemctl mask $DAEMON.service
# apt install $DAEMON

That's it. If the package fails to install then file a bug.

> When I duckduckgo "dpkg do not start service on install" first hit is
> [1] which contains /absurdly involved/ suggestions to achieve "not
> starting a daemon upon installation".
Yes, all of that works but but thankfully nowadays we have systemd.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: not starting a daemon upon installation

[Jonas Smedegaard]

Quoting Tomas Pospisek (2020-03-07 21:30:33)
> tldr: why is not having a daemon started on install so involved? Can't 
> there be a better way?

> It /seems/ that the "official" way to achieve "not starting a daemon 
> upon installation" is to use `dpkg-divert` to overwrite `policy-rc.d` 
> with a script that exits with 101.
> 
> This to me seems again like a awkward, byzantine and brittle way to
> achieve that goal.

Are you familiar with helper packages to do that for you - e.g. 
policy-rcd-declarative and policyrcd-script-zg2?

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

not starting a daemon upon installation

[Tomas Pospisek]

Hi all,

tldr: why is not having a daemon started on install so involved? Can't
there be a better way?

I'm hacking around an ansible playbook that needs to configure an etcd
cluster.

The problem is that installing the package will automatically start the
daemon cluster in a "default" configuration.

That's a problem for me because etcd differentiates between starting the
cluster for the first time and starting it subsequentially. The first
time is special as it generates some internal state.

So I would like to control whether etcd - or for the matter any service
- is started upon package installation.

I imagine that this would be quite a standard requirement for
devops/configuration tools aka "please do not run and configure the
service for me because I want to do it precisely **this way**" (which is
kinda the point of configration automation).

Nota bene: that requirement does not criticise Debian packagers nicely
integrating all things - which is of huge value for the task.

When I duckduckgo "dpkg do not start service on install" first hit is
[1] which contains /absurdly involved/ suggestions to achieve "not
starting a daemon upon installation".

It /seems/ that the "official" way to achieve "not starting a daemon
upon installation" is to use `dpkg-divert` to overwrite `policy-rc.d`
with a script that exits with 101.

This to me seems again like a awkward, byzantine and brittle way to
achieve that goal. Also, the only canonical documentation of policy-rc.d
seems to be
/usr/share/doc/init-system-helpers/README.policy-rc.d.gz, which is quite
cryptic, contains no examples and contains "rc.d" in its name in a world
where systemd is the default, which makes me doubt whether all packages
using systemd will respect policy-rc.d...

So I'm wondering:

* is this really the official (twisted ?8-o) way to solve the problem of
not starting a daemon automatically upon installation?
* why was such an involved method chosen, instead of say setting an
environment variable DPKG_DONT_START_DAEMON or such?

I'm writing to d-d because I think this is a fundamental distro problem
that's worth a thought/discussion/improvement.

?

Waves-
*t

[1]
https://askubuntu.com/questions/74061/install-packages-without-starting-background-processes-and-services#