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

Alexander Koch mail at alexanderkoch.net
Tue Oct 15 19:48:31 UTC 2019


>> * 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.

So you can remove a file other processes are blocked lock-waiting on? 
Didn't
expect this to work, thanks for the hint.

> 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.

Okay I guess I should come up with the actual scenario, here we go:

On my Arch Linux workstation I've got three .timer triggered .service 
units
that do package manager housekeeping (I don't know if you're familiar 
with
Arch/Pacman so I'll annotate their purposes):

1) Synchronize package database (equivalent of `apt-get update` on 
Debian)

     [Timer]
     OnCalendar=8-17/2:00
     Persistent=true

     [Service]
     ExecStart=/usr/bin/pacman -Syq

2) Update file database (equivalent of `apt-file update`)

     [Timer]
     OnCalendar=weekly
     Persistent=true

     [Service]
     ExecStart=/usr/bin/pacman -Fyq

3) Purge old packages from cache (something like `apt-get autoclean`)

     [Timer]
     OnCalendar=daily
     Persistent=true

     [Service]
     ExecStart=/bin/sh -c 'paccache -r -k 2; paccache -r -k 0 -u'

As you can see, I'd like to have different execution intervals for all 
of
these tasks so I'd like to keep them as separate services (which also 
seems
the intuitive approach to me).

I must admit that I haven't tried, but I'm pretty sure that at least 1 
and
2 do lock the ALPM database so if you try to issue one of these Pacman 
calls
while the other is running it will fail, complaining about a lock file 
being
present.

My current workaround for this is using `RandomizedDelaySec=15m` in
conjunction with `AccuracySec=1` in the .timer units to spread the 
triggers.

While this does work I'm really curious about the 'proper' way of 
modeling
this. Is it such an academic problem to have the need of ensuring that 
two
timers (or services) don't fire simultaneously? I had thought this to be
really simple with such an elaborate service manager like systemd, with 
all
its graph theory power and the-like.

(If I were a heretic I'd say 'We can do DNS, DHCP and NTP with systemd
without any third party software but we need additional utilities to 
ensure
that two things don't happen at the same time??' ;) )

I think there are plenty of other scenarios, e.g. ideally I'd like my 
backup
service not to kick in while btrfs-scrub at home.service is running... or 
maybe
it's just me seeing this need ;)


Best regards,

Alex


More information about the systemd-devel mailing list