On Mon, 5 Aug 2019 16:34:18 +0100, Ian Jackson
<ijack...@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 via email to