Random cron

[MarcelWaldvogel]

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.

[MarcelWaldvogel]

Also distribute load on letsencrypt servers better over the course of the day

[jprenken]

Ping @Neilpang - We at Let's Encrypt would love to see this PR updated and merged. Thanks! ❤️

[MarcelWaldvogel]

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 --cron option include a random delay of [0,60] seconds?

[MarcelWaldvogel]

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

[jprenken]

@jprenken: Do you see peaks at the beginning of each minute? I.e., should the --cron option include a random delay of [0,60] seconds?

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.

[Eagle3386]

@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? 😍