Demi Marie Obenour writes: > 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. Why is this different to the top-level vmm service? It also just runs s6-svscan, but it does not use --no-wait.