utils: takes the longest path on cgroup v1

now getCgroupProcess takes the longest path on cgroup v1, instead of
complaining if the paths are different.

This should help when --cgroups=split is used on cgroup v1 and the
process cgroups look like:

$ cat /proc/self/cgroup
11:pids:/user.slice/user-0.slice/session-4.scope
10:blkio:/
9:cpuset:/
8:devices:/user.slice
7:freezer:/
6:memory:/user.slice/user-0.slice/session-4.scope
5:net_cls,net_prio:/
4:hugetlb:/
3:cpu,cpuacct:/
2:perf_event:/

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
(cherry picked from commit 660a06f2f79fc1edf68e286ee452ceb9dcd5e03a)

1 files changed, 2 insertions, 9 deletions

diff --git a/utils/utils_supported.go b/utils/utils_supported.go
index 7a0417c6c..73313cf5e 100644
--- a/utils/utils_supported.go
+++ b/utils/utils_supported.go
@@ -81,16 +81,9 @@ func getCgroupProcess(procFile string) (string, error) {
 			cgroup = line[3:]
 			break
 		}
-		// root cgroup, skip it
-		if parts[2] == "/" {
-			continue
-		}
-		// The process must have the same cgroup path for all controllers
-		// The OCI runtime spec file allow us to specify only one path.
-		if cgroup != "/" && cgroup != parts[2] {
-			return "", errors.Errorf("cgroup configuration not supported, the process is in two different cgroups")
+		if len(parts[2]) > len(cgroup) {
+			cgroup = parts[2]
 		}
-		cgroup = parts[2]
 	}
 	if cgroup == "/" {
 		return "", errors.Errorf("could not find cgroup mount in %q", procFile)