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: 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 :-(