# Certbot hangs on stopping server

**URL:** <https://community.letsencrypt.org/t/certbot-hangs-on-stopping-server/102450>\
**Category:** Help\
**Created:** [September 20, 2019, 8:43am UTC](https://community.letsencrypt.org/t/certbot-hangs-on-stopping-server/102450 "2019-09-20T08:43:31Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![emran.bm](https://avatars.discourse-cdn.com/v4/letter/e/85e7bf/32.png) [@emran.bm](https://community.letsencrypt.org/u/emran.bm)\
**Post date:** [September 20, 2019, 8:43am UTC](https://community.letsencrypt.org/t/certbot-hangs-on-stopping-server/102450/1 "2019-09-20T08:43:32Z")

</div>

My domain is: dongap.ir / [dongap.com](http://dongap.com)

I ran this command: sudo kill -9 27915 && sudo certbot certonly --standalone

It produced this output:  
It hangs on cleaning challenges.  
The last log is: “DEBUG:certbot.plugins.standalone:Stopping server at :::80…”

My web server is (include version): No webserver

The operating system my web server runs on is (include version): Ubuntu 16.04

My hosting provider, if applicable, is: haio.cloud

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

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of `certbot --version` or `certbot-auto --version` if you’re using Certbot): 0.31.0

---

<div class="post-metadata">

**Author:** ![JuergenAuer](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/juergenauer/32/26491_2.png) [@JuergenAuer](https://community.letsencrypt.org/u/JuergenAuer)\
**Post date:** [September 20, 2019, 9:00am UTC](https://community.letsencrypt.org/t/certbot-hangs-on-stopping-server/102450/2 "2019-09-20T09:00:21Z")

</div>

Hi @emran.bm

> [@emran.bm](#):
>
> The last log is: “DEBUG:certbot.plugins.standalone:Stopping server at :::80…

looks like you have a running webserver with ipv6, Certbot can't stop that webserver.

Check your system and stop that webserver manual.

---

<div class="post-metadata">

**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\
**Post date:** [September 20, 2019, 9:26am UTC](https://community.letsencrypt.org/t/certbot-hangs-on-stopping-server/102450/3 "2019-09-20T09:26:00Z")

</div>

> [@emran.bm](#):
>
> The last log is: “DEBUG:certbot.plugins.standalone:Stopping server at :::80…”

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.

---

<div class="post-metadata">

**Author:** ![emran.bm](https://avatars.discourse-cdn.com/v4/letter/e/85e7bf/32.png) [@emran.bm](https://community.letsencrypt.org/u/emran.bm)\
**Post date:** [September 20, 2019, 9:31am UTC](https://community.letsencrypt.org/t/certbot-hangs-on-stopping-server/102450/4 "2019-09-20T09:31:37Z")

</div>

Tnx for your reply.  
Yes there are bound connections. 3 in STABLISHED state and 4 in CLOSE\_WAIT.  
What should I do?

---

<div class="post-metadata">

**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\
**Post date:** [September 20, 2019, 9:33am UTC](https://community.letsencrypt.org/t/certbot-hangs-on-stopping-server/102450/5 "2019-09-20T09:33:50Z")

</div>

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`.

> [@emran.bm](#):
>
> What should I do?

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 ☹ .

---

<div class="post-metadata">

**Author:** ![emran.bm](https://avatars.discourse-cdn.com/v4/letter/e/85e7bf/32.png) [@emran.bm](https://community.letsencrypt.org/u/emran.bm)\
**Post date:** [September 20, 2019, 9:37am UTC](https://community.letsencrypt.org/t/certbot-hangs-on-stopping-server/102450/6 "2019-09-20T09:37:17Z")

</div>

Here is the result of `ss -tnp | grep ":80"`:

```auto
CLOSE-WAIT 2486 0 ::ffff:37.187.222.161:80 ::ffff:83.122.182.233:54781              
CLOSE-WAIT 6812 0 ::ffff:37.187.222.161:80 ::ffff:185.158.151.229:41759              
ESTAB 0 0 ::ffff:37.187.222.161:80 ::ffff:188.159.29.158:17329              
ESTAB 0 0 ::ffff:37.187.222.161:80 ::ffff:93.117.96.229:20263              
ESTAB 0 0 ::ffff:37.187.222.161:80 ::ffff:151.242.168.31:15991              
CLOSE-WAIT 9729 0 ::ffff:37.187.222.161:80 ::ffff:46.51.72.31:15608              
CLOSE-WAIT 1872 0 ::ffff:37.187.222.161:80 ::ffff:194.124.33.245:37386

```

Although previous logs say that the challenges failed because they didn’t reach the server!

```auto
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`

---

<div class="post-metadata">

**Author:** ![\_az](https://avatars.discourse-cdn.com/v4/letter/_/22d042/32.png) [@\_az](https://community.letsencrypt.org/u/_az)\
**Post date:** [September 20, 2019, 9:46am UTC](https://community.letsencrypt.org/t/certbot-hangs-on-stopping-server/102450/7 "2019-09-20T09:46:20Z")

</div>

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](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.

---

<div class="post-metadata">

**Author:** ![emran.bm](https://avatars.discourse-cdn.com/v4/letter/e/85e7bf/32.png) [@emran.bm](https://community.letsencrypt.org/u/emran.bm)\
**Post date:** [September 20, 2019, 9:47am UTC](https://community.letsencrypt.org/t/certbot-hangs-on-stopping-server/102450/8 "2019-09-20T09:47:56Z")

</div>

Hmm.

Killed certbot, and connections are gone…

However thanks a lot for your care.

---

<div class="post-metadata">

**Author:** ![emran.bm](https://avatars.discourse-cdn.com/v4/letter/e/85e7bf/32.png) [@emran.bm](https://community.letsencrypt.org/u/emran.bm)\
**Post date:** [September 20, 2019, 2:32pm UTC](https://community.letsencrypt.org/t/certbot-hangs-on-stopping-server/102450/9 "2019-09-20T14:32:34Z")

</div>

Hi.  
I’ve no webserver running.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [October 20, 2019, 2:32pm UTC](https://community.letsencrypt.org/t/certbot-hangs-on-stopping-server/102450/10 "2019-10-20T14:32:36Z")

</div>

Closed on October 20, 2019, 2:32pm UTC

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