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.
* 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 as
it might
seem, e.g. you cannot do it from the service units themselves in
`ExecStartPost=` or similar.
* /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.
* File-based locking makes it impossible to use private filesystem
namespaces
for the service units (think of `PrivateTmp=yes` and lock files in
/tmp).
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.
Best regards,
Alex
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
