Do you know whether anything is bound to port 80 at the time when Certbot is hung?
For example, is it listed by:
ss -tlnp | grep ":80"
This would be useful to distinguish whether the standalone server is still actually running, or whether Certbot has moved onto something else (but hasn't logged about it).
One reason that the underlying shutdown() operation of the standalone server may hang is if there is a client connected to it who is not disconnecting. You could confirm this by running the following when it is hung:
ss -tn | grep ":80"
If there is a client connected, it should be listed by the above, and it would explain why Certbot would be hung: it is waiting for the client to disconnect before it stops the standalone server entirely.
Those are connections inbound to the local port 80 server, right?
Where are the connections coming from? You might be able to deduce more information by adding a -p (process) parameter to ss.
Unfortunately I'm 99% sure this is a Certbot bug. It should not wait indefinitely to drain unexpected client connections when shutting down the standalone server. I've reproduced it locally and I'm about to file an issue.
The question is, where are those ESTABLISHED connections coming from? They're causing the problems .
Although previous logs say that the challenges failed because they didn’t reach the server!
certbot.errors.FailedChallenges: Failed authorization procedure. dongap.ir (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://dongap.ir/.well-known/acme-challenge/12hUISBU3M2fQRZ1EE_Z1vuR1-7H8wF_ajIwcAehQP8: Timeout during connect (likely firewall problem)
I tried to curl the challenge url (when hung), from my pc; it says: curl: (56) Recv failure: Connection reset by peer
I’m not quite sure what you should do, other than kill -9 the Certbot process.
If those 3 ESTABLISHED connections stay open, so will Certbot .
I’ve now filed the bug (https://github.com/certbot/certbot/issues/7386) but I can’t really think of a good workaround, other than using a real webserver like nginx or Apache (with --nginx or --apache) and not using --standalone mode.