Status stays in processing

rickjanssen · March 28, 2018, 2:54pm

My domain is: phptest70.web0080.zxcs.nl

I ran this command: request with http validation for phptest70.web0080.zxcs.nl testy.phptest70.web0080.zxcs.nl werwer.phptest70.web0080.zxcs.nl westest.phptest70.web0080.zxcs.nl as multi domain certificate

It produced this output:
Expires: Wed, 28 Mar 2018 12:54:46 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache

HTTP/1.1 500 Internal Server Error
Server: nginx
Content-Type: application/problem+json
Content-Length: 112
Boulder-Requester: 5824585
Replay-Nonce: mcD90Wj_OTWnPcHg8Mu43aZbD_ILhNnPDJxY27dJN8c
Expires: Wed, 28 Mar 2018 12:55:17 GMT
Cache-Control: max-age=0, no-cache, no-store
Pragma: no-cache
Date: Wed, 28 Mar 2018 12:55:17 GMT
Connection: close, the body is: Array
(
[type] => urn:ietf:params:acme:error:serverInternal
[detail] => Error finalizing order
[status] => 500
)

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

mnordhoff · March 28, 2018, 3:06pm

That sounds like most likely this issue...

github.com/letsencrypt/boulder

SA.GetValidAuthorizations fetches too much

opened 12:21AM - 20 Mar 18 UTC

closed 06:04PM - 27 Mar 18 UTC

jsha

area/sa kind/performance kind/bug

In SA.GetValidAuthorizations, we query for all authorizations that match a given… identifier, then fetch challenges for them, and then throw away all but the most recent of the authorizations for each identifier, as indicated by the Expires field. The number of authorizations can be quite large in certain circumstances, meaning we fetch a lot of challenges that we subsequently throw away. This can result in query timeouts. We should only fetch challenges for the authorizations we intend to return. Since we already have an index on the Expires field, we could just add an `ORDER BY expires DESC` to the query, which would ensure that we iterate through in order by optimality and throw away the authorizations we don't care about.

If so, the fix might be deployed tomorrow or April 5?

rickjanssen · March 28, 2018, 3:16pm

I can’t tell if the problem is the same, but when I request the status of my domain now, it hangs in processing now

rickjanssen · March 28, 2018, 3:34pm

Order URL: https://acme-staging-v02.api.letsencrypt.org/acme/order/5824585/164623

rickjanssen · March 29, 2018, 9:56am

Can someone look into this? It still says “processing”.

schoen · March 29, 2018, 3:23pm

@jsha, could you confirm whether this is likely to be an instance of a known problem?

jsha · March 29, 2018, 4:17pm

We’ll take a look. Thanks!

rickjanssen · April 3, 2018, 8:30am

Could you find anything?

rickjanssen · April 13, 2018, 8:52am

@jsha Could you find anything?

cpu · April 13, 2018, 6:54pm

The order finalization failed from a timeout on the ACME server side that was aggravated during periods of increased traffic in the staging environment ~30d ago. This normally flips the order from "processing" to invalid, but that operation timed out too. We're aware this can happen and there's an outstanding ticket to implement a daemon to reap these stuck orders: ACMEv2: deal with perpetual "processing" orders · Issue #3427 · letsencrypt/boulder · GitHub

You should submit a fresh newOrder request for the same identifiers.

system · May 13, 2018, 6:54pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.