Random cron #944
Random cron #944
Conversation
|
Also distribute load on letsencrypt servers better over the course of the day |
|
Ping @Neilpang - We at Let's Encrypt would love to see this PR updated and merged. Thanks! ❤️ |
|
Hey, someone is still looking at this old PR, wow! I guess my explanation why we would need to run it twice per day is not valid, as the renewal starts several days (30, I believe) prior to the expiration. However, having two points in time can help distribute the load better, under some assumptions. In any case, it should not be detrimental. @jprenken: Do you see peaks at the beginning of each minute? I.e., should the |
The hour for the cron job isn't really random (as is the minute), but assuming acme.sh installation times are not correlated, neither will be the resulting cron start times.
MarcelWaldvogel
force-pushed
the
random-cron
branch
from
f75b05c
to
0781e8c
Compare
|
I redid this based on the current code base, at the same time reducing clustering of cron start times. Adapted test cases to allow for an hour != 0 with acmesh-official/acmetest#11 |
Thanks so much for updating this! Yes, we do see peaks at the beginning of minutes and even seconds; the finer-grained time randomization, the better. |
|
@Neilpang It's more than 6 years that this PR was opened, its changes are rather trivial & no merge conflicts - even after all these years - exists. Would you mind considering to merge it in the near future, please? 😍 |
acmesh-official#944 (comment) Let's Encrypt employee said in the comments "we do see peaks at the beginning of minutes and even seconds; the finer-grained time randomization, the better." This adds a random amount of sleep second before beginning the cron job. I considered reading from `/dev/urandom` and so on, but we aren't doing anything security critical here so I thought that just using the process number modulo 59 (the largest prime <= 60) should give decent variability across the systems. The starting hour and minute are already randomized during the installation.
To avoid race conditions, run cron twice a day to make sure certificates are guaranteed to be renewed at least once during the last 24 hours of the certificate lifetime.