Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raise yum-cron-hourly random_sleep to 60m #133

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

evan-goode
Copy link
Member

For https://issues.redhat.com/browse/RHEL-40868.

Spreads out the load more on mirror servers.

@evan-goode evan-goode changed the title Raise yum-cron-hourly random_sleep to 30m Raise yum-cron-hourly random_sleep to 60m Jul 16, 2024
@evan-goode
Copy link
Member Author

Ideally, the random delay would be 60 minutes, so mirrors see a uniform distribution across the whole hour. For dnf-makecache.timer, we already use a 0--60 minute random delay.

Initially I was hesitant about increasing random_sleep to 60 minutes, since cron would be much more likely to start another yum-cron when a process is already running. But upon checking /etc/cron.hourly/0yum-hourly.cron, there is a locking mechanism that prevents this from happening:

# Only run if this flag is set. The flag is created by the yum-cron init
# script when the service is started -- this allows one to use chkconfig and
# the standard "service stop|start" commands to enable or disable yum-cron.
if [[ ! -f /var/lock/subsys/yum-cron ]]; then
  exit 0
fi

so I think a 60 minute random_sleep would be fine. In a "worst-case" scenario, cron runs yum-cron on the hour at 00:00, yum-cron random_sleeps 59 minutes and runs from 00:59--01:01, then cron skips running yum_cron at 01:00 since the first process has not released the lockfile. The next yum_cron would be started at 02:00 and could sleep until 02:59.

This situation is already possible in the status quo, but now it could happen even for short-running yum-cron tasks like makecache. I think this is a reasonable tradeoff, given that this patch would lighten mirror loads and avoid making too many changes to the yum-cron scheduling logic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant