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
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
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, 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, 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
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, 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 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, 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 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
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 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.
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, 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.
> >
> >
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, 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 02/01/2019 07:31, Michael Chapman wrote:
On Tue, 1 Jan 2019, Olaf van der Spek wrote:
Hi,
AFAIK socket units require a separate file, which seems more complex
then it has to be.
1. Could sockets be specified directly in the .service file?
If anything, I should think it would work the
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 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
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 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, 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 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 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
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
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
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
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
On Wed, 2 Jan 2019, Reindl Harald wrote:
[...]
> agreed, but why can't have socket simply optional a [Service] section to
> save the "demo@.service" in cases like below?
>
> [root@client:/etc/systemd/system]$ cat demo.socket
> [Unit]
> Description=Demo Server - Activation Socket
>
> [Socket]
>
On Wed, 2 Jan 2019, Reindl Harald wrote:
> Am 02.01.19 um 11:49 schrieb Michael Chapman:
> > On Wed, 2 Jan 2019, Reindl Harald wrote:
> > [...]
> >> agreed, but why can't have socket simply optional a [Service] section to
> >> save the "demo@.service" in cases like below?
> >>
> >>
On Wed, Jan 2, 2019 at 11:05 AM Lennart Poettering
wrote:
>
> On Di, 01.01.19 13:46, Olaf van der Spek (m...@vdspek.org) wrote:
> We could of course add redundancy here, and allow socket activation
> both with embedded information in service unit files (as you suggest)
> and with separate socket
Am 02.01.19 um 11:05 schrieb Lennart Poettering:
> On Di, 01.01.19 13:46, Olaf van der Spek (m...@vdspek.org) wrote:
>> AFAIK socket units require a separate file, which seems more complex
>> then it has to be.
>
> The main reason why socket and service units are separate is that this
> way
Am 02.01.19 um 11:49 schrieb Michael Chapman:
> On Wed, 2 Jan 2019, Reindl Harald wrote:
> [...]
>> agreed, but why can't have socket simply optional a [Service] section to
>> save the "demo@.service" in cases like below?
>>
>> [root@client:/etc/systemd/system]$ cat demo.socket
>> [Unit]
>>
On Mi, 02.01.19 11:38, Olaf van der Spek (m...@vdspek.org) wrote:
> > I mean, I am all for changing and simplifying things, and even if this
> > creates temporary redundancy, but it has to stay temporary, i.e. there
> > needs to be a clear path to a new scheme that can cover the old scheme
> >
Am 02.01.19 um 12:12 schrieb Michael Chapman:
> On Wed, 2 Jan 2019, Reindl Harald wrote:
>> Am 02.01.19 um 11:49 schrieb Michael Chapman:
>>> On Wed, 2 Jan 2019, Reindl Harald wrote:
>>> [...]
agreed, but why can't have socket simply optional a [Service] section to
save the
On Di, 01.01.19 13:46, Olaf van der Spek (m...@vdspek.org) wrote:
> Hi,
>
> AFAIK socket units require a separate file, which seems more complex
> then it has to be.
The main reason why socket and service units are separate is that this
way they may be separately scheduled. i.e. a socket can be
On Mi, 02.01.19 17:31, Michael Chapman (m...@very.puzzling.org) wrote:
> > 2. If not, could the .service file gain a default / implicit
> > dependency on the .socket file?
>
> There are a some reasons for not having a .service dependent upon its
> .socket. Many services can be started directly
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, 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
41 matches
Mail list logo
