[systemd-devel] Still confused with socket activation

[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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>