Cron jobs executes more times than desired when using jitter
See original GitHub issueWhen using the jitter option in a scheduled cron jobs, for example using the code from the documentation:
# Run the
job_function every sharp hour with an extra-delay picked randomly in a [-120,+120] seconds window. sched.add_job(job_function, 'cron', hour='*', jitter=120)
if the job is scheduled before the sharp hour then the job will be scheduled for the same hour again. For example:
-
A Job is defined to be runned at sharp hours.
-
Job is scheduled to run at 14:59:51
-
Job runs at 14:59:51 but its scheduled to run at 15:00:02 again. In this case we only want the job to run once at ~15:00:00.
Attached is a small piece of code to test this behaiviour: test.zip
Issue Analytics
- State:
- Created 6 years ago
- Reactions:7
- Comments:15 (6 by maintainers)
Top Results From Across the Web
Cron jobs and random times, within given hours - Stack Overflow
The only way to do this acceptably seems to Klaus' idea: select your 20 times at 09:00, which allows you to fulfill any...
Read more >Triggered Builds by cron have high deviation against ... - Drone
Triggered Builds by cron have high deviation against expected time · 1 - Jitter · 2 - Accumulated delay · 3 - Cron...
Read more >Can I run a cron job more frequently than every minute?
If your job runs every X minutes, and takes more than X minutes to finish, you'll end up with jobs stacking up. If...
Read more >Randomly spacing cron jobs - End Point Dev
The RANDOM_DELAY variable allows delaying job startups by random amount of minutes with upper limit specified by the variable. The random ...
Read more >Setting up a cron for every 30 hours in Debian
The simplest solution would probably be to run a cronjob more frequently and use a wrapper script to quit without doing anything if...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
For the record, this has been addressed in master by ensuring that jitter always places the execution time after the last run time and before the next run time after that.
I’m closing this as done since v4.0.0a1 is out now.