Elaborating on the issue, here's (rootless) Docker as an example for an application requiring cgroups.

dockerd can successfully be started from within a Void container, at least when skipping the service file's attempt to modprobe anything:

grep -vw modprobe /etc/sv/docker/run | sudo

The daemon is running, but docker run hello-world will report an error:

docker: Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: mountpoint for devices not found: unknown.
ERRO[0000] error waiting for container: context canceled`

The daemon will additonally mention:

mkdir: cannot create directory ‘/sys/fs/cgroup/systemd’: No such file or directory
mount: /sys/fs/cgroup/systemd: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
...
...
copy shim log                                 error="read /proc/self/fd/14: file already closed"

To resolve, /sys/fs/cgroup has to at least be made writeable (docker wants to create the systemd cgroup there) and the devices cgroup has to be mounted:

sudo mount -t tmpfs cgroup /sys/fs/cgroup
sudo mkdir /sys/fs/cgroup/devices
mount -t cgroup -o devices none /sys/fs/cgroup/devices

(At startup, dockerd will still complain about other missing cgroups. Those can be made available too by utilizing the above mkdir & mount, but aren't necessary in this example.)

At this point docker run hello-world should execute successfully.

See #103 for some more thoughts on this situation.

@kevcrumb I notice you chose to use cgroup1 inside the container. What is that decision based on? The fact that the docker service basically assumes cgroup1, or did you try cgroup2 and it caused issues? Could you try again with cgroup2 and a docker service run file with the cgroup handling removed?