Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?
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, a separate package that reads cron jobs and
writes pairs of systemd timer and service units that result in systemd
doing approximately the same things (ana)cron would have done under the
same configuration.
systemd itself does not have cron integration, so packages with
important cron jobs must depend on some cron-daemon implementation. In
current Debian that means either Vixie cron, cronie or bcron, which are
independent daemons, or systemd-cron.
As Philipp Kern pointed out, one reason to break them up is to attribute
log messages and failures to the actual task (popularity-contest.service
or whatever), rather than to some larger unit like cron-weekly.service.
systemd-cron writes cron job output to the system log, rather than sending
it by email like traditional cron implementations, but the general
principle is similar: you can prioritize more easily if the report is
"cron.daily/man-db failed" than if the report is "cron.daily failed".
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). This avoids
log noise (and inefficiency, but the log noise is more important) from
/etc/cron.daily/man-db starting, noticing that this is a systemd system,
and exiting early so that it won't duplicate the timer unit. This is the
same "shadowing" mechanism that ensures that if a package has a systemd
service dbus.service and an init script /etc/init.d/dbus, then the init
script will be skipped. If every script in cron.daily is shadowed in
this way, no daily systemd-cron timers will be scheduled at all.
systemd-cron *could* generate one big timer unit that activates a "target"
(a group of services), generate a separate service per script as part of
that target, chain them together in lexical order by building a linked
list of Before or After directives, and implement the "don't schedule
this one if there's a native timer" logic itself instead of relying
on shadowing - but right now it doesn't, and what it does now is a lot
simpler. Introducing more complexity might be a necessary evil if real
cron jobs rely on it, but it seems better to avoid that if possible.
smcv
Reply to: