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
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
> >starting a daemon upon installation".
> >
> >[1]
>
17 matches
Mail list logo
