Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support listener names for sd-listen #5

Closed
flokli opened this issue Apr 24, 2024 · 12 comments
Closed

support listener names for sd-listen #5

flokli opened this issue Apr 24, 2024 · 12 comments

Comments

@flokli
Copy link
Contributor

flokli commented Apr 24, 2024

As described in https://mgdm.net/weblog/systemd-socket-activation/, it's possible to receive multiple sockets, and they can have names attached.

This can be used to have multiple .socket files (with different FileDescriptorName= values).

For example, one socket could be used for http, and another one for https connections.

@vi
Copy link
Owner

vi commented Apr 24, 2024

How do I test those names and multi-socket mode with systemd-socket-activate (or slimiar tool)?

@flokli
Copy link
Contributor Author

flokli commented Apr 24, 2024

systemd-socket-activate support multiple sockets, and fdnames.

Rememer you need to kick off one request for it to start.

As an example, my rclone patched to support socket activation:

❯ systemd-socket-activate -l 8088 -l 8089 --fdname=foo:bar -- ./rclone serve webdav :local:test/
Listening on [::]:8088 as 3.
Listening on [::]:8089 as 4.
Communication attempt on fd 3.
Execing ./rclone (./rclone serve webdav :local:test/)
2024/04/24 18:14:42 NOTICE: Local file system at /home/flokli/dev/flokli/rclone/test: WebDav Server started on [sd-listen:bar-0/ sd-listen:foo-0/]

@vi
Copy link
Owner

vi commented Apr 24, 2024

What user-facing API do you propose? Something like sd-listen:qqq to explicitly specify one from multiple and err if not found, keeping just sd-listen for the take-arbitrary-one behaviour? Or should plain sd-listen fail if more than one inherited FD is indicated in the environment variables?

@flokli
Copy link
Contributor Author

flokli commented Apr 24, 2024

I think sd-listen should keep the same behaviour (take-arbitrary-one).

I was mostly thinking about supporting parsing "sd-unix:qqq" to ListenerAddress.

@flokli
Copy link
Contributor Author

flokli commented May 3, 2024

Hmmh, I don't quite like the current sd-listen/sd-listen-unix distinction.

We shouldn't have to (let the user) decide about this, I'd feel more comfortable changing the API to return an enum which is either TcpListener or UnixListener, depending on what was actually passed.

And maybe expose another function giving you an API to enumerate the list of FDs passed, as well as getting their names, in addition to the sd-listen:idx_or_name syntax?

@vi
Copy link
Owner

vi commented May 6, 2024

How should it determine whether a file descriptor is a Tcp or Unix socket? Using additional syscall (getsockname)?

@edef1c
Copy link

edef1c commented May 6, 2024

That only identifies the address family. You may also want getsockopt(fd, SOL_SOCKET, SO_TYPE) to disambiguate SOCK_{STREAM,DGRAM,SEQPACKET} etc. Not every passed socket is necessarily a connection-based listener.

@vi
Copy link
Owner

vi commented May 6, 2024

tokio-listener is currently limited to stream and connection-based acceptors by API it exposes.

@vi vi closed this as completed in 689aa87 May 12, 2024
@vi
Copy link
Owner

vi commented May 13, 2024

Implemented, including additional feature: sd-listen:* can now accept from all the sockets simultaneously, if appropriate crate feature is enabled (but it is not enabled by default).

@flokli
Copy link
Contributor Author

flokli commented May 14, 2024

Thanks! Just tested it now, looks good. I noticed you did prepare a 0.4.0 version number, however there doesn't seem to be a tag or release published to crates.io yet.

Can you do this? Thanks!

@vi
Copy link
Owner

vi commented May 15, 2024

Published v0.4.1 with this and also better errors.

@flokli
Copy link
Contributor Author

flokli commented May 15, 2024

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants