Re: [systemd-devel] Requires and After

[Jonathon Kowalski]

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 have other things it needs to wait on, it will infact wait on them and
may even produce results you get with After=).

There may be a case made about installing a job of type JOB_STOP if and
ever b.service's *activation* fails, even after a.service activates
successfully, but I wonder if people are already using Requires= alone to
just cause the explicit stop requests (which is why they might not be usinf
PartOf=) of the required unit to take down their service, and startup
dependencies don't really matter. With this change, you'd break that then.

On Thursday, January 3, 2019, Jérémy Rosen  wrote:

>
> 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 is that... everything
> is very confusing and everybody is very confused.
>
>
> I'll try to clarify the docs and create a PR for that... It seems to be
> severely needed.
>
> --
> [image: SMILE] 
>
> 20 rue des Jardins
> 92600 Asnières-sur-Seine
> *Jérémy ROSEN*
> Architecte technique
> Responsable de l'expertise Smile-ECS
>
> [image: email] jeremy.ro...@smile.fr
> [image: phone] +33141402967
> [image: url] http://www.smile.eu
>
> [image: Twitter]  [image: Facebook]
>  [image: LinkedIn]
>  [image: Github]
> 
>
> [image: Découvrez l’univers Smile, rendez-vous sur smile.eu]
> 
>
> [image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Jérémy Rosen]

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 is that... 
everything is very confusing and everybody is very confused.



I'll try to clarify the docs and create a PR for that... It seems to be 
severely needed.


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Olaf van der Spek]

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 because Reindl does not 
> have a use case in which a.service requires b.service *and* also starts 
> before b.service, is no reason to prohibit other people from configuring such 
> a use case.  That would be the purview of religious zealots and political 
> fundamentalists.
>
> Reindl might be uncomfortable with other people being "insane" and acting 
> with "wild and crazy abandon", but, ... well, it's a big world out there.
>
> In my case, for instance, I have a service unit which I use, in combination, 
> to configure hot-plug network interfaces.  The service unit makes use of a 
> target unit to sequence stages in the configuration process.  This service 
> unit Requires the target unit *and* must be run *Before* the target unit.
>
> With accumulated experience, people will learn new ways to use their tools.  
> It's just going to take time.

Use or abuse?
I don't know the details, are you sure your way is the best way to use
dependencies for your case?


-- 
Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Olaf van der Spek]

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 another
service can depend on.

-- 
Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

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 2019, Michael Chapman wrote
> >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.
> 
> Requires= alone without After= has interesting interaction with
> systemd's job machinery.
> 
> When you use Requires= alone, say from a to b (as in Michael's
> example), two start jobs will be queued for both as part of the
> transaction, but the one for a will not wait for the one for b to
> complete running. Therefore, both go in parallel, and at one point, if
> a completes before b, it will start up as usual. However, if b fails
> before a completes, the start job for a is canceled with
> JOB_DEPENDENCY job result. Hence, in your case, the job is dispatched
> right away and completes before b fails.

For what it's worth, I was quite aware of the issues in omitting any 
ordering dependency with these units. However, I was expecting a.service 
to be stopped whether or not b.service failed before or after a.service 
had become active.

I'll have to do further testing to nail down the behaviour precisely. The 
documentation certainly seems to indicate that no matter how and no matter 
when b.service gets stopped, a.service would be stopped.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[James Feeney]

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 "Requisite=" is defined in systemd but that
> doesn't mean that it's wrong or "less than optimal."

Sorry, I did not mean to imply that *I* had an issue with the term "Requisite".

Personally, my "pet peeve" is with the use of the term "Dead" to refer to units 
which are in an inactive state but which will become active in the future, as, 
for instance, logrotate.service.  These states may be viewed with "systemctl 
list-units".  For me, "dead" connotes a permanent state, in the same sense as 
"failed", in contrast to the terms "dormant", "sleeping", or "suspended".  
Something "dormant" may re-awaken.  Something that is "dead" is not going to 
"wake-up" again - except in horror movies.

I can only guess that Lennart wanted to create a more robust "hommage" to 
horror movies than that provided by the unix term "zombie".  A unix zombie 
process has no chance of being re-animated.


> 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 because Reindl does not have 
a use case in which a.service requires b.service *and* also starts before 
b.service, is no reason to prohibit other people from configuring such a use 
case.  That would be the purview of religious zealots and political 
fundamentalists.

Reindl might be uncomfortable with other people being "insane" and acting with 
"wild and crazy abandon", but, ... well, it's a big world out there.

In my case, for instance, I have a service unit which I use, in combination, to 
configure hot-plug network interfaces.  The service unit makes use of a target 
unit to sequence stages in the configuration process.  This service unit 
Requires the target unit *and* must be run *Before* the target unit.

With accumulated experience, people will learn new ways to use their tools.  
It's just going to take time.

> You could even replace "Wants=" by "Requires=" if a.service can launch
without b.service being up but cannot function without b.service being
up.

Often, the reason to choose between Wants= and Requires= is based upon the way 
units must be shut-down, not because of the way they start-up.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Reindl Harald]

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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Tom H]

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 "Requires=" and "Requisite=".
>
> 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 "Requisite=" is defined in systemd but that
doesn't mean that it's wrong or "less than optimal."

If a.service has "Requires=b.service" and b.service isn't started,
then b.service is started.

If a.service has "Requisite=b.service" and b.service isn't started
(and a.service fails).

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.

However, IIRC and IIUC, someone suggested a weird example where

- a.service can function without b.service being up and there's a
desire for b.service to start when a.service is started

- b.service cannot function without a.service being up

and where you'd therefore need "Wants=b.service" and
"Before=b.service" in a.service

You could even replace "Wants=" by "Requires=" if a.service can launch
without b.service being up but cannot function without b.service being
up.

Using "BindsTo=" ("PartOf=") in b.service rather than "Wants="
("Requires=") in a.service seems more intuitive to me from the
"Before"/"After" perspective.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Reindl Harald]

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 "Requires=" and "Requisite=".
> 
> Some developers and some users are not native English speakers. 

tell me what is opaque in case of the word require?

or better tell me a common sense usecase where you require some other
unit but don't care if it was started already and no you can't replace
common sense with documentation justify weird behavior

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[James Feeney]

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 systemd.

> How is it broken?

In the case of a service unit Requisite upon the existence of a device unit, 
systemd  will completely ignore the dependency and merrily start the service 
unit anyway, which, in this case, uselessly attempts to operate upon a 
nonexistent device.  Of course, the service unit will fail, outright, or after 
time-out, wasting compute resources, and producing lots of otherwise avoidable 
error messages.

I have not really tested Requisite= with other unit type interactions, but 
then, I also don't know of anyone actually using Requisite= with any other use 
case.  As far as I know, Requisite= is effectively a "no op".

In the past, systemd developers have not been especially motivated to fix 
Requisite=, though without actually declaring "Won't Fix" - more of a "Never 
Used It Myself, Don't Really Care".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Jonathon Kowalski]

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 JOB_DONE for
stop)), so there are races. In particular, the documentation says the
unit must be *active*. This means that starting in parallel produces
incorrect results depending on which job is chosen to be dispatched
first (which is why After= is crucial, so that the job is ordered
after theirs in the same transaction).

Hence, I fail to see what else is broken (and this is documented
behavior, so I'd say nothing is broken if you use Requisite= how it is
meant to be used).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Jonathon Kowalski]

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 dependent job fails
before the dependee completes, it will have its job cancelled with a
JOB_DEPENDENCY job result, however the transaction remains unaffected
in case of Wants=.

> Two considerations though:
> - For Wants=, it is OK to not have an ordering dependency.
>
>   So if we made Requires= imply After=, there'd be an inconsistency
>   between Requires= and Wants=.
>
> - When .requires/ is used (and .wants/ too), an After= dependency is
>   added automatically.
>
> I think we could consider making Requires= imply After=, with the
> necessary notices in NEWS, if somebody looks through units (e.g. all
> the ones packaged in Fedora), to verify that this is unlikely to break
> existing units. Elsewhere in the thread, somebody mentioned openstack,
> so that'd be first thing to check.

This is very ugly, is why I don't like this. Now, we'll have to tell
people to add After= when they use Wants= in services (in cases where
they need it), and only for that. At this point many are accustomed to
the practice of declaring ordering relationships. Now, Wants= has
different implicit ordering when configured through the filesystem
rather than the unit (and no, while the primary use case was for
targets for which it makes sense, breaking those use cases which
expected .wants links to produce no ordering effect is undesirable,
for other units).
Also, if people *are* going to do that (not that I agree), then adding
it to BindsTo= makes sense too.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[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 "Requires=" and "Requisite=".

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.

And, as I mentioned, "Requisite=" is broken in systemd, so that is a different 
issue.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Jonathon Kowalski]

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 expecting a.service to stop because
>b.service failed, but apparently my understanding of this isn't quite
>right.

Requires= alone without After= has interesting interaction with
systemd's job machinery.

When you use Requires= alone, say from a to b (as in Michael's
example), two start jobs will be queued for both as part of the
transaction, but the one for a will not wait for the one for b to
complete running. Therefore, both go in parallel, and at one point, if
a completes before b, it will start up as usual. However, if b fails
before a completes, the start job for a is canceled with
JOB_DEPENDENCY job result. Hence, in your case, the job is dispatched
right away and completes before b fails.

This is also why targets that usually gain deps through filesystem
symlinks have an implicit ordering by default, as defining ordering
through that mechanism is not possible.

Now, answering why explicitly stopping b stops a? This is how
Requires= is actually supposed to work. Infact, this is perhaps the
only noticeable difference for end users between Requires= and
BindsTo= (however there are a few other things to keep in mind).

- Jonathon Kowalski
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

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 started too, but B cannot 
> > function without A being active.
> 
> this is insane

Please reduce your hyperbole.

> when B cannot work without A then B wants A and not the other way

I should have probably been more precise with "cannot function". B can 
actually function without A. It's just useless if it were to do so.

Moreover, the fact that B is started as a side-effect of starting A is 
important. I _do not_ want to have to start B explicitly. As I noted in 
another email, I've got some systems where B does not even exist. Having 
every system just have an A.timer that starts A (and on some of them, B as 
well) is very convenient.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Reindl Harald]

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 A being active.

this is insane

when B cannot work without A then B wants A and not the other way


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Reindl Harald]

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 by "soft dependency" and "hard dependency"?  It 
> sounds like you are calling an ordering dependency "soft" and an activation 
> dependency "hard".
> 
> I'm sorry, I do not understand what you mean by "makes no sense not imply 
> ordering".  Do you mean "to not imply ordering makes no sense"?  In which 
> case, are you saying that "an activation dependency must imply an ordering"?  
> That would not be true.  Activating a unit does not automatically imply or 
> require that that unit be activated or deactivated in any particular order 
> relative to any other unit.

what do you not understand?

when i say "Requires=b.service" common sense says i mean *it is
required* and so the "After=b.service" should not be needed because it's
pretty obvious when i REQUIRE something that it should be there when i
get started


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

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.
> >
> > Requisite= propagates a "start" or "restart" job as a "verify-active" job.
> > In other words, it only checks that the other unit is active, failing the
> > activation of the current unit if necessary.
> >
> > Requires= propagates these as "start" jobs, activating the other unit if
> > it is not already active.
> 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...

Let's try it out!

$ systemctl --user cat a.service
# /home/mchapman/.config/systemd/user/a.service
[Unit]
Requires=b.service

[Service]
ExecStart=/bin/true
RemainAfterExit=true

$ systemctl --user cat b.service
# /home/mchapman/.config/systemd/user/b.service
[Service]
ExecStart=/bin/false
RemainAfterExit=true

$ systemctl --user start b.service

No error here, since a Type=oneshot service is always immediately active. 
But it did fail, as expected:

$ systemctl --user status b.service
* b.service
   Loaded: loaded (/home/mchapman/.config/systemd/user/b.service; static; 
vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2019-01-02 20:29:53 AEDT; 
7s ago
  Process: 512 ExecStart=/bin/false (code=exited, status=1/FAILURE)
 Main PID: 512 (code=exited, status=1/FAILURE)

Jan 02 20:29:53 beren.home systemd[2618]: Started b.service.
Jan 02 20:29:53 beren.home systemd[2618]: b.service: Main process exited, 
code=exited, status=1/FAILURE
Jan 02 20:29:53 beren.home systemd[2618]: b.service: Unit entered failed 
state.
Jan 02 20:29:53 beren.home systemd[2618]: b.service: Failed with result 
'exit-code'.

So what happens if we now try to start a.service?

$ systemctl --user start a.service
$ systemctl --user status a.service
* a.service
  Loaded: loaded (/home/mchapman/.config/systemd/user/a.service; static; 
vendor preset: enabled)
  Active: active (exited) since Wed 2019-01-02 20:30:08 AEDT; 2s ago
 Process: 544 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 544 (code=exited, status=0/SUCCESS)

Jan 02 20:30:08 beren.home systemd[2618]: Started a.service.

It was successful! But you can see that it was unable to start b.service a 
second time:

$ systemctl --user status b.service
* b.service
   Loaded: loaded (/home/mchapman/.config/systemd/user/b.service; static; 
vendor preset: enabled)
   Active: failed (Result: exit-code) since Wed 2019-01-02 20:30:08 AEDT; 
4s ago
  Process: 545 ExecStart=/bin/false (code=exited, status=1/FAILURE)
 Main PID: 545 (code=exited, status=1/FAILURE)

Jan 02 20:30:08 beren.home systemd[2618]: Started b.service.
Jan 02 20:30:08 beren.home systemd[2618]: b.service: Main process exited, 
code=exited, status=1/FAILURE
Jan 02 20:30:08 beren.home systemd[2618]: b.service: Unit entered failed 
state.
Jan 02 20:30:08 beren.home systemd[2618]: b.service: Failed with result 
'exit-code'.

However, explicitly stopping b.service causes a.service to be stopped:

$ systemctl stop --user b.service
[mchapman@beren ~]$ systemctl --user status a.service
* a.service
   Loaded: loaded (/home/mchapman/.config/systemd/user/a.service; static; 
vendor preset: enabled)
   Active: inactive (dead)

Jan 02 20:33:33 beren.home systemd[2618]: Stopped a.service.

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.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Jérémy Rosen]

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 other words, it only checks that the other unit is active, failing the
activation of the current unit if necessary.

Requires= propagates these as "start" jobs, activating the other unit if
it is not already active.
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...
--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

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 the other
> > unit.
> >
> > ConsistsOf= (the inverse of PartOf=) propagates "stop" and "restart" jobs
> > as "stop" and "try-restart" jobs respectively on the other unit.
> >
> > So Wants= configures activation dependencies in one direction, and
> > PartOf= configures deactivation dependencies in the other direction.
> >
> > (I'm taking this from transaction_add_job_and_dependencies in
> > src/core/transaction.c, if anybody wants to check my working.)
> 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 other words, it only checks that the other unit is active, failing the 
activation of the current unit if necessary.

Requires= propagates these as "start" jobs, activating the other unit if 
it is not already active.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Jérémy Rosen]

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 "restart" jobs
as "stop" and "try-restart" jobs respectively on the other unit.

So Wants= configures activation dependencies in one direction, and
PartOf= configures deactivation dependencies in the other direction.

(I'm taking this from transaction_add_job_and_dependencies in
src/core/transaction.c, if anybody wants to check my working.)

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...


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

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 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= would prevent.
> 
> That being said... the fact that Requires influences both startup and 
> restart/shutdown makes things a bit more complicated...
>
> From reading the documentation it seems that Requires without After is 
> equivalent to PartOf and thus is suspicious (if you want PartOf, you 
> should use PartOf, if you want Requires, the you should also use After)

Well, PartOf= doesn't provide any forward activation dependencies, so it's 
not exactly equivalent.

> This means that there are cases to be checked for but I still globally 
> think that Requires without After is suspicious, and that an implicit 
> order would make sense... but that's just my opinion and I am still a 
> bit confused about the fine-details of what Requires does.
> 
> my understanding is
> 
> 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 "restart" jobs 
as "stop" and "try-restart" jobs respectively on the other unit.

So Wants= configures activation dependencies in one direction, and 
PartOf= configures deactivation dependencies in the other direction.

(I'm taking this from transaction_add_job_and_dependencies in 
src/core/transaction.c, if anybody wants to check my working.)___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Jérémy Rosen]

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 A.
This is the race the implicit After= would prevent.

There is no such race as Requires without After doesn't stop A from
starting (as it can't).

>From the docs:
If one of the other units fails to activate, and an ordering
dependency After= on the failing unit is set, this unit will not be
started.

you sure about that ? I mean... that's what the doc says, but that
would mean that requires without after is like Wants+PartOf

that's kinda weird. maybe it's an aritifact from early systemd, but
it sounds kinda inconsistent...


Also it means that if you start A, this will start B

if B fails, A is still started ? I don't think a failure of B schedules 
a shutdown of A



This whole thing is very confusing...

--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

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 assume one way or the other.
> >
> 
> > 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 A being active.
> 
> And A can't function without B being active? So basically a circular 
> dependency?

No, not a circular dependency. A can function without B. I just want B   
to start whenever A starts, but I want B to start _after_ A starts.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Olaf van der Spek]

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= would prevent.

There is no such race as Requires without After doesn't stop A from
starting (as it can't).

From the docs:
If one of the other units fails to activate, and an ordering
dependency After= on the failing unit is set, this unit will not be
started.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

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 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 A being active.
> 
> But this really means that B.service should have After=A.service +
> Requires=A.service. Having A.service/start automatically imply B.service/start
> is just unnecessary magic.

In my particular case the magic is quite useful. Specifically, only _some_ 
of my systems need B.service. I don't want to have to think "on this 
system I need to start A, but on this system I need to start B and let it 
automatically start A".

I could imagine also it'd be useful if B.service had some ConditionFoo= 
directive, since that won't prevent A.service from being started even if 
it had Requires=B.service.

> > So here's an example where the activation dependency is essentially 
> > "opposite" that of the ordering dependency.
> > 
> > As you've pointed out, Requires= a bit of a strange case. If I change the 
> > above situation to use Requires= instead, and if B subsequently exits or 
> > fails, A would be stopped. I don't have an immediate use for that, but I 
> > think it's a bit presumptuous to assume that no use could possibly exist.
> > 
> > I think there's use in having Wants= and Requires= work similarly to each 
> > other, in that they are both orthogonal to ordering dependencies. It would 
> > be odd to have only one imply an ordering dependency.
> 
> If we made Requires= imply After=, it'd be a "default" dependency, so an
> explicit Before= would prevent the After= from being added. (This is the same
> as for .wants/ and .after/ directories: an ordering dependency is added, if
> DefaultDependencies=yes, and if Before= was not added to invert the ordering.)
> So a "reverse" orderding like you describe would still be possible.

OK. I'm still not convinced the inconsistency is worth it (it's hard 
enough explaining the existing logic, now we're thinking about adding 
_more_ exceptional cases!), but if it can be overridden it's not too bad.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Jérémy Rosen]

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 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= would prevent.

That being said... the fact that Requires influences both startup and 
restart/shutdown makes things a

bit more complicated...

From reading the documentation it seems that Requires without After is 
equivalent to PartOf and
thus is suspicious (if you want PartOf, you should use PartOf, if you 
want Requires, the you should

also use After)

This means that there are cases to be checked for but I still globally 
think that Requires without
After is suspicious, and that an implicit order would make sense... but 
that's just my opinion and

I am still a bit confused about the fine-details of what Requires does.

my understanding is

Requires = Wants + Requisite + PartOf

is that correct ?

Regards
Jérémy


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Olaf van der Spek]

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 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 A being active.

And A can't function without B being active? So basically a circular dependency?

> So here's an example where the activation dependency is essentially
> "opposite" that of the ordering dependency.

Not entirely, as I assume B Wants A too.

> As you've pointed out, Requires= a bit of a strange case. If I change the
> above situation to use Requires= instead, and if B subsequently exits or
> fails, A would be stopped. I don't have an immediate use for that, but I
> think it's a bit presumptuous to assume that no use could possibly exist.
>
> I think there's use in having Wants= and Requires= work similarly to each
> other,

I agree

> in that they are both orthogonal to ordering dependencies.

I don't agree ;)

> It would
> be odd to have only one imply an ordering dependency.
>
> Moreover, we can't simply change what systemd does here: it would be a
> backward-incompatible change. We don't want that.

It's 2019.. I'm sure we can improve without that being a showstopper.

-- 
Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Zbigniew Jędrzejewski-Szmek]

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.
> > >
> > > An activation dependency does not, a priori, have to obey any rules 
> > > about ordering.  There are not, automatically, any promises or 
> > > guarantees about in what order service units, for instance, might be 
> > > queued for execution, based upon a Requires= dependency.
> > >
> > > "Ordering" is an independent characteristic from "Activation".  
> > > "Activation" only promises to enqueue a unit, and then, only if the 
> > > unit is some kind of unit that can be "executed", such as a timer or 
> > > service unit.  In contrast, for instance, systemd is only a "passive 
> > > observer" of a device unit.  "enqueuing" a device unit for 
> > > "activation" would make no sense in this context.  A *service* unit 
> > > that *creates* a device unit could be enqueued for activation, but not 
> > > the device unit itself.
> > >
> > > If "A Requires B", and you don't like that "A" *might* get enqueued, 
> > > or get executed, before "B", then add an "ordering" dependency.  
> > > "Ordering dependencies", then, create guarantees about unit activation 
> > > *ordering*.
> > 
> > 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 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 A being active.

But this really means that B.service should have After=A.service +
Requires=A.service. Having A.service/start automatically imply B.service/start
is just unnecessary magic.

> So here's an example where the activation dependency is essentially 
> "opposite" that of the ordering dependency.
> 
> As you've pointed out, Requires= a bit of a strange case. If I change the 
> above situation to use Requires= instead, and if B subsequently exits or 
> fails, A would be stopped. I don't have an immediate use for that, but I 
> think it's a bit presumptuous to assume that no use could possibly exist.
> 
> I think there's use in having Wants= and Requires= work similarly to each 
> other, in that they are both orthogonal to ordering dependencies. It would 
> be odd to have only one imply an ordering dependency.

If we made Requires= imply After=, it'd be a "default" dependency, so an
explicit Before= would prevent the After= from being added. (This is the same
as for .wants/ and .after/ directories: an ordering dependency is added, if
DefaultDependencies=yes, and if Before= was not added to invert the ordering.)
So a "reverse" orderding like you describe would still be possible.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

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
> > that unit in After too, otherwise the requirement isn't really met.
> > Is there a use case for Requires but not After?
> > If not, would it make sense to change semantics to have Requires imply 
> > After?
> 
> 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.

Only on service activation though.

During deactivation, RequiredBy= dependencies (but not WantedBy= 
dependencies) are followed to enqueue further deactivation jobs.

> Two considerations though:
> - For Wants=, it is OK to not have an ordering dependency.
> 
>   So if we made Requires= imply After=, there'd be an inconsistency
>   between Requires= and Wants=.
> 
> - When .requires/ is used (and .wants/ too), an After= dependency is
>   added automatically.
> 
> I think we could consider making Requires= imply After=, with the
> necessary notices in NEWS, if somebody looks through units (e.g. all
> the ones packaged in Fedora), to verify that this is unlikely to break
> existing units. Elsewhere in the thread, somebody mentioned openstack,
> so that'd be first thing to check.

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.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Zbigniew Jędrzejewski-Szmek]

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.
> Is there a use case for Requires but not After?
> If not, would it make sense to change semantics to have Requires imply After?

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.

Two considerations though:
- For Wants=, it is OK to not have an ordering dependency.

  So if we made Requires= imply After=, there'd be an inconsistency
  between Requires= and Wants=.

- When .requires/ is used (and .wants/ too), an After= dependency is
  added automatically.

I think we could consider making Requires= imply After=, with the
necessary notices in NEWS, if somebody looks through units (e.g. all
the ones packaged in Fedora), to verify that this is unlikely to break
existing units. Elsewhere in the thread, somebody mentioned openstack,
so that'd be first thing to check.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

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 something about what Requires does (shutdown ?) but at that
> point, Wants would be a better dependency, no ?

If a unit Requires=other.service, any stop or restart job for 
other.service is propagated back to this unit (the latter as try-restart). 
This does not occur with Wants=.

In _most_ cases this back-propagation isn't needed, which is why Wants= is 
generally preferred.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Jérémy Rosen]

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 that point, Wants would be a better dependency, no ?


--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Michael Chapman]

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 
> > about ordering.  There are not, automatically, any promises or 
> > guarantees about in what order service units, for instance, might be 
> > queued for execution, based upon a Requires= dependency.
> >
> > "Ordering" is an independent characteristic from "Activation".  
> > "Activation" only promises to enqueue a unit, and then, only if the 
> > unit is some kind of unit that can be "executed", such as a timer or 
> > service unit.  In contrast, for instance, systemd is only a "passive 
> > observer" of a device unit.  "enqueuing" a device unit for 
> > "activation" would make no sense in this context.  A *service* unit 
> > that *creates* a device unit could be enqueued for activation, but not 
> > the device unit itself.
> >
> > If "A Requires B", and you don't like that "A" *might* get enqueued, 
> > or get executed, before "B", then add an "ordering" dependency.  
> > "Ordering dependencies", then, create guarantees about unit activation 
> > *ordering*.
> 
> 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 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 A being active.

So here's an example where the activation dependency is essentially 
"opposite" that of the ordering dependency.

As you've pointed out, Requires= a bit of a strange case. If I change the 
above situation to use Requires= instead, and if B subsequently exits or 
fails, A would be stopped. I don't have an immediate use for that, but I 
think it's a bit presumptuous to assume that no use could possibly exist.

I think there's use in having Wants= and Requires= work similarly to each 
other, in that they are both orthogonal to ordering dependencies. It would 
be odd to have only one imply an ordering dependency.

Moreover, we can't simply change what systemd does here: it would be a 
backward-incompatible change. We don't want that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Olaf van der Spek]

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 promises or guarantees about in 
> what order service units, for instance, might be queued for execution, based 
> upon a Requires= dependency.
>
> "Ordering" is an independent characteristic from "Activation".  "Activation" 
> only promises to enqueue a unit, and then, only if the unit is some kind of 
> unit that can be "executed", such as a timer or service unit.  In contrast, 
> for instance, systemd is only a "passive observer" of a device unit.  
> "enqueuing" a device unit for "activation" would make no sense in this 
> context.  A *service* unit that *creates* a device unit could be enqueued for 
> activation, but not the device unit itself.
>
> If "A Requires B", and you don't like that "A" *might* get enqueued, or get 
> executed, before "B", then add an "ordering" dependency.  "Ordering 
> dependencies", then, create guarantees about unit activation *ordering*.

What good is an activation dependency without an ordering dependency?
Activation by itself guarantees basically nothing.

>> . 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?

> Are you sure that you were not wondering about "Requisite=", instead of 
> "Requires="?

Yes, I am, though Requisite looks interesting too.

> Because, as far as I know, "Requisite=" is completely broken in systemd.

How is it broken?


-- 
Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[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 by "soft dependency" and "hard dependency"?  It 
sounds like you are calling an ordering dependency "soft" and an activation 
dependency "hard".

I'm sorry, I do not understand what you mean by "makes no sense not imply 
ordering".  Do you mean "to not imply ordering makes no sense"?  In which case, 
are you saying that "an activation dependency must imply an ordering"?  That 
would not be true.  Activating a unit does not automatically imply or require 
that that unit be activated or deactivated in any particular order relative to 
any other unit.

Did you also mean to say "If a unit is not active or does not exist then the 
ordering of that unit does not matter"?  Well, the "ordering" of a nonexistent 
unit would not have any meaning.

However there is also the case of an active unit that may become inactive, in 
addition to the case of an inactive unit that may become active.  While the 
order of activation or deactivation, relative to other units, of a unit that 
exists has meaning, that order may not, a priori, be of any importance or 
consequence.  But I would not go so far as to say that the order of activation 
of an inactive unit does not matter.  The order of activation of an inactive 
unit may actually be important, in which case, an ordering dependency can be 
specified.

So, I think that I am missing your point, with respect to "soft" and "hard" 
dependencies.  Maybe you could express your meaning in another way?

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[James Feeney]

> 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 suggest that, no - or you would not be asking this question.

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 promises or guarantees about in 
what order service units, for instance, might be queued for execution, based 
upon a Requires= dependency.

"Ordering" is an independent characteristic from "Activation".  "Activation" 
only promises to enqueue a unit, and then, only if the unit is some kind of 
unit that can be "executed", such as a timer or service unit.  In contrast, for 
instance, systemd is only a "passive observer" of a device unit.  "enqueuing" a 
device unit for "activation" would make no sense in this context.  A *service* 
unit that *creates* a device unit could be enqueued for activation, but not the 
device unit itself.

If "A Requires B", and you don't like that "A" *might* get enqueued, or get 
executed, before "B", then add an "ordering" dependency.  "Ordering 
dependencies", then, create guarantees about unit activation *ordering*.

Are you sure that you were not wondering about "Requisite=", instead of 
"Requires="?  Because, as far as I know, "Requisite=" is completely broken in 
systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Reindl Harald]

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 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 cases where it makes sense.  For example, most OpenStack
>>> services require both a message bus and a database, but they are smart
>>> enough to wait and re-attempt their connections if either of those
>>> services isn't immediately available.
>>
>> 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.

assumption or measured benefit?

most error handling for such cases has some sleep time which tyically
makes things slower than work with the initalization until everything is
in a proper state


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[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 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 cases where it makes sense.  For example, most OpenStack
> > services require both a message bus and a database, but they are smart
> > enough to wait and re-attempt their connections if either of those
> > services isn't immediately available.
> 
> 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.

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Olaf van der Spek]

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 started, depending
> > on the startup order systemd chooses)
>
> There are cases where it makes sense.  For example, most OpenStack
> services require both a message bus and a database, but they are smart
> enough to wait and re-attempt their connections if either of those
> services isn't immediately available.

What's the benefit of not having After= for those services?


-- 
Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Ian Pilcher]

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 cases where it makes sense.  For example, most OpenStack
services require both a message bus and a database, but they are smart
enough to wait and re-attempt their connections if either of those
services isn't immediately available.

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Reindl Harald]

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)
> 
> however, for backward compatibility reasons, those two will most
> likely stay separate.
> 
> I think a bigger warning in the docs that those two should usually
> be used together would be welcomed.

why?

if it makes little sense than act useful and just make the After
implicit when Requires is in use, it won't harm any "backward
compatibility reasons" which have the After anyways

> On 30/12/2018 12:05, Olaf van der Spek wrote:
>> 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.
>> Is there a use case for Requires but not After?
>> If not, would it make sense to change semantics to have Requires imply After?
>>
>> Requires and After are a common source of confusion:
>> https://serverfault.com/questions/812584/in-systemd-whats-the-difference-between-after-and-requires
>> https://unix.stackexchange.com/questions/388586/systemd-requires-vs-wants
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Olaf van der Spek]

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 chooses)

According to the docs that one doesn't depend on ordering. See how
complicated this is? ;)

>  If one of the other units fails to activate, and an ordering dependency 
> After= on the failing unit is set, this unit will not be started.

> however, for backward compatibility reasons, those two will most
> likely stay separate.
>
> I think a bigger warning in the docs that those two should usually
> be used together would be welcomed.

IMO docs are not a solution, especially long-term.

Greetings,

Olaf
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[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)

however, for backward compatibility reasons, those two will most
likely stay separate.

I think a bigger warning in the docs that those two should usually
be used together would be welcomed.

Cheers
Jeremy

On 30/12/2018 12:05, 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.
Is there a use case for Requires but not After?
If not, would it make sense to change semantics to have Requires imply After?

Requires and After are a common source of confusion:
https://serverfault.com/questions/812584/in-systemd-whats-the-difference-between-after-and-requires
https://unix.stackexchange.com/questions/388586/systemd-requires-vs-wants



--
SMILE 

20 rue des Jardins
92600 Asnières-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email jeremy.ro...@smile.fr 
phone +33141402967
url http://www.smile.eu

Twitter  Facebook 
 LinkedIn 
 Github 




Découvrez l’univers Smile, rendez-vous sur smile.eu 



eco Pour la planète, n'imprimez ce mail que si c'est nécessaire
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Manuel Amador (Rudd-O)]

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 started.

Do I use:
After=myBaseDaemon
Requires=myBaseDaemon 
;or only:
Requires=myBaseDaemon
?

Thanks,
Mike.

--
Michael D. Berger
m.d.ber...@ieee.org
http://www.rosemike.net/


_

systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Requires and After

[Mirco Tischler]

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 the ordering.

Mirco
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel