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
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 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
> >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]
> > https://askubuntu.com/questions/74061/install-packages-wit
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
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
tart 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
--
duckgo "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-divert`
ota 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
29 matches
Mail list logo
