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 ser
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.
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 do
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 syst
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 believe
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 solut
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 an
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 s
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 s
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 hi
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.
* 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 a
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
> 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]
>
>http
17 matches
Mail list logo
