Caddy fails on validation when attempting to set up caddy.service (still no success)

1. My Caddy version (caddy C -version):

(devel) [2.0 beta 10]

2. How I run Caddy:

a. System environment:

DigitalOcean VPS running Ubuntu 18.10 with open incoming ports 80 and 443

b. Command:

bill@Bill2:~$ caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
validate: parsing caddyfile tokens for ‘root’: Caddyfile:2 - Error during parsing: Wrong argument count or unexpected line ending after ‘/var/www/wtrenker.com’

The permissions on /etc/caddy/Caddyfile are:

bill@Bill2:~/testflask$ ls -l /etc/caddy/Caddyfile
-rw-r–r-- 1 root root 85 Nov 21 22:17 /etc/caddy/Caddyfile

The Caddy executable is stored in /usr/local/bin.

c. Service/unit/compose file:

I am currently establishing a caddy.service for systemd. I have attempted to use systemctl to start caddy but I always get the parsing error for Caddyfile. I also get the same error when I try to start caddy directly from the command line.

d. My complete Caddyfile:

bill@Bill2:~$ cat /etc/caddy/Caddyfile
wtrenker.com {
root /var/www/wtrenker.com
reverse_proxy localhost:5000 { }
}

3. The problem I’m having:

I am following the instructions at the following caddyserver link:

https://github.com/caddyserver/caddy/tree/master/dist/init/linux-systemd

So far I believe I have carefully set up everything required by the documentation (of course it is all too easy to miss a keystroke).

4. Error messages and/or full log output:

(see above)

5. What I already tried:

When I link caddy into my test directory, validate works**!!!**

bill@Bill2:~/testflask$ ./caddy validate --config Caddyfile --adapter caddyfile
2019/11/21 22:48:04.403 INFO admin admin endpoint started {“address”: “localhost:2019”, “enforce_origin”: false, “origins”: [“localhost:2019”]}
Valid configuration

But when I run the caddy linked into my test directory and refer to the documented location for the Caddyfile, I get the error again:

bill@Bill2:~/testflask$ ./caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
validate: parsing caddyfile tokens for ‘root’: Caddyfile:2 - Error during parsing: Wrong argument count or unexpected line ending after ‘/var/www/wtrenker.com’

I have also experimented with the permissions on the Caddyfile but with no success.

6. Links to relevant resources:

I am getting excited about Caddy as I feel close to putting it into production, replacing Nginx.

Thanks in advance for any help you can provide. Bill

As I previously mentioned, when I validate a Caddyfile that is located in the current directory, validation works fine. The example is:
bill@Bill2:~/PycharmProjects/Glucose$ caddy validate --config Caddyfile --adapter caddyfile
2019/11/22 03:03:23.110 INFO admin admin endpoint started {“address”: “localhost:2019”, “enforce_origin”: false, “origins”: [“localhost:2019”]}
Valid configuration

But when I use the run command, I get an error that refers to “unexpected end of JSON input.” I’m not sure if that has something to do with the Caddyfile adapter’s JSON output.

bill@Bill2:~/PycharmProjects/Glucose$ caddy run --config Caddyfile --adapter caddyfile
2019/11/22 02:59:33.057 INFO admin admin endpoint started {“address”: “localhost:2019”, “enforce_origin”: false, “origins”: [“localhost:2019”]}
2019/11/22 02:59:33.058 INFO http enabling automatic TLS certificate management {“domains”: [“wtrenker.com”]}
2019/11/22 02:59:33.059 INFO http enabling automatic HTTP->HTTPS redirects {“domains”: [“wtrenker.com”]}
2019/11/22 02:59:33.066 INFO tls cleaned up storage units
2019/11/22 02:59:33.068 INFO admin Caddy 2 serving initial configuration
2019/11/22 02:59:33 [INFO][cache:0xc0000a7c20] Started certificate maintenance routine
2019/11/22 02:59:33 [ERROR] wtrenker.com: caching certificate after obtaining it: decoding certificate metadata: unexpected end of JSON input - backing off and retrying (attempt 1/29)…
2019/11/22 02:59:35 [ERROR] wtrenker.com: caching certificate after obtaining it: decoding certificate metadata: unexpected end of JSON input - backing off and retrying (attempt 2/29)…
^C2019/11/22 02:59:36.864 INFO shutting down {“signal”: “SIGINT”}
2019/11/22 02:59:36 [INFO][cache:0xc0000a7c20] Stopped certificate maintenance routine
2019/11/22 02:59:36.865 INFO shutdown done {“signal”: “SIGINT”}

Well, I’m back again with another test result, and this one looks promising. I simply did a soft link of the caddy executable into my project directory, ran Caddy from the project directory (where the Caddyfile also exists) and Caddy started serving on the web just like that!! The command I used is:
bill@Bill2:~/PycharmProjects/Glucose$ sudo ./caddy run --config Caddyfile --adapter caddyfile &

Now to try and get caddy.service working.

I haven’t followed everything in your posts, and I can’t check the documentation now, but for v2 (currently in beta) I think the root directive may need a matcher:

root * /var/www/...

There’s a v2 documentation wiki page at Github in case you haven’t yet seen it. :slight_smile:

Hello David. Thanks for the tip. I tried putting the * in the Caddyfile as a matcher but it doesn’t help. So far it appears that I need a copy (or link to) the caddy executable in the current working directory, and then the Caddyfile has to be in that same directory. When I do that, Caddy runs fine.

I’m fiddling arround with all this directory location stuff as I try to prepare a systemd service for Caddy. The instructions I referenced in the OP have the files located in separate directories: the caddy executable in /usr/local/bin; the Caddyfile in /etc/caddy/; and the root at /var/www/wtrenker.com (in my case).

Thanks again for your input -Bill

I think there’s some other funky stuff going on in your system. I tried your Caddyfile and got the same error you did, because @BrightEyesD’s answer is correct, this is what your Caddyfile should be:

wtrenker.com {
	root * /var/www/wtrenker.com
	reverse_proxy localhost:5000
}

And this validates successfully.

Thanks, Matt. I managed to come up with the same Caddyfile that you just showed me and I’ve had my proxy running just fine for many days solid. I was able to work out a systemd service file for Caddy and one for the proxy software. This has been very encouraging and I have retired Nginx.

All was well until I tried to support serving some static files along with my proxy. I just can’t get a workable Caddyfile for this dual role. I’ve read your instructions on other posts and I have browsed all over Google. One challenge is that there is a lot of information about the version 1 Caddyfile, but things are a bit sparse when it comes to version 2, and that is understandable.

Here is the Caddyfile I have been trying to sort out:

bill@Bill2:/usr/local/bin$ cat Caddyfile
matcher notStatic {
    not {
		file {
			try_files {/home/bill/www}
		}
	}
  }

wtrenker.com {
    root * /var/www/wtrenker.com
    reverse_proxy match:notStatic localhost:5000
    file_server /static browse { root /home/bill/www }
}

and here are the results of running validate on it:

bill@Bill2:/usr/local/caddy$ sudo /usr/local/bin/caddy validate --config /usr/local/bin/Caddyfile --adapter caddyfile
validate: Caddyfile:2: unrecognized directive: not

My version of Caddy is 2.0 beta 10. By the way is it possible to include that version string in the development files whenever you release a new beta so that “caddy version” prints out the beta version? I’m thinking of something like “2.0 beta 10 (devel)”.

Thanks again, Matt.

Cheers, Bill

Remember, the first line of the Caddyfile is always the site to serve (unless you have a global options block at the top). Yours seems to be missing that, so Caddy is confused.

With all the good advice I got here, Caddy has now been running solidly for almost a month. I was able to get a simple caddy.service systemd file working, and I got a proxy to a Python WSGI back-end running smoothly.

Thanks for all the help, --Bill

1 Like

Awesome!! Thanks for the update.

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