Caddy keeps crashing out with 'goroutine' message

[phikl]

1. My Caddy version (caddy -version):

v1.0.4

2. How I run Caddy:

/opt/caddy/caddy

a. System environment:

Ubuntu 18.04

b. Command:

caddy

3. The problem I’m having:

Start caddy through the usual command and as I always have for over a year now and after about 15 minutes starts spewing out 1000’s of lines of text (see below - I’ve only included part of the text as it is huge and is all very similar) and all external access is lost. The only thing that has changed on my network is new pi-hole (gone virtual). Nothing else has changed at all not even any new entries in the caddyfile.

4. Error messages and/or full log output:

goroutine 442877 [chan receive]:
net/http.http2closeWaiter.Wait(…)
/usr/local/go/src/net/http/h2_bundle.go:3314
net/http.(*http2responseWriter).CloseNotify.func1(0xc05e42f0e0, 0xc05e386700)
/usr/local/go/src/net/http/h2_bundle.go:6147 +0x34
created by net/http.(*http2responseWriter).CloseNotify
/usr/local/go/src/net/http/h2_bundle.go:6146 +0xf8

5. What I already tried:

Updating caddy and apt update && apt upgrade

Please can someone help. If I’m totally honest I’m more of a hardware guy!

[Whitestrake (Matthew Fay)]

Hi @phikl, welcome to the Caddy community.

Can you post the exact output of caddy -version and caddy -plugins please?

This may need to go to a Github issue to investigate further. That log line you’ve given only indicates the errors within net/http. Posting the entire error log might also be necessary if you can share it via Pastebin or similar.

[phikl]

Hi @Whitestrake

Ta for the reply:

caddy -version:
Caddy v1.0.4 (h1:wwuGSkUHo6RZ3oMpeTt7J09WBB87X5o+IZN4dKehcQE=)

caddy -plugins:
Server types:
http

Caddyfile loaders:
short
flag
default

Other plugins:
http.basicauth
http.bind
http.browse
http.errors
http.expvar
http.ext
http.fastcgi
http.gzip
http.header
http.index
http.internal
http.limits
http.log
http.markdown
http.mime
http.pprof
http.proxy
http.push
http.redir
http.request_id
http.rewrite
http.root
http.status
http.templates
http.timeouts
http.websocket
on
tls
tls.cluster.file

Just woke up so will post the error log a bit later.

[phikl]

Had to use ControlC as it was way past the 512KB limit for pastebin but output here:

Caddy Output - 4373383a

[matt (Matt Holt)]

Thanks, but that output is still truncated at the top. It seems to be missing the first lines, which contains the actual error message.

[phikl]

Hi Matt

Thanks for your reply.

That’s the problem the error spits out so much and so fast it cut’s off the first few lines in my console.

Any suggestions?

Phil

[matt (Matt Holt)]

I would just upload the whole log file.

[phikl]

Ok cool. Where do I find that? (sorry)

[matt (Matt Holt)]

Where did you get the log output before? Same place. Just get the whole thing.

[phikl]

From the command line. This is what I’m saying, it fires off so much text that it totally cuts off the top and I can’t scroll up any further.

[magikstm]

Did you enable log and error logging in your caddyfile?

Are you able to reproduce the issue?

Add these lines in your caddyfile on sites if you don’t have them already:

log
errors error.log

Ref:
https://caddyserver.com/v1/docs/errors
https://caddyserver.com/v1/docs/log

[matt (Matt Holt)]

As @magikstm said, if we can reproduce the bug easily, that’s another option for fixing this. However, if you can get the full log output as he suggested, that will speed things up.

Ideally, we need to be able to reproduce the bug in the most minimal way possible. This allows us to write regression tests to verify the fix is working. If we can’t reproduce it, then you’ll have to test our changes for us until it’s fixed – and then we can’t add test cases, either.

I’ve attached a template below that will help make this easier and faster! It will ask for some information you’ve already provided; that’s OK, just fill it out the best you can.

I’ve also included some helpful tips below the template. Feel free to let me know if you have any questions!

Template

## 1. Environment

### 1a. Operating system and version

```
paste here
```


### 1b. Caddy version (run `caddy version` or paste commit SHA)

```
paste here
```


### 1c. Go version (if building Caddy from source; run `go version`)

```
paste here
```


## 2. Description

### 2a. What happens (briefly explain what is wrong)




### 2b. Why it's a bug (if it's not obvious)




### 2c. Log output

```
paste terminal output or logs here
```



### 2d. Workaround(s)




### 2e. Relevant links




## 3. Tutorial (minimal steps to reproduce the bug)

Helpful tips

1. Environment: Please fill out your OS and Caddy versions, even if you don’t think they are relevant. (They are always relevant.) If you built Caddy from source, provide the commit SHA and specify your exact Go version.

2. Description: Describe at a high level what the bug is. What happens? Why is it a bug? Not all bugs are obvious, so convince readers that it’s actually a bug.

   • 2c) Log output: Paste terminal output and/or complete logs in a code block. DO NOT REDACT INFORMATION except for credentials.
   • 2d) Workaround: What are you doing to work around the problem in the meantime? This can help others who encounter the same problem, until we implement a fix.
   • 2e) Relevant links: Please link to any related issues, pull requests, docs, and/or discussion. This can add crucial context to your report.

3. Tutorial: What are the minimum required specific steps someone needs to take in order to experience the same bug? Your goal here is to make sure that anyone else can have the same experience with the bug as you do. You are writing a tutorial, so make sure to carry it out yourself before posting it. Please:

   • Start with an empty config. Add only the lines/parameters that are absolutely required to reproduce the bug.
   • Do not run Caddy inside containers.
   • Run Caddy manually in your terminal; do not use systemd or other init systems.
   • If making HTTP requests, avoid web browsers. Use a simpler HTTP client instead, like curl.
   • Do not redact any information from your config (except credentials). Domain names are public knowledge and often necessary for quick resolution of an issue!
   • Note that ignoring this advice may result in delays, or even in your issue being closed. Only actionable issues are kept open, and if there is not enough information or clarity to reproduce the bug, then the report is not actionable.

Example of a tutorial:

Create a config file:

{ ... }

Open terminal and run Caddy:

$ caddy ...

Make an HTTP request:

$ curl ...

Notice that the result is ___ but it should be ___.