[systemd-devel] Ordering (apt) timer services to not run at the same time

[Andrei Borzenkov]

28.04.2017 12:05, Julian Andres Klode пишет:
> On Fri, Apr 28, 2017 at 08:46:45AM +0200, Michal Sekletar wrote:
>> On Thu, Apr 27, 2017 at 11:30 PM, Julian Andres Klode <jak at debian.org> wrote:
>>
>>> Now, we seem to be missing one bit: If daily-upgrade is already
>>> running, and daily is about to start, daily should wait for
>>> daily-upgrade to finish. I had hoped that maybe that works
>>> automatically given that there is some ordering relation between the
>>> two, but that did not work out. I tried adding Conflicts, but systemd
>>> then said "loop to fast" and became unresponsive (not sure if caused
>>> by this, but maybe).
>>
>> After/Before dependencies ensure ordering between respective jobs in a
>> transaction (actually between both jobs in a single transaction and
>> between jobs that are already in run queue). However, ordering doesn't
>> affect jobs that we've already dispatched, since they are already
>> running we can't do much about them.
> 
> From my testing, if B has After=A, and A is already started, the
> startup of B is delayed until A has completed - do you mean that
> with run queue, or is that merely by accident somehow?
> 

Works as designed. You have Type=oneshot units, for this type "unit
started" means "ExecStart command has finished". So B waits until A is
started a.k.a. ExecStart command completes.

But in opposite case, when B is already being started, there is nothing
that can be done about A; even worse, strict solution would be to abort
B, start A then restart B.

This really needs other type of dependencies. Asymmetrical After (that
does not imply revers Before) is one possibility. Reverse Requisite is
not exactly the right one, as you want to wait, not fail start request
immediately.

>> Indeed, seems like lockfile + condition in other unit is the simplest way out.
> 
> How unfortunate.
>