Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?

[Simon McVittie <smcv@debian.org>]

On Mon, 29 Jul 2019 at 18:26:22 +0100, Simon McVittie wrote:
> On Sun, 28 Jul 2019 at 14:07:59 +0100, Ian Jackson wrote:
> > Why can't systemd run cron.fooly as one big timer job rather than one
> > timer job for each script ?
> 
> Of course it could, but perhaps it shouldn't.
> 
> To avoid ambiguity, this is not a systemd design decision: it's a design
> decision of systemd-cron

Correction: at the moment, systemd-cron *does* run cron.daily, etc. as
one big timer/service pair per interval, using essentially the same
run-parts call as for traditional cron.

If scripts rely on lexical order, then it will have to continue to do this,
and maintainers who want to opt-in to having their periodic script run
outside that sequence on systemd systems will have to write native timer
units.

(Conversely, if scripts don't rely on lexical order, then systemd-cron
would be free to schedule them separately if the trade-offs around
race-to-idle, predictable load spikes, etc. make that desirable.)

> Another reason to break them up is that if the same package installs
> both a cron script like /etc/cron.daily/man-db and a systemd unit like
> /lib/systemd/system/man-db.timer, systemd-cron deliberately generates its
> unit to be named man-db.timer, so that it will be "shadowed" by the native
> man-db.timer (which is in a higher-precedence directory).

As a result, systemd-cron doesn't currently do this for daily, etc. cron
jobs (but it does for cron.d jobs).

    smcv