Florian Klink

@cannatag understood. Can we still add an issue to a 3.x milestone, so this won't get lost?

> It sounds like what is being asked for is graceful upgrades/restarts. No, getting this for free is only one side-effect of supporting socket-activation. socket-activation will also cause caddy to...

Ah yes, and because caddy just takes FDs, it doesn't need to `bind()` on its own, which allows applying stronger sandboxing from the outside.

Sockets can have [names attached](https://github.com/coreos/go-systemd/blob/7d375ecc2b092916968b5601f74cca28a8de45dd/activation/listeners.go#L42) (so the user can name them `http` and `https` for example, or `api` and `metrics`), and we could add a syntax to refer to them...

Yes! Or well, I don't want caddy to do any bind on its own at all, but pass in every socket via this mechanism.

> @mholt I did some experiments with registering custom network, it's too much trouble to be worth it. Every site block needs an explicit `bind` and that includes http port...

I'm aware of `CAP_NET_BIND_SERVICE` to allow non-root processes to bind to lower ports, that's not why I'm advocating for this feature. Giving the option to move the whole socket binding...

I wasn't using the `./buildme` script - the build runs in some sandboxed environment without access to `sudo` (and outputs need to go to a custom location), so it won't...

How would the semantics of `NATIVE` be? No cross-compilation involved? If we build this on a raspberry pi or on x86-64-linux, that's both no cross-compilation, it's just that less of...

Yeah, `X86` might be more understandable, but then, we'd need to distinguish between I686 and AMD64 (and every other host cpu we might build this for). It's really a pity...