On 7/27/26 08:16, Alyssa Ross wrote: > Demi Marie Obenour writes: > >> Signed-off-by: Demi Marie Obenour >> --- >> host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/run | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/run b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/run >> index 78f794202bf174f3c036f3e20755ac087a988277..430065b1efae8ce1fe7c7a07b67920daa88bf98c 100755 >> --- a/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/run >> +++ b/host/rootfs/image/etc/s6-linux-init/run-image/service/vm-services/run >> @@ -1,5 +1,8 @@ >> #!/bin/execlineb -WP >> # SPDX-License-Identifier: EUPL-1.2+ >> # SPDX-FileCopyrightText: 2023 Alyssa Ross >> +# SPDX-FileCopyrightText: 2026 Demi Marie Obenour >> >> +# Set up the parent cgroup of all VMMs and VM services >> +cgroup-setup --no-wait -- /vm-services.slice >> s6-svscan -d3 instance > > We wouldn't want to wait if vm-services was restarted? (I'm not sure > either way, would just like to read the reasoning.) cgroup-setup waits for the cgroup *and all of its transitive child cgroups* to become empty. Therefore, waiting would block until all VMMs had exited and all of their services had stopped. Even if it only waited on /vm-service.slice/$inner.service to become empty, it would still wait for all of the s6-supervise processes in that cgroup to exit. That's unlikely to ever happen. Running more than one instance of s6-svscan (or s6-supervise) is harmless: the program immediately exits with status 100. That will cause it to be restarted indefinitely, consuming CPU. However, I don't know a good alternative unless s6 gets support for bind-mounted pidfds, allowing s6-svscan and s6-supervise to keep track of child processes across restarts. -- Sincerely, Demi Marie Obenour (she/her/hers)