caddy: caddy reload does not return to the command line when finished

Hello,

I’m experiencing this same behaviour as issue #3341 on latest v2.1.1 release (didn’t happen on 2.0.0).

caddy@myserver:~$ caddy version
v2.1.1 h1:X9k1+ehZPYYrSqBvf/ocUgdLSRIuiNiMo7CvyGUQKeA=

This is what happens:

caddy@myserver:~$ caddy reload --config /etc/caddy/Caddyfile
2020/07/01 10:55:14.457	INFO	using provided configuration	{"config_file": "/etc/caddy/Caddyfile", "config_adapter": ""}

and stays like this until I hit CTRL-C. As a consequence, even sudo systemctl reload caddy is failing for timeout. However, the configuration seems to get reloaded properly.

On Caddy side, I only see this log being outputted:

{"level":"info","ts":1593613252.249103,"logger":"admin.api","msg":"received request","method":"POST","host":"localhost:2019","uri":"/load","remote_addr":"127.0.0.1:43840","headers":{"Accept-Encoding":["gzip"],"Content-Length":["2503"],"Content-Type":["application/json"],"Origin":["localhost:2019"],"User-Agent":["Go-http-client/1.1"]}}

Nothing else is reported about the reload.

My Caddyfile is quite simple (I just replaced the domain since it’s a customer’s one):

monitor.mydomain.com {
    route /netdata/* {
        uri strip_prefix /netdata
        reverse_proxy 127.0.0.1:19999
    }
    redir /netdata /netdata/

    basicauth /netdata/* {
        bob JDJhJDEwJEVCNmdaNEg2Ti5iejRMYkF3MFZhZ3VtV3E1SzBWZEZ5Q3VWc0tzOEJwZE9TaFlZdEVkZDhX
    }
}

http://sub1.mydomain.com,
https://sub1.mydomain.com {
    reverse_proxy 127.0.0.1:8000
}

http://sub2.mydomain.com,
https://sub2.mydomain.com {
    reverse_proxy 127.0.0.1:8001
}

http://sub3.mydomain.com,
https://sub3.mydomain.com {
    reverse_proxy 127.0.0.1:8002
}

http://sub4.mydomain.com,
https://sub4.mydomain.com {
    reverse_proxy 127.0.0.1:8003
}

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 19 (7 by maintainers)

Most upvoted comments

😃 Just to be clear. This is why I told my neighbor to call my patch ‘dirty workaround’. It is clear that this would not solve anything but highlight the issue.

ok, so grace_period is related, but not in the code path that’s responsible for my trouble. My neighbor was so nice to start the debugger, this is his wip hotfix: https://github.com/burton1982/caddy/pull/1

I found the solution, it’s a missing grace_period - if there is a connection that makes the reload hang beyond the timeout of systemd, reload is effectively ignored.

@m3nu And this is with a grace period set?