Clean update of caddy following caddyfile update

1. Caddy version (caddy version):

v2.4.5

2. How I run Caddy:

sudo systemctl start/stop/reload/reset-failed caddy

a. System environment:

Ubuntu 20.04 with apt install of caddy

b. Command:

sudo systemctl start caddy

c. Service/unit/compose file:

systemd

d. My complete Caddyfile or JSON config:

root.mydomain.tld {
        # Set this path to your site's directory.
        root * /var/www/html

        # Enable the static file server.
        file_server

        # Another common task is to set up a reverse proxy:
        # reverse_proxy localhost:8080

        # Or serve a PHP site through php-fpm:
        # php_fastcgi localhost:9000
        php_fastcgi unix//run/php/php7.4-fpm.sock

}

service1.mydomain.tld {

        encode zstd gzip
        reverse_proxy xxx.yyy.zzz.aaa:80
        php_fastcgi unix//run/php/php7.4-fpm.sock
}

service2.mydomain.tld {

        encode zstd gzip
        reverse_proxy :2812
        php_fastcgi unix//run/php/php7.4-fpm.sock
}

3. The problem I’m having:

Hi all
I am quite new to caddy and love it thus far but i have to hold my breath every time that i try to amend the caddyfile…
Every time I modify my Caddyfile and try to reload, i get an error message whatever the sequence of commands. It seems that only waiting for a little while after having stopped caddy clears it. I am then able to restart without issue. I am not sure though that this is the expected behaviour…
What is the exact suite of commands to instruct to reload a modified caddyfile without the impression to be breaking the process?
Sorry for the basic question but I could not find explicit guidance on this and it seems to depend on install & environment a lot…

sudo systemctl daemon-reload
sudo systemctl restart caddy

or

caddy stop
caddy reload -confic /path/to/config
caddy start

4. Error messages and/or full log output:

Output of sudo systemctl status caddy

Sep 21 12:43:47 root.mydomain.tld caddy[3006]: {"level":"info","ts":1632221027.5625596,"logger":"http","msg":"enabling automatic HTTP->
Sep 21 12:43:47 root.mydomain.tld caddy[3006]: {"level":"info","ts":1632221027.5625982,"logger":"http","msg":"enabling automatic HTTP->
Sep 21 12:43:47 root.mydomain.tld caddy[3006]: {"level":"info","ts":1632221027.5650213,"logger":"tls","msg":"cleaning storage unit","d>
Sep 21 12:43:47 root.mydomain.tld caddy[3006]: {"level":"info","ts":1632221027.5655785,"logger":"tls.cache.maintenance","msg":"stopped>
Sep 21 12:43:47 root.mydomain.tld systemd[1]: Started Caddy.
Sep 21 12:43:47 root.mydomain.tld caddy[3006]: 2021/09/21 12:43:47 [ERROR] Deleting old OCSP staples: context canceled
Sep 21 12:43:47 root.mydomain.tld caddy[3006]: run: loading initial config: loading new config: http app module: start: tcp: listening>
Sep 21 12:43:47 root.mydomain.tld systemd[1]: caddy.service: Main process exited, code=exited, status=1/FAILURE
Sep 21 12:43:47 root.mydomain.tld systemd[1]: caddy.service: Failed with result 'exit-code'.
Sep 21 12:43:49 root.mydomain.tld systemd[1]: caddy.service: Unit cannot be reloaded because it is inactive.

output of sudo caddy cmd

2021/09/21 10:45:46.946	WARN	failed using API to stop instance	{"error": "performing request: Post \"http://localhost:2019/stop\": dial tcp [::1]:2019: connect: connection refused"}
stop: performing request: Post "http://localhost:2019/stop": dial tcp [::1]:2019: connect: connection refused

5. What I already tried:

A number of permutations of commands…

6. Links to relevant resources:

The error message is cut off here.

Don’t use systemctl status caddy to view the logs, because it truncates them. Please instead use the journalctl command outlined on this page in the docs:

It doesn’t make sense to both have reverse_proxy and php_fastcgi in your config, without a request matcher.

Caddy sorts directives according to a predetermined directive order, and reverse_proxy is ordered higher than php_fastcgi so it will take precedence. Requests will never reach php_fastcgi in that config.

If you actually need to proxy some requests, and serve others with PHP, then you’ll need to use request matchers to tell Caddy when to use reverse_proxy and when to use php_fastcgi.

But you probably just want to remove php_fastcgi here otherwise.

Hi Francis

Thanks a lot for looking at this. Please see below the output of journalctl:

Sep 21 12:32:26 root.mydomain.tld systemd[1]: Starting Caddy...
Sep 21 12:32:27 root.mydomain.tld caddy[669]: caddy.HomeDir=/var/lib/caddy
Sep 21 12:32:27 root.mydomain.tld caddy[669]: caddy.AppDataDir=/var/lib/caddy/.local/share/caddy
Sep 21 12:32:27 root.mydomain.tld caddy[669]: caddy.AppConfigDir=/var/lib/caddy/.config/caddy
Sep 21 12:32:27 root.mydomain.tld caddy[669]: caddy.ConfigAutosavePath=/var/lib/caddy/.config/caddy/autosave.json
Sep 21 12:32:27 root.mydomain.tld caddy[669]: caddy.Version=v2.4.5 h1:################################################
Sep 21 12:32:27 root.mydomain.tld caddy[669]: runtime.GOOS=linux
Sep 21 12:32:27 root.mydomain.tld caddy[669]: runtime.GOARCH=amd64
Sep 21 12:32:27 root.mydomain.tld caddy[669]: runtime.Compiler=gc
Sep 21 12:32:27 root.mydomain.tld caddy[669]: runtime.NumCPU=2
Sep 21 12:32:27 root.mydomain.tld caddy[669]: runtime.GOMAXPROCS=2
Sep 21 12:32:27 root.mydomain.tld caddy[669]: runtime.Version=go1.17
Sep 21 12:32:27 root.mydomain.tld caddy[669]: os.Getwd=/
Sep 21 12:32:27 root.mydomain.tld caddy[669]: LANG=en_US.UTF-8
Sep 21 12:32:27 root.mydomain.tld caddy[669]: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
Sep 21 12:32:27 root.mydomain.tld caddy[669]: NOTIFY_SOCKET=/run/systemd/notify
Sep 21 12:32:27 root.mydomain.tld caddy[669]: HOME=/var/lib/caddy
Sep 21 12:32:27 root.mydomain.tld caddy[669]: LOGNAME=caddy
Sep 21 12:32:27 root.mydomain.tld caddy[669]: USER=caddy
Sep 21 12:32:27 root.mydomain.tld caddy[669]: INVOCATION_ID=fb57128cc38d47e8ad43dcb17825c912
Sep 21 12:32:27 root.mydomain.tld caddy[669]: JOURNAL_STREAM=9:22801
Sep 21 12:32:27 root.mydomain.tld caddy[669]: {"level":"info","ts":1632220347.9903631,"msg":"using provided configuration","config_file":"/etc/caddy/Caddyfile","config_adapter":""}
Sep 21 12:32:27 root.mydomain.tld caddy[669]: {"level":"warn","ts":1632220347.998135,"msg":"input is not formatted with 'caddy fmt'","adapter":"caddyfile","file":"/etc/caddy/Caddyfile","line":24}
Sep 21 12:32:28 root.mydomain.tld caddy[669]: {"level":"info","ts":1632220348.0262878,"logger":"admin","msg":"admin endpoint started","address":"tcp/localhost:2019","enforce_origin":false,"origins":["localhost:2019","[::1]:2019","127.0.0.1:2019"]}
Sep 21 12:32:28 root.mydomain.tld caddy[669]: {"level":"info","ts":1632220348.0304258,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv0"}
Sep 21 12:32:28 root.mydomain.tld caddy[669]: {"level":"info","ts":1632220348.0305285,"logger":"http","msg":"server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS","server_name":"srv1","https_port":443}
Sep 21 12:32:28 root.mydomain.tld caddy[669]: {"level":"info","ts":1632220348.030557,"logger":"http","msg":"enabling automatic HTTP->HTTPS redirects","server_name":"srv1"}
Sep 21 12:32:28 root.mydomain.tld caddy[669]: {"level":"info","ts":1632220348.0464654,"logger":"tls.cache.maintenance","msg":"started background certificate maintenance","cache":"0xc000334700"}
Sep 21 12:32:28 root.mydomain.tld caddy[669]: {"level":"info","ts":1632220348.054475,"logger":"tls.cache.maintenance","msg":"stopped background certificate maintenance","cache":"0xc000334700"}
Sep 21 12:32:28 root.mydomain.tld systemd[1]: Started Caddy.
Sep 21 12:32:28 root.mydomain.tld caddy[669]: run: loading initial config: loading new config: http app module: start: tcp: listening on :2019: listen tcp :2019: bind: address already in use
Sep 21 12:32:28 root.mydomain.tld systemd[1]: caddy.service: Main process exited, code=exited, status=1/FAILURE
Sep 21 12:32:28 root.mydomain.tld systemd[1]: caddy.service: Failed with result 'exit-code'.

As for your other suggestions, I have not yet tested many configs/parameters as i do not seem to be able to cleanly reload configs & caddy2. The php line for the reverse_proxy is a legacy from the declaration of root.mydomain.tld that i will clean up following your suggestion.

This means you probably have another instance of Caddy running. Make sure to kill any other instances.

You can run ps ax | grep caddy to see what’s running. The first number on each line will be the process ID. Then you can run kill <pid> to stop it. Then start the systemd process again.

This usually happens when you’ve run Caddy with caddy start, not as a systemd service.

If that doesn’t help, then you must have some other program running and bound to port 2019. You can run sudo netstat -lntup | grep 2019 to see which one might be using that port (process ID followed by a slash, then the process name, at the end of the line).

Thanks Francis, that is what i thought. Just to confirm (and not attempt to restart an instance every time I update), the correct way to restart caddy after a caddyfile update would be the following?

sudo systemctl daemon-reload
sudo systemctl restart caddy

or should I do anything different?
Thanks for your patience
M

No, you should use sudo systemctl reload caddy.

Using daemon-reload tells systemd to load any changes to systemd unit files. Not relevant here, unless you did change the caddy.service unit file.

Running sudo systemctl restart caddy will completely restart Caddy, incurring downtime. If you already have Caddy running, don’t use this, instead use sudo systemctl reload caddy which is a graceful reload with a new configuration, with zero downtime.

If Caddy isn’t running because of some config error, then sudo systemctl restart caddy is the same as sudo systemctl start caddy, because it wasn’t already running anyways. So it’s fine in that sense. But best to stick with only start and reload, and don’t use restart unless you absolutely need to.

OK - makes sense - thanks a lot!

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