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