PSA: systemctl reload caddy will call this api. If you disable it, then reloading the server will no longer work.
The API can still be there, I'm just asking for better integration where feasible. Signal handling on Linux/similar
It's silly to tell my init process to go out 'to the network' to do something it can do directly against the child.
I would not expect turning off an admin API to effectively limit my way to administer the process.
Services will generally ordain a path for a config, overridable with arguments. The same file used then is what is re-read on reload.
Argument/command line changing during a reload isn't a thing, that's restarting. We give it config files as an argument (or implicit default) so that can be reloaded.
It's uncommon to start a process with one file, decide you want a new file path, but keep the PID.
But it won't be possible to add signals support. We've thought hard about it but it's simply not a fit. There's discussion in GitHub: https://github.com/caddyserver/caddy/issues/3967
ie: admin interface disabled, I can't reload to bring it back... because that depends on it.
With sockets we gain a permission model; one simply being in the 'localhost' scope can't do funny/scary things - either a user or another service on the system.
Thank you for the discussion, I'll give it a read - have a meeting then I can finally use my computer to 'catch up'
What if rm would by default just delete everything, as it assumes that makes sense? Stupid comparison, I know, also a stupid default.
It would be more appropriate to handle signals, particularly SIGHUP. That's how most services have been handling reloads.
It's fine to offer an admin API, especially if I want a peer to be able to affect the local instance, but this shouldn't be the position init is placed in.
Put simply, the init process is what we depend on if everything else fails.