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
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
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
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
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
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.
* 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
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
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
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
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
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'
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
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
* 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
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.
>
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
> 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
> >st
* 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]
> >
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
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
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
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
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
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://askubunt
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
--
"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
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-d
hat 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 da
29 matches
Mail list logo
