Re: Mutually exclusive (timer-triggered) services

[Silvio Knizek <killermoehre@xxxxxxx>]

Am Montag, den 14.10.2019, 12:45 +0200 schrieb Alexander Koch:
> Dear ,
>
> 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.
>
>
> Best regards,
>
> Alex
Hi Alex,

exactly for this you would use a flock(1) in your .service.

BR
Silvio

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