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

[Lennart Poettering]

On Thu, 27.04.17 23:30, Julian Andres Klode (jak at debian.org) wrote:

> Hi systemd folks,
> 
> (service and timer files being discussed at the bottom)
> 
> we are currently reworking the way automatic updates and upgrades work
> on Ubuntu and Debian systems. We basically have two persistent timers
> with associated services:
> 
> 1. apt-daily - Downloads new lists and packages
> 2. apt-daily-upgrade - Performs upgrades
> 
> The first job should run spread out through the day (we run it twice
> due to some other reasons), the latter in the morning between 6 and 7,
> and at boot, daily-upgrade should be resumed after daily (so we added
> After ordering relations to apt-daily-upgrade timer and service).
> 
> 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.

Hmm, this should just work — with restrictions —, as long as both
services use Type=oneshot, and there's an After/Before= dep between
them. In that case if both services are enqueued at the same time they
will be dispatched in the right order, and the second one only after
the service completed.

That said, there are limits to this: this will only work correctly if
the start jobs for both units are either enqueued at the same time or
in the order they are supposed to be run in. If however, the job for
the unit that is supposed to be run second is enqueued first, it will
be immediately dispatched (as at that moment ordering deps won't have
any effect as the other unit isn't enqueue), and if the job for the
first unit is then enqueued then both will run at the same time. This
is simply as the queue dispatching order only matters at the moment a
service is actually triggered, afterwards it doesn't matter anymore.

> I tried adding Conflicts, but systemd
> then said "loop to fast" and became unresponsive (not sure if caused
> by this, but maybe).

Conflicts is not what you want: it means that any queued jobs of the
other service are removed when you start a conflicting service, in
addition to the service being stopped itself.
"loop to fast" usually indicates that either something in PID 1 is
borked, or you have some kind of feedback loop, where systemd keeps
doing stuff based on a flood of client requests.

So, I am not sure what i can recommend you, systemd's dependency
currently cannot express what you want to do, but I sympathize with
the problem. I am not entirely sure what a good and natural way would
be though to extend systemd's logic for what you want to do.

Ideas?

Lennart

-- 
Lennart Poettering, Red Hat