* 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@home.service is running... or
maybe
it's just me seeing this need ;)
Best regards,
Alex
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
