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
