RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1832510 - RFE: Add support for "~" ("random within range") for cronjob execution
Summary: RFE: Add support for "~" ("random within range") for cronjob execution
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: cronie
Version: 8.2
Hardware: x86_64
OS: Linux
Target Milestone: rc
: 8.3
Assignee: Ondřej Pohořelský
QA Contact: Jan Houska
Lenka Špačková
Depends On:
TreeView+ depends on / blocked
Reported: 2020-05-06 18:23 UTC by Robert Scheck
Modified: 2022-11-08 12:33 UTC (History)
9 users (show)

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.
Clone Of:
Last Closed: 2022-11-08 10:48:38 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)
Cronie rpm with added random within range option (117.41 KB, application/x-rpm)
2022-01-14 12:17 UTC, Ondřej Pohořelský
no flags Details
Fixed Cronie rpm that adds random within range feature (117.46 KB, application/x-rpm)
2022-02-08 15:34 UTC, Ondřej Pohořelský
no flags Details

System ID Private Priority Status Summary Last Updated
Github cronie-crond cronie pull 95 0 None open Adds random within range '~' operator 2021-09-23 12:16:17 UTC
Red Hat Product Errata RHBA-2022:7721 0 None None None 2022-11-08 10:48:42 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.