Marc Haber writes ("Re: do packages depend on lexical order or
{daily,weekly,monthly} cron jobs?"):
> 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.
Right. That makes sense.
So it seems to me that there are the following options for systemd
users:
A. Continue to use run-parts.
Disadvantages: Bundles the output together.
Doesn't provide individual status.
Advantages: No work needed.
B. Run each script as a single systemd timer unit.
Disadvantages: Runs scripts in parallel (causing load spikes and
other undesirable performance effects). Imposes un-auditable and
undebuggable new concurrency/ordering requirements on scripts (that
is, scripts must cope with concurrent running and in any order).
Ie, effectively, exposes systemd users to new bugs.
Advantages: Unbundled output and individual status.
C. Provide a feature in systemd to do what is needed.
Advantages: Everything works properly.
Disadvantage: Requires writing new code to implement the feature.
D. Provide a version of run-parts which does per-script reporting.
Advantages: Provides the benefits of (c) to sysvinit/cron users
too. Disadvantages: Requires design of a new reporting protocol,
and implementation of that protocol in run-parts; to gain the
benefits for systemd users, must be implemented in systemd too.
(Likewise for cron users.)
I was wrong when earlier I wrote that sysvinit users would suffer any
significant trouble, regardless what option above is picked. The only
negative impact of (B) on sysvinit users is that maybe the cron
scripts they are running become more complex and fragile, in order to
try to satisfy the new concurrency requirement.
I would be interested in (D) if you thought it would be worthwhile.
Maybe the subunit v1 protocol or something :-).
> Maybe systemd-cron could be extended to be locally configurable
> whether to use run-parts, keeping the old semantics, or to generate
> individual timers.
There would be question of the default.
With current code the options are:
A. Things run in series but with concatenated output and no individual
status.
B. Things run in parallel, giving load spikes and possible concurrency
bugs; vs.
I can see few people who would choose (B).
People who don't care much about paying attention to broken cron
stuff, or people who wouldn't know how to fix it, are better served by
(A). It provides a better experience.
Knowledgeable people will not have too much trouble interpreting
combined output, and maybe have external monitoring arrangements
anyway. Conversely, heisenbugs and load spikes are still undesirable.
So they should also choose (A).
IOW reliability and proper operation is more important than separated
logging and status reporting.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
