[francislavoie]

Signals don't work on Windows. We want a unified API for all platforms. Also signals don't carry arguments, which is necessary to push a new config. At runtime, Caddy doesn't know where the config came from because config is just data.

[bravetraveler]

Apologies in advance, I'm not trying to be mean spirited or too critical. I'm limited in my ability to express at the moment, on mobile.

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.

[francislavoie]

See https://news.ycombinator.com/item?id=37482096, the plan is to switch to unix socket by default on certain distributions of Caddy.

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

[bravetraveler]

Sockets will definitely be appreciated! It leaves some corner cases I can imagine, but it's definitely a step in the right direction.

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'