On 2019-07-28 15:07, Ian Jackson wrote:
Marc Haber writes ("Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?"):On Sat, 27 Jul 2019 19:02:16 +0100, Ian Jackson >I worry about additional concurrency. Unlike ordering bugs, >concurrency bugs are hard to find by testing. So running these >scripts in parallel is risky. > >And, I think running cron.fooly scripts in parallel is a bad idea. >The objective is to run them "at some point", not to get it done as >soon as possible. Running them in sequence will save electricity, >may save wear on components, and will reduce overall impact on other >uses of the same system. I fully agree with that. However, moving away from "in sequence" thing would greatly ease the migration to systemd timers, making it easier to get away without crond on many systems.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 it's better for the administrator to export state as granular as possible. That way the exit codes are exported into global systemd state and you can see exactly what is failing rather than a generic "something in cron.$foo failed, good luck finding the right logs". systemd also gives you the logs per timer unit, rather than in bulk, so the error is trivially visible rather than filtering a long log for what went wrong.
Think of this as an alert condition: I want to know if, say, popularity-contest failed and treat that with lower urgency than, say, debsums. One is a goodie and one is evidence of potential disk corruption. If the "cron.daily" script failed, I don't know if this has a particular urgency until I crawled the logs.
Obviously, I don't think it is a good idea to break this for non-systemd users because of difficulties making it work properly with systemd. Perhaps I have misunderstood you ?
To be honest, that's something that the compatibility/init diversity folks then need to figure out.
Kind regards Philipp Kern