Hide Forgot
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): cronie-1.5.2-4.el8 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).
Cross-filed case 02647607 at the Red Hat customer portal.
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.
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*.
Component ownership in bugzilla has changed; reassigning to new owner.
I've opened upstream PR[1] with a patch. Feel free to test this patch and provide a feedback into PR discussion. [1]https://github.com/cronie-crond/cronie/pull/95
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.
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?
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!
(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.
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. https://access.redhat.com/errata/RHBA-2022:7721