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?
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
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.
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
uh? wasmtime (or some embedder or whatever) is the wasi host, the wasm program is the wasi guest
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.
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.
ahh
(yeah we're not particularly familiar with p2 yet... we can't even wrap our head around wasm components .-.)
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)
With "the listenfd protocol" I mean the protocol used by https://www.freedesktop.org/software/systemd/man/latest/sd_listen_fds.html
https://docs.rs/listenfd/latest/listenfd/ as you assumed it's the Rust library that handles working with external sockets
(I'll stop spreading half-knowledge)
The listenfd
rust crate indeed implements this protocol though.
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: Dec 23 2024 at 12:05 UTC