mirror of
https://github.com/opencontainers/runc.git
synced 2026-07-11 14:13:58 +08:00
Kir Kolyshkin
c1bba720f7
Commita1d5398afa("Respect container's cgroup path") added a cgroupPath argument to FindCgroupMountpoint to make runc/libcontainer work in a custom multitenant environment with multiple cgroup mount points. It also added passing c.Path as an argument to FindCgroupMountpoint for systemd (v1) controller. This is wrong, because 1. systemd controller do not use c.Path at all (and c.Path is never set by specconv) -- instead, it uses Name and Parent. 2. c.Path, if set, is not absolute -- it is relative to /sys/fs/cgroup -- but it is used as an absolute path here. Since c.Path is never set, the change did not result in any breakage, so this code sit quietly for some time and the issue might not have been discovered -- until we started running libcontainer/integration tests in a CentOS 7 VM, which resulted in a following weird error: > FAIL: TestPidsSystemd: utils_test.go:55: exec_test.go:630: unexpected error: container_linux.go:353: starting container process caused: process_linux.go:326: applying cgroup configuration for process caused: mountpoint for devices not found The error was "fixed" in commitf57bb2fe3dby changing the tests' cgroups Path to be "/sys/fs/cgroup/". This actually resulted in creation of cgroup directories like /sys/fs/cgroup/memory/sys/fs/cgroup, /sys/fs/cgroup/devices/sys/fs/cgroup and so on. The proper fix to the test case is implemented in the previous commit, which sets c.Name and c.Parent. This commit just removes the invalid use of c.Path, and tells the whole story. Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>