Caddy 2 Windows oddities

Running Caddy 2 (v2.2.0) in Windows Server 2012 R2, I have come across a number of oddities.

First, using “caddy run” in a command windows works entirely as expected - this was a good start and enabled me to write and debug a new caddyfile.

However, using “caddy start” behaved rather badly. Although the program ran and served sites, using “caddy reload” or “caddy stop” got a response that said the command was “actively rejected”.

Still, I persevered, and continued to set up a service, using nssm, with a command lineof “caddy run”. The first attempt failed completely - caddy would not run. In the end, I changed the login from “LocalSystem” (as used by my caddy v1 installation) to a proper user - the system then ran as expected.

Although the system is serving sites as expected, there is still some other oddity. Specifically, the behaviour of “caddy reload”. Yes, the reload happens as it should, and the expected output appears - but then the program takes 26 minutes (in the instance I actually measured) to return to the command prompt. Admittedly, killing it with ctrl-C appears to have no ill effect, but something is clearly off!


Hmm, that doesn’t seem right. What happens when you run this?

$ curl -v localhost:2019/config/

You should see that you’re connected to Caddy’s admin endpoint, and see your config in JSON form.

When running Caddy with caddy start, Caddy will spin up a process and detach from the terminal, and this process will listen on localhost:2019. Running caddy reload thereafter connects to localhost:2019 to push the new configuration, and Caddy will reload if appropriate.

I just tried caddy reload on my Windows 10 machine, and it works just fine, and returns immediately after finishing:

$ ./caddy reload --config ..\..\..\..\Documents\caddy\Caddyfile
2020/09/30 14:16:17.577 INFO    using provided configuration    {"config_file": "..\\..\\..\\..\\Documents\\caddy\\Caddyfile", "config_adapter": ""}

(I’m using a long relative path because I’m using a Caddy executable built from source)

2012 R2 is pretty old, so that might have something to do with it :thinking:

2012 R2 is supported by MS for another three years yet…

I’ll compare on a 2016 machine, but it would be inconvenient to change (as a retired enthusiast, licence costs matter to me!).


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