libct/cg/systemd/v1: do not use c.Path

Commit a1d5398 ("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 commit f57bb2f by 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 <[email protected]>

Author: kolyshkin

libcontainer/cgroups/systemd/v1.go

@@ -267,7 +267,7 @@ func (m *legacyManager) joinCgroups(pid int) error {
 }
 
 func getSubsystemPath(c *configs.Cgroup, subsystem string) (string, error) {
-	mountpoint, err := cgroups.FindCgroupMountpoint(c.Path, subsystem)
+	mountpoint, err := cgroups.FindCgroupMountpoint("", subsystem)
 	if err != nil {
 		return "", err
 	}