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

[Lennart Poettering]

On Mo, 14.10.19 12:45, Alexander Koch (mail at alexanderkoch.net) wrote:

> Dear [systemd-devel],
>
> imagine you've got multiple services that perform system housekeeping
> tasks, all triggered by .timer units. These services all happen to use
> a specific resource (e.g. the system package manager) so they must not
> be run in parallel, but they all need to be run.
>
> Is there a systemd'ish way of modeling this?
>
> I first thought of using `Conflicts=` but having read the manpages I
> understand that queueing one of the services would actively stop any
> running instance of any of the others.
>
> `After=` is not an option either as that (unless 'Type=oneshot', which
> isn't to be used for long-running tasks) doesn't delay up to completion
> but only to initialization. Furthermore I think you'd run into trouble
> ordering more than two units using this approach.
>
> Ideally I'd think of something like a 'virtual resource' that can be
> specified by service units, like this (real use case on Arch Linux):
>
>     [Unit]
>     Description=Pacman sync
>     Locks=pacman-db
>
>     [Service]
>     ExecStart=/usr/bin/pacman -Sy
>
>     ----
>
>     [Unit]
>     Description=Pacman cleanup
>     Locks=pacman-db
>
>     [Service]
>     ExecStart=/usr/bin/paccache -r -k 0 -u
>
> The value of `Locks=` shall be an arbitrary string describing the
> virtual resource the service is requiring exclusive access to. systemd
> would then delay the start of a unit if there is another unit with
> identical `Locks=` entry currently active.
>
> A nice advantage of this concept is that services depending on the same
> virtual resource would not need to know of each other, which simplifies
> shipping them via separate packages.
>
> Any thoughts on this? Maybe I'm just too blind to see the obvious
> solution to this simple problem.

I presume pacman uses file system locks anyway, no? I think the best
approach would be to make those (optionally) blocking directly in
pacman, no?

I mean, you can add five layers of locking on top, but ultimately it
appears to me in this case you just want to make the locking that
already exists just blocking. Linux fs locking exists in non-blocking
*and* blocking flavour anyway, it's just a matter of making pacman
expose that, maybe with a new --block switch or so?

Other than that you can of course use tools such as "flock(1)" around
pacman.

Lennart

--
Lennart Poettering, Berlin