Caddy can be controlled using an admin API endpoint that it serves on localhost:2019. Having that enabled is not ideal from a security perspective, because any user able to log in may connect to it.
Disabling it with `admin off` in the global config breaks `service caddy reload` as well as `service caddy stop`. The former (as of Caddy 2) does not appear to have an alternative anymore, but perhaps at least the latter could be rewritten using to make use of `kill`? Meanwhile, I'll then file an issue with the Caddy project so we can hopefully fix reloading after.
I was wondering about that. It's certainly not ideal; I'd far prefer to have the admin API off. Caddy doesn't document which signals it responds to. It'd be nice to have a graceful shutdown signal, a reload signal, and a reopen logs signal, but I have no idea which (if any) of those it responds to.
Here's a comment I found in the source: "trapSignalsCrossPlatform captures SIGINT or interrupt (depending on the OS), which initiates a graceful shutdown. A second SIGINT or interrupt will forcefully exit the process immediately."
The reload signal I brought up here: https://github.com/caddyserver/caddy/issues/3967#issuecomment-820943864. Not sure what you mean by reloading logs?
Correction: reopening logs.