a.service will just not stop after it gets activated, and b.service fails.
Otherwise, the start job is cancelled with a JOB_DEPENDENCY job result. If
you need those semantics (and people often do), use After=, so that the
start job for a waits for the running job of b to complete (note that if
you
Make of that what you will. I was expecting a.service to stop because
b.service failed, but apparently my understanding of this isn't quite
right.
And that's kinda my point... most people (me included until recently)
expect that behaviour
I think the overall conclusion of that conversation
On Thu, Jan 3, 2019 at 4:23 AM James Feeney wrote:
> > What Reindl Harald was saying was that "Requires" should have an
> > implicit "After" because it wouldn't make sense for a.service to
> > require b.service but to start before b.service.
>
> I understand that Reindl has said that. But, just
On Wed, Jan 2, 2019 at 10:51 PM James Feeney wrote:
>
> On 1/2/19 12:50 AM, Olaf van der Spek wrote:
> > Activation by itself guarantees basically nothing.
>
> "Activation" guarantees activation.
Eh, yes, but what does that guarantee mean?
Activation can fail so effectively it guarantees nothing
On Thu, 3 Jan 2019, Jonathon Kowalski wrote:
> On Wed, 2 Jan 2019, Jérémy Rosen wrote:
> > I'm pretty sure that there is something about Requires making a unit fail if
> > it's dependency has already failed when it is scheduled for startup...
> >
> > Again I may be wrong...
>
> On Wed, 2 Jan
On 1/2/19 5:38 PM, Tom H wrote:
>> Some developers and some users are not native English speakers. In
>> some cases, systemd terminology can be ... less than optimal, while,
>> in other situations, users will simply misunderstand the conventional
>> meaning of words.
> You might not like how
Am 03.01.19 um 01:38 schrieb Tom H:
> What Reindl Harald was saying was that "Requires" should have an
> implicit "After" because it wouldn't make sense for a.service to
> require b.service but to start before b.service
exactly and i don't get the discussion fuss about such obvious things
On Wed, Jan 2, 2019 at 10:09 PM James Feeney wrote:
> On 1/2/19 3:21 AM, Reindl Harald wrote:
>>
>> it's pretty obvious when i REQUIRE something that it should be there
>> when i get started
>
> Not only is it not "obvious" that "something should be there", it is not true.
>
> You are confusing
Am 02.01.19 um 22:09 schrieb James Feeney:
> On 1/2/19 3:21 AM, Reindl Harald wrote:
>> it's
>> pretty obvious when i REQUIRE something that it should be there when i
>> get started
>
> Not only is it not "obvious" that "something should be there", it is not true.
>
> You are confusing
On 1/2/19 12:50 AM, Olaf van der Spek wrote:
> Activation by itself guarantees basically nothing.
"Activation" guarantees activation. Activating, for instance, a service unit
is quite a bit more significant than "nothing".
>> Because, as far as I know, "Requisite=" is completely broken in
On Wed, Jan 2, 2018, James Feeney wrote:
> Because, as far as I know, "Requisite=" is completely broken in systemd.
I am curious about how. I am aware that Requisite= will internally
create a job of JOB_VERIFY_ACTIVE job type and install it (on
start/restart (when it gets patched to start after
On Wed, Jan 2, 2018, Zbigniew Jędrzejewski-Szmek wrote:
>The short answer is that Requires without After is mostly meaningless,
>because it's impossible for systemd to actually implement the check,
>so effectively Requires downgrades to Wants
It doesn't downgrade to Wants=, because if the
On 1/2/19 3:21 AM, Reindl Harald wrote:
> it's
> pretty obvious when i REQUIRE something that it should be there when i
> get started
Not only is it not "obvious" that "something should be there", it is not true.
You are confusing "Requires=" and "Requisite=".
Some developers and some users are
On Wed, 2 Jan 2019, Jérémy Rosen wrote:
> I'm pretty sure that there is something about Requires making a unit fail if
> it's dependency has already failed when it is scheduled for startup...
>
> Again I may be wrong...
On Wed, 2 Jan 2019, Michael Chapman wrote
>Make of that what you will. I was
On Wed, 2 Jan 2019, Reindl Harald wrote:
> Am 02.01.19 um 09:14 schrieb Michael Chapman:
> > I have two services on my system, A.service and B.service, where A.service
> > Wants=B.service but is ordered Before=B.service. The reason for this is
> > that when I start A I want B to be automatically
Am 02.01.19 um 09:14 schrieb Michael Chapman:
> I have two services on my system, A.service and B.service, where A.service
> Wants=B.service but is ordered Before=B.service. The reason for this is
> that when I start A I want B to be automatically started too, but B cannot
> function without
Am 02.01.19 um 05:22 schrieb James Feeney:
> On 1/1/19 8:33 PM, Reindl Harald wrote:
>> "After" is a soft dependency, if that unit isn't enabled or don#t exist
>> at all it don't matter
>>
>> "Requires" is a hard dependency and it makes no sense not imply ordering
>
> And then, what do you mean
On Wed, 2 Jan 2019, Jérémy Rosen wrote:
> So...
> >> Requires = Wants + PartOf
> >> Requires + After = Wants + PartOf + Requisite + After
> >>
> >> better ?
> >> My goal is to try to clarify that in the documentation at some point...
> > I don't think Requisite= comes into it at all.
> >
> >
So...
Requires = Wants + PartOf
Requires + After = Wants + PartOf + Requisite + After
better ?
My goal is to try to clarify that in the documentation at some point...
I don't think Requisite= comes into it at all.
Requisite= propagates a "start" or "restart" job as a "verify-active" job.
In
On Wed, 2 Jan 2019, Jérémy Rosen wrote:
>
>
> On 02/01/2019 10:08, Michael Chapman wrote:
> >
> >> Requires = Wants + Requisite + PartOf
> >>
> >> is that correct ?
> > I think it's just:
> >
> >Requires = Wants + PartOf
> >
> > Wants= propagates "start" and "restart" jobs as "start" jobs on
On 02/01/2019 10:08, Michael Chapman wrote:
Requires = Wants + Requisite + PartOf
is that correct ?
I think it's just:
Requires = Wants + PartOf
Wants= propagates "start" and "restart" jobs as "start" jobs on the other
unit.
ConsistsOf= (the inverse of PartOf=) propagates "stop" and
On Wed, 2 Jan 2019, Jérémy Rosen wrote:
>
> > In my opinion, I don't think the extra inconsistency we get from this is
> > worth it. It literally only saves one line in a unit file.
> >
> It's not about saving a line in the unit file, it's about avoiding errors on
> the most common case
>
> i.e
On 02/01/2019 09:59, Olaf van der Spek wrote:
On Wed, Jan 2, 2019 at 9:54 AM Jérémy Rosen wrote:
i.e if A Requires B, you would expect failures of B to prevent A from starting.
* This is not the case if B is (randomly) scheduled after A.
* This is the case if B is (randomly) scheduled before
On Wed, 2 Jan 2019, Olaf van der Spek wrote:
> On Wed, Jan 2, 2019 at 9:14 AM Michael Chapman wrote:
> > > What good is an activation dependency without an ordering dependency?
> >
> > The problem is that it's not necessarily clear _which_ ordering dependency
> > is required. systemd can't just
On Wed, Jan 2, 2019 at 9:54 AM Jérémy Rosen wrote:
> i.e if A Requires B, you would expect failures of B to prevent A from
> starting.
> * This is not the case if B is (randomly) scheduled after A.
> * This is the case if B is (randomly) scheduled before A.
> This is the race the implicit After=
On Wed, 2 Jan 2019, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jan 02, 2019 at 07:14:10PM +1100, Michael Chapman wrote:
[...]
> > The problem is that it's not necessarily clear _which_ ordering dependency
> > is required. systemd can't just assume one way or the other.
> >
> > I have two
In my opinion, I don't think the extra inconsistency we get from this is
worth it. It literally only saves one line in a unit file.
It's not about saving a line in the unit file, it's about avoiding
errors on the most common case
i.e if A Requires B, you would expect failures of B to
On Wed, Jan 2, 2019 at 9:14 AM Michael Chapman wrote:
> > What good is an activation dependency without an ordering dependency?
>
> The problem is that it's not necessarily clear _which_ ordering dependency
> is required. systemd can't just assume one way or the other.
>
> I have two services on
On Wed, Jan 02, 2019 at 07:14:10PM +1100, Michael Chapman wrote:
> On Wed, 2 Jan 2019, Olaf van der Spek wrote:
> > On Wed, Jan 2, 2019 at 4:22 AM James Feeney wrote:
> > > systemd has two different classes of "dependencies": 1) "activation"
> > > dependencies, and 2) "ordering" dependencies.
>
On Wed, 2 Jan 2019, Zbigniew Jędrzejewski-Szmek wrote:
> On Sun, Dec 30, 2018 at 12:05:46PM +0100, Olaf van der Spek wrote:
> > Hi,
> >
> > Evverx suggested I ask here @
> > https://github.com/systemd/systemd/issues/11284
> > It's about Requires and After. I think a unit in Requires should imply
On Sun, Dec 30, 2018 at 12:05:46PM +0100, Olaf van der Spek wrote:
> Hi,
>
> Evverx suggested I ask here @ https://github.com/systemd/systemd/issues/11284
> It's about Requires and After. I think a unit in Requires should imply
> that unit in After too, otherwise the requirement isn't really met.
On Wed, 2 Jan 2019, Jérémy Rosen wrote:
>
> >> What's the benefit of not having After= for those services?
> >I guess they can start and do their initialization in parallel with
> > the service they require.
> In that case, what is the benefit or Requires vs Wants ?
>
> I might be missing
What's the benefit of not having After= for those services?
I guess they can start and do their initialization in parallel with
the service they require.
In that case, what is the benefit or Requires vs Wants ?
I might be missing something about what Requires does (shutdown ?) but
at
On Wed, 2 Jan 2019, Olaf van der Spek wrote:
> On Wed, Jan 2, 2019 at 4:22 AM James Feeney wrote:
> > systemd has two different classes of "dependencies": 1) "activation"
> > dependencies, and 2) "ordering" dependencies.
> >
> > An activation dependency does not, a priori, have to obey any rules
On Wed, Jan 2, 2019 at 4:22 AM James Feeney wrote:
> systemd has two different classes of "dependencies": 1) "activation"
> dependencies, and 2) "ordering" dependencies.
>
> An activation dependency does not, a priori, have to obey any rules about
> ordering. There are not, automatically, any
On 1/1/19 8:33 PM, Reindl Harald wrote:
> "After" is a soft dependency, if that unit isn't enabled or don#t exist
> at all it don't matter
>
> "Requires" is a hard dependency and it makes no sense not imply ordering
And then, what do you mean by "soft dependency" and "hard dependency"? It
> It's about Requires and After. I think a unit in Requires should imply
> that unit in After too, otherwise the requirement isn't really met.
> Is there a use case for Requires but not After?
Olaf, previously, on GitHub, you had said:
>> I think I understand Requires and After ...
and, I would
Am 01.01.19 um 20:24 schrieb Tomasz Torcz:
> On Tue, Jan 01, 2019 at 08:20:19PM +0100, Olaf van der Spek wrote:
>> On Tue, Jan 1, 2019 at 8:17 PM Ian Pilcher wrote:
>>>
>>> On 1/1/19 5:44 AM, Jérémy Rosen wrote:
The short answer is that Requires without after makes little sense,
since
On Tue, Jan 01, 2019 at 08:20:19PM +0100, Olaf van der Spek wrote:
> On Tue, Jan 1, 2019 at 8:17 PM Ian Pilcher wrote:
> >
> > On 1/1/19 5:44 AM, Jérémy Rosen wrote:
> > > The short answer is that Requires without after makes little sense,
> > > since you can't reliably know if your dependency is
On Tue, Jan 1, 2019 at 8:17 PM Ian Pilcher wrote:
>
> On 1/1/19 5:44 AM, Jérémy Rosen wrote:
> > The short answer is that Requires without after makes little sense,
> > since you can't reliably know if your dependency is here without it
> > (if it fails at startup, you might or might not be
On 1/1/19 5:44 AM, Jérémy Rosen wrote:
The short answer is that Requires without after makes little sense,
since you can't reliably know if your dependency is here without it
(if it fails at startup, you might or might not be started, depending
on the startup order systemd chooses)
There are
Am 01.01.19 um 12:44 schrieb Jérémy Rosen:
> The short answer is that Requires without after makes little sense,
> since you can't reliably know if your dependency is here without it
> (if it fails at startup, you might or might not be started, depending
> on the startup order systemd chooses)
>
On Tue, Jan 1, 2019 at 12:44 PM Jérémy Rosen wrote:
>
> The short answer is that Requires without after makes little sense,
> since you can't reliably know if your dependency is here without it
> (if it fails at startup, you might or might not be started, depending
> on the startup order systemd
The short answer is that Requires without after makes little sense,
since you can't reliably know if your dependency is here without it
(if it fails at startup, you might or might not be started, depending
on the startup order systemd chooses)
however, for backward compatibility reasons, those
Both. Otherwise your daemon can be started in parallel and be done before the
other daemon.
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Michael D. Berger m.d.ber...@ieee.org wrote:
myDaemon must start after myBaseDaemon, and must start only
if myBaseDaemon is
2011/11/9 Michael D. Berger m.d.ber...@ieee.org:
myDaemon must start after myBaseDaemon, and must start only
if myBaseDaemon is started.
Do I use:
After=myBaseDaemon
Requires=myBaseDaemon
;or only:
Requires=myBaseDaemon
?
Thanks,
Mike.
The first. Requires alone doesn't ensure
46 matches
Mail list logo
