Judgehost container fail to start because of cgroups

[epitavy]

Description of the problem

I used to run judgehost with the provided docker container but after some update of my OS, judgehost no longer run because of errors with cgroups.

mkdir: cannot create directory '/sys/fs/cgroup/cpuset': Read-only file system
mount: /sys/fs/cgroup/cpuset/: mount point does not exist.
Error: Can not mount cpuset cgroup. Probably cgroup support is missing from running kernel. Unable to continue.

I can remove the mkdir and mount error by setting the volume in read/write instead of read/only but I still have an error saying that cgroup support is missing.
However, cgroup is enabled in grub.

Your environment

judgehost:7.3.2
Archlinux with Linux 5.13.10-arch1-1

Steps to reproduce

I run the judgehost with the following docker-compose.yml:

...
judgehost:
   restart: unless-stopped
   image: domjudge/judgehost:7.3.2
   privileged: true
   volumes:
     - /sys/fs/cgroup:/sys/fs/cgroup:ro
   environment:
     DAEMON_ID: 0
     DOMSERVER_BASEURL: "http://app/"
     JUDGEDAEMON_PASSWORD: "c0pl1c4ted_password"
   depends_on:
     - app
...

As the judgehost is complaining that /sys/fs/cgroup/cpuset is read only, I set the volume to rw and got the following error:
Error: cgroup support missing memory features in running kernel. Unable to continue.

Expected behaviour

Normal startup of the judgehost container

Actual behaviour

Container cannot start

The problem probably comes from me and not from the container as I successfully run it few months ago. I wonder if the issue is with the privileged option.

Output of some command

$ cat /proc/cmdline
$ BOOT_IMAGE=/vmlinuz-linux root=UUID=8be6c898-1f2c-40bc-84be-9a2e217ad264 rw loglevel=3 cgroup_enable=memory swapaccount=1

$ sudo systemctl enable create-cgroups --now                                                                                  
$ Failed to enable unit: Unit file create-cgroups.service does not exist.

[vmcj]

You might need to check which cgroup you have as there is an issue with CgroupV2, which I think is the default for Arch currently.
#1072

[epitavy]

You might need to check which cgroup you have as there is an issue with CgroupV2, which I think is the default for Arch currently.
#1072

You was absolutely right, after enabling cgroupV1, the container start proprely