mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-13 15:13:33 +01:00
Need to delay/retry on 500 errors #159
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ktwalrus on GitHub (Oct 29, 2016).
I'm using an older version of the letsencrypt.sh script (from August, I think).
I have a domain with 70 subdomains that I am trying to renew the cert for. But, the LE server seems to be busy right now and I have been unable to run the script all the way through without the script aborting with a Server Busy (500) error partway through execution.
Here is the error message on one of the aborts:
And, here is another:
I think the script should check for a Status 500 and delay for 15 seconds or so and then retry the post-request.
I am using DNS challenges so when the script aborts, it leaves outstanding challenges and LE eventually makes me wait a week (like happened to me tonight) for the outstanding challenges to age off and allow me to try the script again.
@pastukhov commented on GitHub (Oct 30, 2016):
There is about issue in letsecrypt repo about it https://github.com/letsencrypt/boulder/issues/1943#issuecomment-247550765
@fragpit commented on GitHub (Dec 16, 2016):
facing this issue today, despite that letsencrypt status is ok. It happens on about 124 requests.
less than 100, pass ok.
@ktwalrus commented on GitHub (Feb 24, 2017):
I'm using the latest version of dehydrated and this still happens for me. Any chance of a fix coming soon?
@ktwalrus commented on GitHub (Feb 24, 2017):
Turns out this doesn't seem to be as bad a problem as it was before. When I re-ran dehydrated, it didn't deploy_challenges for the ones that had previously succeeded. Instead, it picked up with the challenge that had failed with the SERVER BUSY error.
Still, dehydrated should probably check for Status 500 and delay before retrying the post-request. As it is now, the script simply prints the error messages and exits which is not very friendly in the case of a temporary problem like SERVER BUSY.
@lukas2511 commented on GitHub (Jul 10, 2017):
Duplicate of quite a lot of other tickets. There are a lot of reasons not to implement this: If Let's Encrypt is under heavy load it definitively won't help if tons of clients retry and retry and retry, also error handling in bash is hard enough, retrying stuff will only result in quite complicated code, carrying failure flags and everything. At the moment the script often just hardly exits on errors.
What I will implement soon(ish): Caching of requested verifications. This will help with the rate limiting, and should speed things up if you really wanted to retry running the script.