Tried to restart caddy...it failed and won't restart

Help
1

1. Caddy version (caddy version):

2.2.1

2. How I run Caddy:

[Unit]

Description=Caddy

Documentation=https://caddyserver.com/docs/

After=network.target network-online.target

Requires=network-online.target

[Service]

User=caddy

Group=caddy

ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile

ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile

TimeoutStopSec=5s

LimitNOFILE=1048576

LimitNPROC=512

PrivateTmp=true

ProtectSystem=full

AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]

WantedBy=multi-user.target

a. System environment:

CentOS 7

b. Command:

sudo systemctl start caddy

or alternately:

caddy start

c. Service/unit/compose file:

paste full file contents here

d. My complete Caddyfile or JSON config:

http:// {
    tls off
    file_server {
            root /etc/hyperglass/static/ui
            index /etc/hyperglass/static/ui/index.html
        }
        file_server /custom {
            root /etc/hyperglass/static/custom
        }
        file_server /images {
            root /etc/hyperglass/static/images
        }
    reverse_proxy localhost:8001
}

3. The problem I’m having:

Caddy has been running for over two months with no problem, but I needed to add a TLS cert. I copied the existing Caddyfile to old_Caddyfile and changed the tls directives, then tried to restart Caddy. It failed, so I deleted the Caddyfile and moved the old_Caddyfile back to Caddyfile, but caddy still will not start. It’s using the exact same file I used to start it last time.

4. Error messages and/or full log output:

caddy start

2021/03/08 23:06:35.124 INFO using adjacent Caddyfile

run: adapting config using caddyfile: parsing caddyfile tokens for ‘tls’: Caddyfile:2 - Error during parsing: single argument must either be ‘internal’ or an email address

start: caddy process exited with error: exit status 1

$ sudo systemctl status caddy

● caddy.service - Caddy

Loaded: loaded (/usr/lib/systemd/system/caddy.service; enabled; vendor preset: disabled)

Active: failed (Result: exit-code) since Mon 2021-03-08 22:53:02 UTC; 2s ago

Process: 4609 ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile (code=exited, status=1/FAILURE)

Main PID: 4609 (code=exited, status=1/FAILURE)

Mar 08 22:53:02 bblg-ho-01.sys.comcast.net systemd[1]: Started Caddy.

Mar 08 22:53:02 bblg-ho-01.sys.comcast.net systemd[1]: caddy.service: main process exited, code=exited, status=1/FAILURE

Mar 08 22:53:02 bblg-ho-01.sys.comcast.net systemd[1]: Unit caddy.service entered failed state.

Mar 08 22:53:02 bblg-ho-01.sys.comcast.net systemd[1]: caddy.service failed.

5. What I already tried:

I restored the original caddyfile and have tried restarting it using “caddy start” as well as “systemctl start caddy”, but there is no difference in the end result. It seems to be failing because of “tls off” in the Caddyfile, but that’s what was there when I started and it was working. I remember having difficulties getting this to work a couple of months ago, but I don’t remember don’t anything specific to make this work. I’ve looked back in my command history and don’t see any clues to indicate I did anything special.

6. Links to relevant resources:

2

Caddy v2 does not have tls off. That’s something from Caddy v1. Caddy v2 is a complete rewrite from the ground up, so you can’t assume that it will be configured the same way.

Also, path matching is exact in Caddy v2, so /custom will only match exactly /custom and not /custom/foo. Use a * suffix on your path matcher to also match everything below that path.

This line is redundant - Caddy’s file_server will look for an index file automatically by default.

And finally, you have a both file_server and reverse_proxy in the same site without matchers (the first file_server has no matcher) which doesn’t make sense. The reverse_proxy will take precedence over your first file_server because HTTP handler directives are sorted according to a predetermined order (seen at the link below), and the reverse_proxy handler is terminal (meaning that no handlers that come after it will be run).

1 Like
3

Thank you for the reply! I’m even more confused at how it has been running with that config for two months. I have no idea how I got it running before. I originally had it running with a Caddyfile from another directory. I wonder if somehow it has been running based on the other file this entire time. That’s not what I see when looking back at command history, but I don’t see how it’s possible that it could have ever run from this file.

I’ll do some digging. This has been in production for a while and now I honestly don’t have any idea what to do to get it working. It’s a basic http/80 site. The auto-https feature broke because this server cannot reach the internet. I had to disable all of that, but now I can’t figure out how I did it. I’m honestly stumped.

4

The docs say this about matchers:

Matcher tokens are usually optional. If a matcher token is omitted, it is the same as a wildcard matcher (* ).

Based on your advice, I changed the Caddyfile to the following and all seems to be well now:

http:// {
    file_server {
            root /etc/hyperglass/static/ui
        }
        file_server /custom/* {
            root /etc/hyperglass/static/custom/
        }
        file_server /images/* {
            root /etc/hyperglass/static/images/
        }
    reverse_proxy localhost:8001
}

Thank you very much for the help! I’m still completely stumped about how this was ever running in the first place.

5

Matchers are optional, but if you have two different terminal handlers that are both wildcard, then only the one that’s sorted higher will be used. This means your reverse_proxy will take precedence over your file_server for /etc/hyperglass/static/ui.

6

Ah, I understand now. It’s been so long since this was originally configured that I don’t remember why the reverse proxy part is even in there. I can probably remove it.

1 Like
7

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