Cgroup problem with Docker CE and Ubuntu

I’m having what appear to be a configuration issue when using Docker for Mac CE (Version 17.12.0-ce-mac55 (23011)) with Ubuntu Xenial (the ubuntu:xenial image) on High Sierra. I’m not sure if it has anything specific to do with Docker for Mac but I figured I’d start here since that is the version I am using.

The problem occurs when trying to run the benchexec software (https://github.com/sosy-lab/benchexec) in a Docker container created from the Xenial image. As per the benchexec documentation (INSTALL.md) we are using a run command like the following to set up cgroups.

docker run -v /sys/fs/cgroup:/sys/fs/cgroup:rw ...

This used to work with a non-CE version of Docker (don’t have the version to hand since I don’t have it installed any more). Unfortunately, with Docker CE when I run benchexec’s cgroup check it complains:

python3 -m benchexec.check_cgroups
WARNING: Cannot use cgroup hierarchy mounted at /sys/fs/cgroup/cpuacct/docker-ce/docker/a1463c9146baf2d7d1892eb2b659ad35acfdc8416ed7a755be3449944ee0687b for subsystem cpuacct, reason: No such file or directory. If permissions are wrong, please run "sudo chmod o+wt '/sys/fs/cgroup/cpuacct/docker-ce/docker/a1463c9146baf2d7d1892eb2b659ad35acfdc8416ed7a755be3449944ee0687b'".
WARNING: Without cpuacct cgroups, cputime measurement and limit might not work correctly if subprocesses are started.
WARNING: Cannot use cgroup hierarchy mounted at /sys/fs/cgroup/freezer/docker-ce/docker/
Summary

a1463c9146baf2d7d1892eb2b659ad35acfdc8416ed7a755be3449944ee0687b

for subsystem freezer, reason: No such file or directory. If permissions are wrong, please run “sudo chmod o+wt ‘/sys/fs/cgroup/freezer/docker-ce/docker/a1463c9146baf2d7d1892eb2b659ad35acfdc8416ed7a755be3449944ee0687b’”.
WARNING: Cannot reliably kill sub-processes without freezer cgroup.
WARNING: Cannot use cgroup hierarchy mounted at /sys/fs/cgroup/memory/docker-ce/docker/a1463c9146baf2d7d1892eb2b659ad35acfdc8416ed7a755be3449944ee0687b for subsystem memory, reason: No such file or directory. If permissions are wrong, please run “sudo chmod o+wt ‘/sys/fs/cgroup/memory/docker-ce/docker/a1463c9146baf2d7d1892eb2b659ad35acfdc8416ed7a755be3449944ee0687b’”.
WARNING: Cannot measure memory consumption without memory cgroup.
WARNING: Cannot use cgroup hierarchy mounted at /sys/fs/cgroup/cpuset/docker-ce/docker/a1463c9146baf2d7d1892eb2b659ad35acfdc8416ed7a755be3449944ee0687b for subsystem cpuset, reason: No such file or directory. If permissions are wrong, please run “sudo chmod o+wt ‘/sys/fs/cgroup/cpuset/docker-ce/docker/a1463c9146baf2d7d1892eb2b659ad35acfdc8416ed7a755be3449944ee0687b’”.

An issue has been created on the benchexec github (https://github.com/sosy-lab/benchexec/issues/289) with more information and some discussion of possible solutions, but since my expertise with both benchexec and Docker is very limited, I haven’t been able to work out a way to fix this problem.

Essentially the problem seems to be that /proc/self/cgroup refers to paths like this:

1:cpuset:/docker-ce/docker/4b594f13acb2c123e3c8edf34f96ec62db02f7f57812af2b376fb56c258709bd

but benchexec fails when trying to open these, since the /sys/fs/cgroup file system doesn’t contain any docker-ce directories. Note docker not docker-ce/docker in the following, for example:

# ls /sys/fs/cgroup/cpuset
cgroup.clone_children  cpuset.cpus            cpuset.mem_exclusive   cpuset.memory_pressure     cpuset.mems                      docker
cgroup.procs           cpuset.effective_cpus  cpuset.mem_hardwall    cpuset.memory_spread_page  cpuset.sched_load_balance        notify_on_release
cpuset.cpu_exclusive   cpuset.effective_mems  cpuset.memory_migrate  cpuset.memory_spread_slab  cpuset.sched_relax_domain_level  tasks

I’ve been told that this may be related to cgroup namespaces but I’m not sure how to turn them on or off as needed, if indeed that is the problem.

Can anyone suggest how to resolve this?

It seems that something has been fixed in Docker since the latest Mac version (Version 18.03.0-ce-mac60 (23751)) doesn’t have the problem. Hopefully this situation remains…