Re: [systemd-devel] Still confused with socket activation

2021-02-06 Thread Andrei Borzenkov
04.02.2021 17:53, Simon McVittie пишет:
> On Thu, 04 Feb 2021 at 13:07:33 +0100, Reindl Harald wrote:
>> "Requires=a.service" combined with "Before=a.service" is contradictory -
>> don't you get that?
> 
> It means what it says: whenever my service is enabled, a.service must
> also be enabled, but my service has to start first (and stop last).
> 

Nitpicking - you probably mean "activated", not "enabled". "enabled"
means something entirely different in systemd (at least above config
directives are not related to "enabling" unit).

> For instance, imagine this scenario:
> 
> * my service sets something up that will trigger an action later:
>   perhaps it creates a configuration fragment in a.conf.d
> 
> * any number of other services might be doing the same as my service
> 
> * whenever at least one service has done that, when they have all finished
>   doing their setup, we need to start a.service, which will take those
>   triggers (e.g. contents of a.conf.d) and "commit" whatever is needed
>   for all of them
> 
> * if multiple services have set up a triggered action, we only want to
>   run a.service once, and it will act on all the triggers as a batch
> 

This is racy. If one of other services is activated when a.service is
already being activated due to other service, it is unpredictable
whether a.service will pick changes made by all other services. The only
way to ensure that all other services are being activated together with
(and finished before) a.service is to have a.service
Wants(Requires)/After them (or WantedBy(RequiredBy)=a.service in all of
them).

> Then my service should have Requires=a.service (because if a.service
> never runs, the "commit" action will never happen and my service will
> not do what I wanted); and it should have Before=a.service (because the
> triggers need to be in place before a.service processes them).
> 

If you never activate a.service explicitly you also never know whether
it completed successfully or not. You only have status of "some other
service" and it will fail only if a.service definition is missing; it
won't tell you anything about result of a.service itself.

While this is interesting exercise, it is really stretching systemd
dependency systems way beyond what it was deigned for.

> dpkg and RPM triggers are not (currently!) systemd services, but they
> work a lot like this. They're typically used to regenerate caches.
> 
> Another reason to combine Requires with Before is that Before is really
> a short name for "start before and stop after", and After is really a
> short name for "start after and stop before". If you're dealing with
> actions taken during system shutdown or session logout, the stop action
> might be the one that does the real work, making it more likely that
> Before dependencies are the important ones.
> 
> smcv
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

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


Re: [systemd-devel] Still confused with socket activation

2021-02-05 Thread Benjamin Berg
On Thu, 2021-02-04 at 22:16 +0300, Andrei Borzenkov wrote:
> 03.02.2021 22:25, Benjamin Berg пишет:
> > Requires= actually has the difference that the unit must become
> > part of
> > the transaction (if it is not active already). So you get a hard
> > failure and appropriate logging if the unit cannot be added to the
> > transaction for some reason.
> > 
> 
> Oh, I said "documented" :) systemd documentation does not even define
> what "transaction" is. You really need to know low level implementation
> details to use it in this way.
> 
> But thank you, I missed this subtlety. Of course another reason could be
> stop behavior.

Oh, good point! I really had not been considering the implication on
stop behaviour. :)

Benjamin

> > > Care to show more complete example and explain why Wants does not
> > > work in this case?
> > 
> > Wants= would work fine. I think it boils down to whether you find
> > the
> > extra assertions useful. The Requires= documentation actually
> > suggests
> > using Wants= exactly to avoid this.
> > 
> > Benjamin
> > 
> 
> 



signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Still confused with socket activation

2021-02-04 Thread Andrei Borzenkov
03.02.2021 22:25, Benjamin Berg пишет:
> On Wed, 2021-02-03 at 20:47 +0300, Andrei Borzenkov wrote:
>> 03.02.2021 00:25, Benjamin Berg пишет:
>>> On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote:
 02.02.2021 17:59, Lennart Poettering пишет:
>
> Note that Requires= in almost all cases should be combined with
> an
> order dep of After= onto the same unit.

 Years ago I asked for example when Requires makes sense without
 After.
 Care to show it? I assume you must have use case if you say "in
 almost all".
>>>
>>> In the GNOME systemd units there are a few places where a Requires=
>>> is
>>> combined with Before=.
>>>
>>
>> This is functionally completely equivalent to simply using
>> Wants+Before.
>> At least as long as you rely on *documented* functions.
> 
> Requires= actually has the difference that the unit must become part of
> the transaction (if it is not active already). So you get a hard
> failure and appropriate logging if the unit cannot be added to the
> transaction for some reason.
> 

Oh, I said "documented" :) systemd documentation does not even define
what "transaction" is. You really need to know low level implementation
details to use it in this way.

But thank you, I missed this subtlety. Of course another reason could be
stop behavior.

>> Care to show more complete example and explain why Wants does not
>> work in this case?
> 
> Wants= would work fine. I think it boils down to whether you find the
> extra assertions useful. The Requires= documentation actually suggests
> using Wants= exactly to avoid this.
> 
> Benjamin
> 




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Still confused with socket activation

2021-02-04 Thread Simon McVittie
On Thu, 04 Feb 2021 at 13:07:33 +0100, Reindl Harald wrote:
> "Requires=a.service" combined with "Before=a.service" is contradictory -
> don't you get that?

It means what it says: whenever my service is enabled, a.service must
also be enabled, but my service has to start first (and stop last).

For instance, imagine this scenario:

* my service sets something up that will trigger an action later:
  perhaps it creates a configuration fragment in a.conf.d

* any number of other services might be doing the same as my service

* whenever at least one service has done that, when they have all finished
  doing their setup, we need to start a.service, which will take those
  triggers (e.g. contents of a.conf.d) and "commit" whatever is needed
  for all of them

* if multiple services have set up a triggered action, we only want to
  run a.service once, and it will act on all the triggers as a batch

Then my service should have Requires=a.service (because if a.service
never runs, the "commit" action will never happen and my service will
not do what I wanted); and it should have Before=a.service (because the
triggers need to be in place before a.service processes them).

dpkg and RPM triggers are not (currently!) systemd services, but they
work a lot like this. They're typically used to regenerate caches.

Another reason to combine Requires with Before is that Before is really
a short name for "start before and stop after", and After is really a
short name for "start after and stop before". If you're dealing with
actions taken during system shutdown or session logout, the stop action
might be the one that does the real work, making it more likely that
Before dependencies are the important ones.

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


Re: [systemd-devel] Still confused with socket activation

2021-02-04 Thread Benjamin Berg
On Thu, 2021-02-04 at 13:07 +0100, Reindl Harald wrote:
> Am 04.02.21 um 12:46 schrieb Benjamin Berg:
> > On Wed, 2021-02-03 at 16:43 +0100, Reindl Harald wrote:
> > > seriously - explain what you expect to happen in case of
> > > 
> > > Requires=a.service
> > > Before=a.service
> > > 
> > > except some warning that it's nonsense
> > 
> > So, one way I used it is as ExecStartPost= equivalent for a .target
> > unit. i.e. pull in a Type=oneshot service once a target has become
> > active in order to execute a simple command
> 
> "Requires=a.service" combined with "Before=a.service" is
> contradictory - 
> don't you get that?

Your statements will not become more informed by repeating them.

It looks to me like you are interpreting Requires= incorrectly. Of
course, one can see a contradiction in saying "B requires A in order to
run" and then also saying "start A after B is ready".

But systemd considers requirements and ordering as two independent
problems. As such "Requires=A" only means something like "unit A must
be added to the transaction together with B". A statement that does not
imply ordering.

Yes, this is a a very logical/mathematical meaning which may not be
what you intuitively expect. And it does have the unfortunate side
effect of sometimes confusing people and they forget to add a needed
After= that they thought was implied.

But, it is well defined what happens when combining Requires= with
Before=. There is no contradiction.

Benjamin


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Still confused with socket activation

2021-02-04 Thread Reindl Harald




Am 04.02.21 um 12:46 schrieb Benjamin Berg:

On Wed, 2021-02-03 at 16:43 +0100, Reindl Harald wrote:

seriously - explain what you expect to happen in case of

Requires=a.service
Before=a.service

except some warning that it's nonsense


So, one way I used it is as ExecStartPost= equivalent for a .target
unit. i.e. pull in a Type=oneshot service once a target has become
active in order to execute a simple command



"Requires=a.service" combined with "Before=a.service" is contradictory - 
don't you get that?

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


Re: [systemd-devel] Still confused with socket activation

2021-02-04 Thread Benjamin Berg
On Wed, 2021-02-03 at 16:43 +0100, Reindl Harald wrote:
> seriously - explain what you expect to happen in case of
> 
> Requires=a.service
> Before=a.service
> 
> except some warning that it's nonsense

So, one way I used it is as ExecStartPost= equivalent for a .target
unit. i.e. pull in a Type=oneshot service once a target has become
active in order to execute a simple command.

Benjamin


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Still confused with socket activation

2021-02-03 Thread Benjamin Berg
On Wed, 2021-02-03 at 20:47 +0300, Andrei Borzenkov wrote:
> 03.02.2021 00:25, Benjamin Berg пишет:
> > On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote:
> > > 02.02.2021 17:59, Lennart Poettering пишет:
> > > > 
> > > > Note that Requires= in almost all cases should be combined with
> > > > an
> > > > order dep of After= onto the same unit.
> > > 
> > > Years ago I asked for example when Requires makes sense without
> > > After.
> > > Care to show it? I assume you must have use case if you say "in
> > > almost all".
> > 
> > In the GNOME systemd units there are a few places where a Requires=
> > is
> > combined with Before=.
> > 
> 
> This is functionally completely equivalent to simply using
> Wants+Before.
> At least as long as you rely on *documented* functions.

Requires= actually has the difference that the unit must become part of
the transaction (if it is not active already). So you get a hard
failure and appropriate logging if the unit cannot be added to the
transaction for some reason.

> Care to show more complete example and explain why Wants does not
> work in this case?

Wants= would work fine. I think it boils down to whether you find the
extra assertions useful. The Requires= documentation actually suggests
using Wants= exactly to avoid this.

Benjamin



signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Still confused with socket activation

2021-02-03 Thread Andrei Borzenkov
03.02.2021 21:13, Andrei Borzenkov пишет:
> 02.02.2021 12:43, Ulrich Windl пишет:
>> Hi!
>>
>> Having:
>> ---
>> # /usr/lib/systemd/system/virtlockd.service
>> [Unit]
>> Description=Virtual machine lock manager
>> Requires=virtlockd.socket
>> Requires=virtlockd-admin.socket
> 
> That's always wrong with After for the same units 
s/with/without/

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


Re: [systemd-devel] Still confused with socket activation

2021-02-03 Thread Andrei Borzenkov
02.02.2021 12:43, Ulrich Windl пишет:
> Hi!
> 
> Having:
> ---
> # /usr/lib/systemd/system/virtlockd.service
> [Unit]
> Description=Virtual machine lock manager
> Requires=virtlockd.socket
> Requires=virtlockd-admin.socket

That's always wrong with After for the same units unless you can prove
that both socket units are always ordered Before service unit due to
dependency chain, at least if intention is to ensure socket units are
active *before* service unit. In real life nobody notices it because
both sockets are started much earlier which papers over race condition.

And if after 10 years of software existence everyone still gets it wrong
I strongly suspect something is not right with software, not with everyone.

> Before=libvirtd.service
> ...
> ---
> 
> How would I start both sockets successfully unter program control?

I do not understand what you want to say here, sorry. What "program
control" means? What exactly are you trying to do?

> If I start one socket, I cannot start the other without an error (as 
> libvirtd.service is running already, see my earlier message from last week).

I do not see how starting socket unit is related to starting service
unit. Unless there was incoming traffic on socket. Also I do not
understand why you need to start socket units if you *already* started
service unit. Again, you do not really provide much coherent information
to do any suggestion.

And I do not really understand the reason to use two different socket
units that apparently are always started together and activate the same
service. Just create single socket unit that listens on both sockets.

> If I mask the socket units, I cannot start the libvirtd.service.
> So would I disable the socket units and start libvirtd.service?

You misunderstand what "disable" means in systemd (see remark above).
You cannot disable (in common sense) starting of socket units together
with virtlockd.service because starting of virtlockd.service will always
attempt to start both socket units (that is exactly what Requires/Wants
are about).

Actually if they are "enabled" (in systemd sense) then they are started
very early during boot, long before service unit. What exact problem you
have in this case?

> Unfortunately if someone (update when vendor-preset is enabled) re-enables 
> the socket units, it would break things, so I tried to mask them, but that 
> failed, too.
> error: Could not issue start for prm_virtlockd: Unit virtlockd.socket is 
> masked.
> 
> Regards,
> Ulrich
> 
> 
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
> 

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


Re: [systemd-devel] Still confused with socket activation

2021-02-03 Thread Andrei Borzenkov
03.02.2021 00:25, Benjamin Berg пишет:
> On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote:
>> 02.02.2021 17:59, Lennart Poettering пишет:
>>>
>>> Note that Requires= in almost all cases should be combined with an
>>> order dep of After= onto the same unit.
>>
>> Years ago I asked for example when Requires makes sense without
>> After.
>> Care to show it? I assume you must have use case if you say "in
>> almost all".
> 
> In the GNOME systemd units there are a few places where a Requires= is
> combined with Before=.
> 

This is functionally completely equivalent to simply using Wants+Before.
At least as long as you rely on *documented* functions.

Care to show more complete example and explain why Wants does not work
in this case?



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Still confused with socket activation

2021-02-03 Thread Reindl Harald



Am 03.02.21 um 10:43 schrieb Benjamin Berg:

On Wed, 2021-02-03 at 08:00 +0100, Reindl Harald wrote:



Am 02.02.21 um 22:25 schrieb Benjamin Berg:

On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote:

02.02.2021 17:59, Lennart Poettering пишет:


Note that Requires= in almost all cases should be combined with
an
order dep of After= onto the same unit.


Years ago I asked for example when Requires makes sense without
After.
Care to show it? I assume you must have use case if you say "in
almost all".


In the GNOME systemd units there are a few places where a Requires=
is
combined with Before=


sounds like complete nonsense

you can not require something at your own to be there but on the other
hand start before it - at least by common sense


The units are indeed non-trivial. I have put in a lot of effort to find
a solution that both works and is robust in various failure modes. It
may well be that there is a better approach with similar properties.
But, session login and logout(!) is not quite as trivial as one could
hope for unfortunately (backward compatibility and workarounds add some
complexities).

So, I would love to be educated on how to simplify all this while still
catching the various corner cases. But in order to convince me, you'll
need to make a more concrete suggestion and explain its properties


seriously - explain what you expect to happen in case of

Requires=a.service
Before=a.service

except some warning that it's nonsense

you need a.service but want to be started before a.service sounds like 
wash me but don't make me wet

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


Re: [systemd-devel] Still confused with socket activation

2021-02-03 Thread Benjamin Berg
On Wed, 2021-02-03 at 08:00 +0100, Reindl Harald wrote:
> 
> 
> Am 02.02.21 um 22:25 schrieb Benjamin Berg:
> > On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote:
> > > 02.02.2021 17:59, Lennart Poettering пишет:
> > > > 
> > > > Note that Requires= in almost all cases should be combined with
> > > > an
> > > > order dep of After= onto the same unit.
> > > 
> > > Years ago I asked for example when Requires makes sense without
> > > After.
> > > Care to show it? I assume you must have use case if you say "in
> > > almost all".
> > 
> > In the GNOME systemd units there are a few places where a Requires=
> > is
> > combined with Before=
> 
> sounds like complete nonsense
> 
> you can not require something at your own to be there but on the other 
> hand start before it - at least by common sense

The units are indeed non-trivial. I have put in a lot of effort to find
a solution that both works and is robust in various failure modes. It
may well be that there is a better approach with similar properties.
But, session login and logout(!) is not quite as trivial as one could
hope for unfortunately (backward compatibility and workarounds add some
complexities).

So, I would love to be educated on how to simplify all this while still
catching the various corner cases. But in order to convince me, you'll
need to make a more concrete suggestion and explain its properties.

Benjamin


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Still confused with socket activation

2021-02-02 Thread Reindl Harald



Am 02.02.21 um 22:25 schrieb Benjamin Berg:

On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote:

02.02.2021 17:59, Lennart Poettering пишет:


Note that Requires= in almost all cases should be combined with an
order dep of After= onto the same unit.


Years ago I asked for example when Requires makes sense without
After.
Care to show it? I assume you must have use case if you say "in
almost all".


In the GNOME systemd units there are a few places where a Requires= is
combined with Before=


sounds like complete nonsense

you can not require something at your own to be there but on the other 
hand start before it - at least by common sense

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


Re: [systemd-devel] Still confused with socket activation

2021-02-02 Thread Benjamin Berg
On Tue, 2021-02-02 at 22:50 +0300, Andrei Borzenkov wrote:
> 02.02.2021 17:59, Lennart Poettering пишет:
> > 
> > Note that Requires= in almost all cases should be combined with an
> > order dep of After= onto the same unit.
> 
> Years ago I asked for example when Requires makes sense without
> After.
> Care to show it? I assume you must have use case if you say "in
> almost all".

In the GNOME systemd units there are a few places where a Requires= is
combined with Before=.

Benjamin


signature.asc
Description: This is a digitally signed message part
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Still confused with socket activation

2021-02-02 Thread Lennart Poettering
On Di, 02.02.21 22:50, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> 02.02.2021 17:59, Lennart Poettering пишет:
> >
> > Note that Requires= in almost all cases should be combined with an
> > order dep of After= onto the same unit.
>
> Years ago I asked for example when Requires makes sense without After.
> Care to show it? I assume you must have use case if you say "in almost all".

You can synthesize cases where it doesn't matter: if you know the
order is enforced by other means already, for example transitive
ordering. i.e. think of a late-boot service that needs some early-boot
preparation service to have run. Because the early-boot service
probably ordered itself before sysinit.target, and the late-boot
service is implicitly ordered after basic.target, there isn' a need to
order them directly against each other too, the transient deps between
sysinit.target and basic.target already gurantee correct ordering.

And there are other cases: for example if the ordering is already
configured the other way, or if you have any other reason you know the
stuff is ordered already.

Lennart

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


Re: [systemd-devel] Still confused with socket activation

2021-02-02 Thread Andrei Borzenkov
02.02.2021 17:59, Lennart Poettering пишет:
> 
> Note that Requires= in almost all cases should be combined with an
> order dep of After= onto the same unit.

Years ago I asked for example when Requires makes sense without After.
Care to show it? I assume you must have use case if you say "in almost all".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Still confused with socket activation

2021-02-02 Thread Lennart Poettering
On Di, 02.02.21 10:43, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> Hi!
>
> Having:
> ---
> # /usr/lib/systemd/system/virtlockd.service
> [Unit]
> Description=Virtual machine lock manager
> Requires=virtlockd.socket
> Requires=virtlockd-admin.socket
> Before=libvirtd.service
> ...
> ---
>
> How would I start both sockets successfully unter program control?
> If I start one socket, I cannot start the other without an error (as 
> libvirtd.service is running already, see my earlier message from last week).
> If I mask the socket units, I cannot start the libvirtd.service.
> So would I disable the socket units and start libvirtd.service?
> Unfortunately if someone (update when vendor-preset is enabled) re-enables 
> the socket units, it would break things, so I tried to mask them, but that 
> failed, too.
> error: Could not issue start for prm_virtlockd: Unit virtlockd.socket is 
> masked.

I don't grok what you are trying to say, the excerpt of the unit file
is too short. Please provide the relevant parts of the other unit
files too.

Masking is a big hammer, the last resort. It should not be part of the
usual workflow.

Note that Requires= in almost all cases should be combined with an
order dep of After= onto the same unit. If the unit above doesn't do
that it's almost certainly broken.

Lennart

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


[systemd-devel] Still confused with socket activation

2021-02-02 Thread Ulrich Windl
Hi!

Having:
---
# /usr/lib/systemd/system/virtlockd.service
[Unit]
Description=Virtual machine lock manager
Requires=virtlockd.socket
Requires=virtlockd-admin.socket
Before=libvirtd.service
...
---

How would I start both sockets successfully unter program control?
If I start one socket, I cannot start the other without an error (as 
libvirtd.service is running already, see my earlier message from last week).
If I mask the socket units, I cannot start the libvirtd.service.
So would I disable the socket units and start libvirtd.service?
Unfortunately if someone (update when vendor-preset is enabled) re-enables the 
socket units, it would break things, so I tried to mask them, but that failed, 
too.
error: Could not issue start for prm_virtlockd: Unit virtlockd.socket is masked.

Regards,
Ulrich




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