Is systemd namespace necessary in bin/setup-cgroups?

[glorpen]

Snippet from bin/setup-cgroups :

if ! test -e /sys/fs/cgroup/systemd ; then
  mkdir /sys/fs/cgroup/systemd
  mount -t cgroup -o none,name=systemd none /sys/fs/cgroup/systemd
fi

It kind of assumes that on host system there is SystemD, in my case it is not true. So upon first task run everything works, but then new cgroup is created and any attempt to start containers on host ends with docker: Error response from daemon: cgroups: cannot find cgroup mount destination: unknown., as there is now new cgroup namespace and docker wants it all mounted.

Not sure if this namespace is required by something, but if not snippet removal then maybe env flag to skip it would be good solution.

[vito]

Hmm, the lineage of this can be traced to https://github.com/concourse/docker-image-resource/commit/264b3718b5b85d850c208159fe2dd364620a83d1 with some further context in https://github.com/concourse/docker-image-resource/pull/177

Ideally there'd be some way to detect whether it needs to be done. Do you happen to have a way for me to reproduce this so I can play around? Maybe a particular VM or Linux distribution?

[glorpen]

I'm using Gentoo - there is openrc by default. From what I've tried - after the fact you can check /proc/self/cgroup for systemd entry existence. Also, after my superficial research, I think that init entry could be always on position "1", so maybe it is as simple as 1:name=systemd:... vs 1:name=openrc:....

$ cat /proc/self/cgroup
14:name=systemd:/
13:pids:/
12:hugetlb:/
(...)
1:name=openrc:/
0::/

[muntac]

@vito fyi this issue can now be closed as https://github.com/concourse/docker-image-resource/pull/314 added a fix.

[vito]

will need to repeat the same fix here in bin/setup-cgroups, but cool!