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] .service and .socket

[Reindl Harald]

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 "demo@.service" in cases like below?

 [root@client:/etc/systemd/system]$ cat demo.socket
 [Unit]
 Description=Demo Server - Activation Socket

 [Socket]
 Accept=yes
 ListenStream=0.0.0.0:7
 ListenStream=0.0.0.0:19
 ListenStream=0.0.0.0:21

 [Service]
 Type=oneshot
 ExecStart=/usr/bin/echo "DEMO-SERVICE"
 StandardOutput=socket
 StandardInput=socket

 [Install]
 WantedBy=sockets.target
>>
>> first can you please reply only to the list so that the duplicate
>> message-filter don't rip the later coming list message after your
>> off-list copy was received breaking my reply-to-list button and threading?
> 
> I'll try to remember, but I'm likely to forget. (I use Reply-all for much 
> the reasons described in [1]. I also prefer _receiving_ Reply-all emails
> [1] http://david.woodhou.se/reply-to-list.html

get a proper mail client which knows what to do with "List-Post:
" headers

http://mailman13.u.washington.edu/pipermail/alpine-info/2014-June/005974.html

>>> Presumably things in [Unit] would only apply to the socket. What if the 
>>> service needs [Unit] directives itself? Do we really want yet another 
>>> special case ("you can embed the service inside the socket... but only if 
>>> the service doesn't need [Unit] directives")?
>>
>> why would they need only apply to the socket?
> 
> Well, consider things like After= and Before=. Yes, you could make those 
> only apply to both the socket and the service, but it wouldn't make much 
> sense. In fact, they probably should only apply to the service.

why?

there is one unit which just contains a [service] section

> But then you've got the special case that [Unit] directives inside a file 
> whose name matches *.socket don't apply to the socket, if and only if the 
> file also contains a [Service] section.
> 
> I would find that confusing.

there is no need for any distinction to begin with

when you want different directives for the two parts just use a .service
and a .socket unit as you are forced to do now and you are done and when
not use a .socket unit with a [service] section

it's that easy

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

Re: [systemd-devel] .service and .socket

[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 "demo@.service" in cases like below?
> >>
> >> [root@client:/etc/systemd/system]$ cat demo.socket
> >> [Unit]
> >> Description=Demo Server - Activation Socket
> >>
> >> [Socket]
> >> Accept=yes
> >> ListenStream=0.0.0.0:7
> >> ListenStream=0.0.0.0:19
> >> ListenStream=0.0.0.0:21
> >>
> >> [Service]
> >> Type=oneshot
> >> ExecStart=/usr/bin/echo "DEMO-SERVICE"
> >> StandardOutput=socket
> >> StandardInput=socket
> >>
> >> [Install]
> >> WantedBy=sockets.target
> 
> first can you please reply only to the list so that the duplicate
> message-filter don't rip the later coming list message after your
> off-list copy was received breaking my reply-to-list button and threading?

I'll try to remember, but I'm likely to forget. (I use Reply-all for much 
the reasons described in [1]. I also prefer _receiving_ Reply-all emails, 
since I've set up notifications when I receive personal email, but 
not when I receive list email. You're lucky I'm keeping an eye on this 
list at the moment, otherwise I probably wouldn't have seen your reply. 
Mailman deduplicates the mail for me, so I never see duplicates. 
Threading is fine since all the relevant headers are kept intact.)

[1] http://david.woodhou.se/reply-to-list.html

> > Presumably things in [Unit] would only apply to the socket. What if the 
> > service needs [Unit] directives itself? Do we really want yet another 
> > special case ("you can embed the service inside the socket... but only if 
> > the service doesn't need [Unit] directives")?
> 
> why would they need only apply to the socket?

Well, consider things like After= and Before=. Yes, you could make those 
only apply to both the socket and the service, but it wouldn't make much 
sense. In fact, they probably should only apply to the service.

But then you've got the special case that [Unit] directives inside a file 
whose name matches *.socket don't apply to the socket, if and only if the 
file also contains a [Service] section.

I would find that confusing.

> > I really don't think combining two units into one file makes things 
> > simpler.
> well, all the 5 socket-activation units i ever wrote have besides
> ExecStart boilerplate stuff to make it a valid unit

I'm just looking on my system, and most of the socket-activated services 
have their own other [Unit]-section directives in them (and not just 
Description=).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] .service and .socket

[Lennart Poettering]

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
> > too, so that the old scheme doesn't have to stay around. But this is
> > not the case here, as the current scheme is substantially more
> > powerful than what you suggest, if you follow what I mean...
>
> I'm not proposing removing the current scheme.
> The new scheme might / would increase systemd (code) complexity but
> it'd simplify end-user / conf / service / socket files.
> I agree is't not a perfect improvement (simplifying both) but it might
> still be worth it.

Well, but that's the redundancy I am talking about: we'd then have two
schemes to support for perpetuity in parallel, and that's not what I
am too fond of...

it boils down to the question, what is better:

1. just two short unit files

2. supporting a pair of two short unit files +
   supporting a single, longer unit file with some new additional
   decoration that clarifies which object let's say a setting like
   "After=" applies to (which is a setting after all which might be
   used for the socket or for the service, and in both cases valid).

I think I prefer the simplicity of #1 in this case...

Moreover, consider the unit list "systemctl" shows you when you invoke
it. Right now, it's relatively easy to figure out the relationship
between the units listed there and the unit files on disk: they mostly
map 1:1: the unit name is the file name. (within bounds, admittedly,
think templates/instances). This is a really nice property. If we'd
now allow embedding both socket and service bits into the same file,
then we'd lose that, and unit names and unit file names would start to
deviate...

> > > 2. If not, could the .service file gain a default / implicit
> > > dependency on the .socket file?
> >
> > Well, there are services that are socket-activatable and services
> > which are not.
>
> I don't follow. If they're not, would they have a .socket file?

No, but this would have to be detected. This would mean when we load a
.service we'd always have to look for any matching .socket file, and
then add an implicit dep if it exists, and none if it doesn't.

> > We'd have to determine that before we could add such a
> > dep, but that determination is problematic and not how systemd works
> > right now. Moreover there are services which have two sockets assigned
> > to them, and neither is called like the service itself. For example,
> > systemd-udevd.service is activated through the pair
> > systemd-udevd-control.socket and systemd-udevd-kernel.socket but there
> > is no systemd-udevd.socket.
>
> In that case the automatic dependency of course wouldn't be added.

But this is kinda nasty to implement, because this means we'd not only
have to search for .socket if .service is loaded but also
for basically *.socket to see if any of the socket files lists
Service=.service in it...

That would certainly be doable, but it would reverse how systemd loads
units right now. Right now it loads things lazily: only units that are
explicitly referenced are loaded, and units that are never referenced
are not, i.e. systemd doesn't load *everything* that is in
/usr/lib/systemd/system/*, but just the stuff default.target pulls in
directly and indirectly, and then adds in whatever else is
needed. This scheme is kinda nice, since it means template schemes
nicely fit into it: we can search for a matching unit template file
when a specific unit instance is requested. If we'd load everything in
advance otoh, then this could never cover templates/instances, as
during runtime any kind of instance can appear, and this always means
we need to start searching, if you follow what I mean...

Lennart

--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] .service and .socket

[Reindl Harald]

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]
>> Description=Demo Server - Activation Socket
>>
>> [Socket]
>> Accept=yes
>> ListenStream=0.0.0.0:7
>> ListenStream=0.0.0.0:19
>> ListenStream=0.0.0.0:21
>>
>> [Service]
>> Type=oneshot
>> ExecStart=/usr/bin/echo "DEMO-SERVICE"
>> StandardOutput=socket
>> StandardInput=socket
>>
>> [Install]
>> WantedBy=sockets.target

first can you please reply only to the list so that the duplicate
message-filter don't rip the later coming list message after your
off-list copy was received breaking my reply-to-list button and threading?

> Presumably things in [Unit] would only apply to the socket. What if the 
> service needs [Unit] directives itself? Do we really want yet another 
> special case ("you can embed the service inside the socket... but only if 
> the service doesn't need [Unit] directives")?

why would they need only apply to the socket?

> I really don't think combining two units into one file makes things 
> simpler.
well, all the 5 socket-activation units i ever wrote have besides
ExecStart boilerplate stuff to make it a valid unit
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] .service and .socket

[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]
> Description=Demo Server - Activation Socket
> 
> [Socket]
> Accept=yes
> ListenStream=0.0.0.0:7
> ListenStream=0.0.0.0:19
> ListenStream=0.0.0.0:21
> 
> [Service]
> Type=oneshot
> ExecStart=/usr/bin/echo "DEMO-SERVICE"
> StandardOutput=socket
> StandardInput=socket
> 
> [Install]
> WantedBy=sockets.target

Presumably things in [Unit] would only apply to the socket. What if the 
service needs [Unit] directives itself? Do we really want yet another 
special case ("you can embed the service inside the socket... but only if 
the service doesn't need [Unit] directives")?

I really don't think combining two units into one file makes things 
simpler.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] .service and .socket

[Olaf van der Spek]

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 and service unit files (as is implemented
> right now), but quite frankly this kind of redundancy just complicates
> things further... Everything comes at the price. And when the goal is
> simplification then adding redundancy and thus complexity is
> very problematic.
>
> 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
> too, so that the old scheme doesn't have to stay around. But this is
> not the case here, as the current scheme is substantially more
> powerful than what you suggest, if you follow what I mean...

I'm not proposing removing the current scheme.
The new scheme might / would increase systemd (code) complexity but
it'd simplify end-user / conf / service / socket files.
I agree is't not a perfect improvement (simplifying both) but it might
still be worth it.

> > 2. If not, could the .service file gain a default / implicit
> > dependency on the .socket file?
>
> Well, there are services that are socket-activatable and services
> which are not.

I don't follow. If they're not, would they have a .socket file?

> We'd have to determine that before we could add such a
> dep, but that determination is problematic and not how systemd works
> right now. Moreover there are services which have two sockets assigned
> to them, and neither is called like the service itself. For example,
> systemd-udevd.service is activated through the pair
> systemd-udevd-control.socket and systemd-udevd-kernel.socket but there
> is no systemd-udevd.socket.

In that case the automatic dependency of course wouldn't be added.

> > 3. AFAIK Install.WantedBy doesn't have a default. Could it get a proper 
> > default?
>
> I am not grokking this one?

It's entirely separate from 1 and 2, I should've put it in another email.

-- 
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 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] .service and .socket

[Reindl Harald]

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 they may be separately scheduled. i.e. a socket can be established
> early and only when it is triggered the matching service is pulled in
> with all its dependencies which might delay its activation. The socket
> hence can have entirely different dependencies, properties, timings,
> lifecycles than the activated services, and that's a *good* thing

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]
Accept=yes
ListenStream=0.0.0.0:7
ListenStream=0.0.0.0:19
ListenStream=0.0.0.0:21

[Service]
Type=oneshot
ExecStart=/usr/bin/echo "DEMO-SERVICE"
StandardOutput=socket
StandardInput=socket

[Install]
WantedBy=sockets.target
___
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] .service and .socket

[Lennart Poettering]

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 and will work correctly
> even when not passed any sockets from systemd.

This property is something I liked when we put this together
initially: i.e. have a service that can both act socket-activated and
in classic mode. But today I must say I don't think this particular
facet was a good idea, actually, because it creates raciness pitfalls:
if you start the service before its socket unit you get very different
behaviour then the other way round...

Lennart

--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] .service and .socket

[Lennart Poettering]

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 established
early and only when it is triggered the matching service is pulled in
with all its dependencies which might delay its activation. The socket
hence can have entirely different dependencies, properties, timings,
lifecycles than the activated services, and that's a *good* thing.

> 1. Could sockets be specified directly in the .service file?

This has been suggested before, but the ability to schedule sockets
and services independently from each other is kinda crucial (it's
pretty much what allows us to put together the whole boot process from
units, unlike for example launchd-based systems where socket
activation is suitable only for "regular" services, but not
permissible for early boot).

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 and service unit files (as is implemented
right now), but quite frankly this kind of redundancy just complicates
things further... Everything comes at the price. And when the goal is
simplification then adding redundancy and thus complexity is
very problematic.

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
too, so that the old scheme doesn't have to stay around. But this is
not the case here, as the current scheme is substantially more
powerful than what you suggest, if you follow what I mean...

> 2. If not, could the .service file gain a default / implicit
> dependency on the .socket file?

Well, there are services that are socket-activatable and services
which are not. We'd have to determine that before we could add such a
dep, but that determination is problematic and not how systemd works
right now. Moreover there are services which have two sockets assigned
to them, and neither is called like the service itself. For example,
systemd-udevd.service is activated through the pair
systemd-udevd-control.socket and systemd-udevd-kernel.socket but there
is no systemd-udevd.socket.

> 3. AFAIK Install.WantedBy doesn't have a default. Could it get a proper 
> default?

I am not grokking this one?

What you are proposing has been requested before (well, 1 + 2, I don't
understand 3), and I very much sympathize with it, and in fact is how
the design started out when we began with systemd, but I don't see how
such a scheme could cover the same ground in a nice way, without
appearing too redundant...

Lennart

--
Lennart Poettering, Red Hat
___
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] .service and .socket

[Jérémy Rosen]

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 other way around: a .socket
without any activatable .service is relatively useless.

But I'm not proposing that this actually be implemented.

A socket can trigger a service with a different name using Service=

moreover a service can be triggered by multiple sockets. It's a bit
complicated to use (check Socket= in [Service]) but it can be handy
if you want your web server to be started both by 80 and 8080



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 and will work correctly
even when not passed any sockets from systemd.


3. AFAIK Install.WantedBy doesn't have a default. Could it get a proper default?
WantedBy is valid for all units, not just services and can have lots of 
proper values, not just

default.target.

Lots of on demand daemons do not have a WantedBy at all. they have 
Also=



That doesn't make much sense.

Take your example:


xhp.service:
[Unit]
Requires=xhp.socket

[Install]
WantedBy=default.target

xhp.socket:
[Socket]
ListenStream=/run/xhp.socket

This would start xhp.service at daemon startup (i.e. boot, for the system
daemon) whether or not the service is actually required. One of the
reasons for using socket activation is to _not_ start services when
they're not required.
___
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: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