Support socket activation for mdbook serve - #3093
Conversation
67b5b46 to
a25052e
Compare
This comment has been minimized.
This comment has been minimized.
GuillaumeGomez
added
the
A-needs-discussion
|
Sorry for the delay. No opinion on this feature, what do you think about it @rust-lang/mdbook ? |
|
I’m in favor. It’s not very complicated, and people do use it. |
|
@rfcbot fcp merge mdbook |
|
@GuillaumeGomez has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
|
Thanks! Glad to hear there is acceptance of this sort of thing. |
Add a `--socket-activate` flag that adopts a pre-bound TCP listener from `LISTEN_FDS` instead of binding a new one. This allows process managers like foreman (with Socketfile support) or systemd to own the socket, so it survives server restarts. Three modes: - `--socket-activate`: require a passed-in socket, fail if absent - `--port N` / `--hostname H`: always bind, ignore `LISTEN_FDS` - Neither: try `LISTEN_FDS` first, fall back to binding the default The listener is now bound in the main thread before spawning the server, so the actual address is always known for logging and `--open`. Also parse `--port` as `u16` at arg-parse time instead of leaving it as a string. Socket activation is normally associated with systemd. And indeed, it would be peculiar to wire up this development command with systemd, but it is also used in other contexts more appropriate to this command, like https://github.com/mitsuhiko/systemfd, a development tool. From a Capsicum/WASI perspective, it also is generally better when tools can consume resources provided by a more privileged caller, rather than having to open them themselves. For these reasons, I think everything should support socket-activation.
a25052e to
160c043
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
5 participants
Add a
--socket-activateflag that adopts a pre-bound TCP listener fromLISTEN_FDSinstead of binding a new one. This allows process managers like foreman (with Socketfile support) or systemd to own the socket, so it survives server restarts.Three modes:
--socket-activate: require a passed-in socket, fail if absent--port N/--hostname H: always bind, ignoreLISTEN_FDSLISTEN_FDSfirst, fall back to binding the defaultThe listener is now bound in the main thread before spawning the server, so the actual address is always known for logging and
--open.Also parse
--portasu16at arg-parse time instead of leaving it as a string.Socket activation is normally associated with systemd. And indeed, it would be peculiar to wire up this development command with systemd, but it is also used in other contexts more appropriate to this command, like https://github.com/mitsuhiko/systemfd, a development tool. From a Capsicum/WASI perspective, it also is generally better when tools can consume resources provided by a more privileged caller, rather than having to open them themselves. For these reasons, I think everything should support socket-activation.