James Smith writes: > Forwarding for on this : > > Both systemd and s6, so I might be uniquely qualified here. (Though, I must > admit that I haven't been deep in systemd's internals lately.) > > Any chance I can take a peek at some s6 service directories to get a better > idea of how things work currently? A quick perusal of the spectrum git tree > wasn't terribly enlightening. Hi James, thanks for offering to have a look! For the host, s6 services are here: https://spectrum-os.org/git/spectrum/tree/host/rootfs/etc/s6-linux-init/run-image/service And some s6-rc services are here: https://spectrum-os.org/git/spectrum/tree/host/rootfs/etc/s6-rc My idea for grouping services with s6 was going to be running an s6-svscan instance for each VM, inside a cgroup, running virtiofsd, cloud-hypervisor, etc. below it. That way we'd be able to enforce resource limits per-VM. > On Sat, Aug 16, 2025, 6:11 PM Demi Marie Obenour > wrote: > > I'm working on Spectrum OS (https://spectrum-os.org/) and am > currently porting it from s6 (https://skarnet.org/software/s6-linux-init/) > to systemd. > > Spectrum OS's host (which is what is being ported) is rather > different from a normal system: > > - The root filesystem is completely read-only. There's no writable /var. > I decided to put a tmpfs there for now. > - There is no network access, so /etc/resolv.conf isn't needed. > - The real work happens in VMs, each of which depends on a few services: > - Cloud Hypervisor (https://www.cloudhypervisor.org) which runs the VM. > - crosvm (https://crosvm.dev/book/) used for graphics. > - virtiofsd (https://virtio-fs.gitlab.io) to provide a filesystem > - Spectrum OS's own proxy for the XDG desktop portals > - In the future, an instance of vhost-device-sound > ( > https://github.com/rust-vmm/vhost-device/blob/main/vhost-device-sound/README.md > ) > used for sound > - A per-VM D-Bus daemon > - An instance of xdg-desktop-portal > > If the Cloud Hypervisor instance is stopped or exits, the others > should be stopped automatically, as they have no other use. > Having BindsTo=, After=, PropagatesStopTo=, and PropagatesReloadTo= > should handle most cases, but I don't know if that is sufficient > if Cloud Hypervisor exits spontaneously (because the guest shut down) > or crashes. > > Additionally, these services have different sandboxing needs. > Cloud Hypervisor should only be able to connect to its own instance > of the daemons that serve it, rather than to any instance. > crosvm needs GPU and Wayland access and vhost-device-sound needs > to connect to PipeWire. virtiofsd needs an id-mapped mount. > I would also like to block abstract AF_UNIX socket access. > > Are there existing systemd features that can easily meet these > needs? For the sockets I am thinking of placing them in > RuntimeDirectory= and only giving the correct units access to > those directories. Also, I would like to use `DynamicUser=` > for everything where that is possible.