Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?
On Mon, 5 Aug 2019 16:34:18 +0100, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
>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.
In fact, systemd-cron already has an issue open upstream to change
this behavior, see
https://github.com/systemd-cron/systemd-cron/issues/47
I have taken the liberty of commenting a pointer to this discussion
into the upstream issue and also making my case to make tihs
configurable.
>C. Provide a feature in systemd to do what is needed.
> Advantages: Everything works properly.
> Disadvantage: Requires writing new code to implement the feature.
Imo, there should be a possibility in a systemd timer to switch on the
"old" output-to-e-mail behavior. This is probably something that
systemd upstream would never implement, so we'd end up with a wrapper
that is called by the systemd timer unit.
>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.)
We have already thrown sysvinit away. Things are exactly like I
predicted, the init scripts are rotting away quickly. I think we
should stop wasting personpower for sysvinit support, people not
liking systemd have gone to devuan anyway.
>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).
>From an individual system's POV, with RandomizeDelay the load would be
higher, granted, but from a virtualization environment's POV the load
spike would greatly be evened out when the VMs don't invoke their
run-parts in the same second. I know virtualization operators who call
the 06:25 peak in their load "The Debian peak".
I would choose Option B in all my use cases, with different
parameters: As a server jockey, I'd use a high RandomizeDelay to even
out the impact on the infrastructure, and on my personal laptop, I'd
probably use a very small RandomizeDelay so that the box can return to
power-save idle faster.
What keeps me from doing this now is the lack of e-mail output.
>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.
I disagree.
>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).
I disagree.
>IOW reliability and proper operation is more important than separated
>logging and status reporting.
I would choose B to help in debugging the scripts. Better force those
errors now to have them ironed out for bullseye. The current behavior
of run-parts doing things in lexical order and serialized is basically
a historically caused coincidence.
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
Reply to: