[systemd-devel] Mutually exclusive (timer-triggered) services

[Silvio Knizek]

Am Montag, den 14.10.2019, 18:30 +0200 schrieb Alexander Koch:
> > exactly for this you would use a flock(1) in your .service.
>
> Thanks for the hint, didn't have that in mind. So you're suggesting
> something like this?
>
>      # service-a.service
>      # (...)
>      [Service]
>      ExecStart=/usr/bin/flock -F /var/lock/resource.lock
> /usr/bin/service-a
>
>      # service-b.service
>      # (...)
>      [Service]
>      ExecStart=/usr/bin/flock -F /var/lock/resource.lock
> /usr/bin/service-b
>
>
> I see some drawbacks of this approach:
>
> * Wrapping the actual command in an flock call seems pretty ugly in
> my eyes, i.e. looking at the `ExecStart=` lines above I find it very
> hard to see where the former begins, at first glance. This is
> subjective, of course.
You could use something like

ExecStart=/usr/bin/flock -F /path/to/lock.file \
          /your/actual/command --with argument

Should be easier on the eyes.
>
> * flock leaves the lock file behind so you'd need some type of
> cleanup in case you really want the jobs to be trace-free. This is
> not as trivial is it might seem, e.g. you cannot do it from the
> service units themselves in `ExecStartPost=` or similar.
An

ExecStartPost=-/usr/bin/flock -F /path/to/lock.file \
              /usr/bin/rm /path/to/lock.file

should solve this issue.
>
> * /var/lock is very likely not user-writable so you'd need a
> different lock file directory for user services. You could of course
> use /tmp for that.
For this I would suggest StateDirectory=. See man:systemd.exec for more
information
>
> * File-based locking makes it impossible to use private filesystem
> namespaces for the service units (think of `PrivateTmp=yes` and lock
> files in /tmp).
If a StateDirectory= is used than only the access rights are important.
>
>
> As systemd (or service managers in general) are all about queueing,
> ordering and controlling services and their dependencies I had hoped
> there would be a cleaner solution using systemd internals rather than
> solving it using external tools, which mixes up the service call
> itself with its requirements (exclusive resource access).
>
> Nevertheless I think I will go with your proposal and see how it
> works out.
If your units are actually dependent on each other, than maybe you
should think about your approach in general. But to be able to help you
with that we need more information about the actual dependencies of the
applications started by your units and at which interval they shall
run.
>
>
> Best regards,
>
> Alex
BR
Silvio