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