Stream: wasi

Topic: systemd socket activation

Soni L. (Mar 31 2024 at 13:47):

how would you implement systemd socket activation with wasi, both as a host and as a guest? as far as we can tell, wasi and systemd socket activation are mutually exclusive/incompatible. is this something that could be resolved in a future wasi version?

Ramon Klass (Mar 31 2024 at 15:16):

wasi is not virtualizing a linux system, you will never be able to "run a systemd instance inside the virtualized container", I don't think this can directly be supported

bjorn3 (Mar 31 2024 at 16:34):

I think the idea of OP is to have a socket activated systemd service which runs the wasm module using wasmtime and then have this wasm module get access to the socket on which it can listen for (web) requests.

Ramon Klass (Mar 31 2024 at 16:41):

that's almost purely a host thing then, but everything I found about systemd socket activation says the protocol is based on a systemd running on the host and in the guest, so I was wondering if that aspect was important

Soni L. (Mar 31 2024 at 16:46):

uh? wasmtime (or some embedder or whatever) is the wasi host, the wasm program is the wasi guest

bjorn3 (Mar 31 2024 at 16:49):

With Socket activation systemd itself creates a socket, and polls it for incoming requests. When an incoming request happens it will start the associated service and pass it the socket as fd using the listenfd protocol (which is basically having the child inherit the fd and setting an env var to tell the child about it.) Listenfd support already exists in Wasmtime. As I understand there is a conflict between the fd assignments required by listenfd and by wasi though. Listenfd expects the first fd to be passed as fd 3, but wasi starts preopened directories from fd 3, so you can't easily have both preopened directories and listenfd support.

bjorn3 (Mar 31 2024 at 16:52):

Wasip2 uses resource handles rather than integer fd's. For getting handles to all preopens there is now preopens.get-directories. For getting handles to the listenfd fds I think there will need to be a separate interface defined.

Soni L. (Mar 31 2024 at 16:56):

ahh

Soni L. (Mar 31 2024 at 16:57):

(yeah we're not particularly familiar with p2 yet... we can't even wrap our head around wasm components .-.)

Soni L. (Mar 31 2024 at 17:00):

we've never heard of "listenfd protocol" tho, that seems to be a rust-specific thing (a crate that implements the systemd socket activation protocol)

bjorn3 (Mar 31 2024 at 17:01):

With "the listenfd protocol" I mean the protocol used by https://www.freedesktop.org/software/systemd/man/latest/sd_listen_fds.html

Ramon Klass (Mar 31 2024 at 17:01):

https://docs.rs/listenfd/latest/listenfd/ as you assumed it's the Rust library that handles working with external sockets

Ramon Klass (Mar 31 2024 at 17:01):

(I'll stop spreading half-knowledge)

bjorn3 (Mar 31 2024 at 17:01):

The listenfd rust crate indeed implements this protocol though.

Soni L. (Apr 02 2024 at 22:03):

we discussed this briefly with sunfish and it seems like it would be best to keep it consistent with dir preopens (in wasip2), so you'd probably have an interface you'd call to get the socket handles. (as opposed to passing them into run.) thanks btw

Last updated: Nov 22 2024 at 16:03 UTC