Bug 1832510

Summary: RFE: Add support for "~" ("random within range") for cronjob execution
Product: Red Hat Enterprise Linux 8 Reporter: Robert Scheck <redhat-bugzilla>
Component: cronieAssignee: Ondřej Pohořelský <opohorel>
Status: CLOSED ERRATA QA Contact: Jan Houska <jhouska>
Severity: urgent Docs Contact: Lenka Špačková <lkuprova>
Priority: unspecified    
Version: 8.2CC: dklon, hhorak, jkejda, job, jstanek, mmuzila, opohorel, robert.scheck, sbalasub
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: 8.3   
Hardware: x86_64   
OS: Linux   
Fixed In Version: cronie-1.5.2-7.el8 Doc Type: Enhancement
Doc Text:
.`Cronie` adds support for a randomized time within a selected range The `Cronie` utility now supports the `~` (random within range) operator for cronjob execution. As a result, you can start a cronjob on a randomized time within the selected range.
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-11-08 10:48:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
Cronie rpm with added random within range option
Fixed Cronie rpm that adds random within range feature none

Description Robert Scheck 2020-05-06 18:23:27 UTC
Description of problem:
I would like to see the OpenBSD cron(8) crontab(5) feature "A random value (within the legal range) may be obtained by using the ‘~’ character in a field. The interval of the random value may be specified explicitly, for example “0~30” will result in a random value between 0 and 30 inclusive. If either (or both) of the numbers on either side of the ‘~’ are omitted, the appropriate limit (low or high) for the field will be used." (source: https://man.openbsd.org/crontab.5) in cronie.

Version-Release number of selected component (if applicable):

Actual results:
No support for random cronjob execution within specified range.

Expected results:
Support for random cronjob execution within specified range, like in OpenBSD cron(8).

Comment 1 Robert Scheck 2020-05-06 18:26:17 UTC
Cross-filed case 02647607 at the Red Hat customer portal.

Comment 7 Robert Scheck 2020-10-02 13:04:20 UTC
Via GSS I received this:

> In RHEL, cronie has two similar options:
> 1) RANDOM_DELAY variable
> When specified in the crontab file, this delays the execution by the specified amount of minutes.
> 2) RANDOMTIME in run-parts
> This works for special @hourly, @weekly etc. jobs being run by the run-parts script. It allows to randomize the job time by a specified interval in seconds.
> This was introduced specifically to lower load spikes on I/O.
> Note that for this to work, RANDOMIZE must be set to a non-empty value and RANDOM must be set, as it works as a random seed.

Unfortunately, neither $RANDOM_DELAY nor $RANDOMTIME do the trick, because they do not allow the following:

15~45 * * * * root /some/script.sh

What does it do? The /some/script.sh is run at a random time *between* *:15 and *:45. All I can do with $RANDOM is a sleep(1) for e.g. $RANDOM seconds. Yes, I somehow could fiddle around by adding some offset to it. But more advanced:

5 6~18 * * * root /some/script.sh

Now /some/script.sh is executed at 5 minutes after a random hour between 6 am and 6 pm. Yes, I could fiddle with $RANDOM and sleep(1) somehow again. But I even could do this:

5~15,35~45 * * * * root /some/script.sh

How to do that with sleep(1) and $RANDOM? Yes, might still work somehow. But that's a lot of bash fiddling in a crontab. Finally, the '~' character is much more readable and admin-friendly, right?

Further bonus of '~' implementation, if I'm not mistaken: The "random within range" is sticky randomness until reload of crond, while $RANDOM is not.

See also the following mailing list discussions for the actual implementation:

 - https://marc.info/?l=openbsd-tech&m=158683644314416&w=2
 - https://marc.info/?l=openbsd-tech&m=158689123305224&w=2
 - https://marc.info/?l=openbsd-tech&m=158683601514310&w=2
 - https://marc.info/?l=openbsd-tech&m=158683644314416&w=2

Finally, I can not see how $RANDOMTIME would solve the expectation of this feature request.

Comment 8 Robert Scheck 2020-10-02 13:06:33 UTC
Not sure if engineering's question "Is it for backward-compatibility with a BSD system or something similar to the case mentioned above (I/O load)?" is already answered by the cool examples above by itself, thus if not: I would like to have *clearly* *readable* crontab files without bash fiddling but still "random within range" cronjob executions, where the important part is *within* *range*.

Comment 12 Jan Staněk 2021-01-22 13:41:22 UTC
Component ownership in bugzilla has changed; reassigning to new owner.

Comment 22 Ondřej Pohořelský 2021-09-23 12:16:18 UTC
I've opened upstream PR[1] with a patch.

Feel free to test this patch and provide a feedback into PR discussion.


Comment 30 Ondřej Pohořelský 2022-01-14 12:17:47 UTC
Created attachment 1850780 [details]
Cronie rpm with added random within range option

I'm adding x86_64 rpm that contains Cronie with applied random within range patch, so customer can test this feature and provide us feedback.

Comment 36 Robert Scheck 2022-01-31 22:54:01 UTC
I am not sure if the package from comment #30 works properly, because when I put

5~10 * * * * root echo "5~10 * * * *"

into /etc/crontab, I end up with:

crond[6617]: (CRON) bad minute (/etc/crontab)

And with

5 7~9 * * * root echo "5 7~9 * * *"

in /etc/crontab, I end up with:

crond[6617]: (CRON) bad hour (/etc/crontab)

Or am I overlooking something?

Comment 38 Ondřej Pohořelský 2022-02-08 15:34:17 UTC
Created attachment 1859836 [details]
Fixed Cronie rpm that adds random within range feature

I'm terribly sorry for this mistake. You are not overlooking anything. I've got my files mixed up and uploaded an rpm that indeed doesn't work.
Could you please test this new one?

Thank you for your feedback!

Comment 39 Robert Scheck 2022-04-08 14:36:04 UTC
(In reply to Ondřej Pohořelský from comment #38)
> Could you please test this new one?

I tested your package over a longer period to also catch crond restarts and systemd reboots etc. It seems like it works as expected - thank you!

Are there still chances for RHEL 8, or is this going to land in RHEL 9 only? The latter would be okay, RHEL 8 additionally would be outstanding.

Comment 61 errata-xmlrpc 2022-11-08 10:48:38 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (cronie bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.