On Mon, 29 Jul 2019 18:42:34 +0100, Simon McVittie <s...@debian.org> wrote: >On Wed, 24 Jul 2019 at 20:14:22 +0200, Marc Haber wrote: >> Scripts with such dependencies will probably fail miserably on systems >> that are using systemd-cron instead of one of the "classic" cron >> packaes > >I thought so too, but they don't: systemd-cron uses run-parts for >cron.{hourly,etc.} too.
... this imports many disadvantages of the old scheme into the new world. Philipp has explained in this thread very well. Maybe systemd-cron could be extended to be locally configurable whether to use run-parts, keeping the old semantics, or to generate individual timers. systemd itself would need a means to group different timers together with the constraint that at most X of those can run in parallel. >On Sun, 28 Jul 2019 at 08:47:49 +0200, Marc Haber wrote: >> Setting RandomizeDelaySecs sufficiently high on our daily jobs would >> probably help to chop off the load pike that especially virtualization >> setups running many Debian instances suffer from at 06:25 or 07:35. I >> think this could be a net gain worth pursuing. > >If you want this, the way to opt-in to it is currently to add a native >systemd timer, and make the traditional cron script a no-op on systems >running systemd (to avoid doing the periodic task twice). For example, >apt and man-db have both done this. ... which takes away flexibility and standardization from the local admin, adding more things to think about when developing larger infrastructures. I am not sure whether I like that. Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834