Possible to keep Caddy up even if there is a single server runtime error?


One somewhat irritating thing about caddy (and it may not be caddy but systemd) is that when a single entry has an error it brings the whole caddy server down.

For example I have a entry like so

https://xxxxx.org {
        tls xxxxxr@gmail.com
        fastcgi / /var/run/php/php7.2-fpm.sock php
        root /mnt/data/webs/smnordic
    rewrite / {
        if {path} not_match ^\/wp-admin
        to {path} {path}/ /index.php?_url={uri}

and because the dns record has not propogated letsencryt throws an error that then brings the whole Caddy server down even though all the other entries(servers) are fine. This is a bummer cause when I am trying to work out the settings for a new server I end up bringing the Caddy down. This can’t really be intended???

I run caddy via a systemd service so I tried putting a - in the start command per docker - Reset / Ingnore non-zero exit code with fleet / systemd - Server Fault but that did not work.

I understand if there is a syntax error then it wont run no matter what but can’t a runtime error of a single server entry not bring all of caddy down? If so how?

BTW is this issue addressed in V2? If I send v2 a bad entry or have a runtime issue on a single server’s settings will that not affect the rest of my operational caddy server?

here is my current unit file

Description=Caddy HTTP/2 web server
After=network-online.target mnt-data.mount
Wants=network-online.target systemd-networkd-wait-online.service


; User and group the process will run as.

; Letsencrypt-issued certificates will be written to this directory.

; Always set "-root" to something safe in case it gets forgotten in the Caddyfile.
ExecStart=-/opt/caddy/caddy -log stdout -agree=true -conf=/opt/caddy/caddy.conf -root=/var/tmp 
ExecReload=/bin/kill -USR1 $MAINPID

; Use graceful shutdown with a reasonable timeout

; Limit the number of file descriptors; see `man systemd.exec` for more limit settings.
; Unmodified caddy is not expected to use more than that.

; Use private /tmp and /var/tmp, which are discarded after caddy stops.
; Use a minimal /dev (May bring additional security if switched to 'true', but it may not work on Raspberry Pi's or other devices, so it has been disabled in this dist.)
; Hide /home, /root, and /run/user. Nobody will steal your SSH-keys.
; Make /usr, /boot, /etc and possibly some more folders read-only.
; … except /etc/ssl/caddy, because we want Letsencrypt-certificates there.
;   This merely retains r/w access rights, it does not add any new. Must still be writable on the host!

; The following additional security directives only work with systemd v229 or later.
; They further restrict privileges that can be gained by caddy. Uncomment if you like.
; Note that you may have to add capabilities required by any plugins in use.


Actually, Caddy doesn’t “bring the whole server down” just because one domain can’t resolve. That’s a common misconception which is explained here, and which is not unique to Caddy: How to have bad domain in config skipped - #2 by matt

In Caddy 2, certificate management is asynchronous by default.

1 Like

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