Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trying to run docker in a systemd container faces cgroup path error #79

Open
jshachm opened this issue Oct 10, 2017 · 5 comments
Open

Comments

@jshachm
Copy link

jshachm commented Oct 10, 2017

When trying to run docker in a systemd container with oci-systemd-hook, things go wrong with cgroup path.
# docker run -ti busybox docker: Error response from daemon: oci runtime error: container_linux.go:247: starting container process caused "process_linux.go:393: container init caused \"rootfs_linux.go:57: mounting \\\"cgroup\\\" to rootfs \\\"/var/lib/docker/devicemapper/mnt/e83e8ed9017e5dfe76d9bc6473d6d630902bde19a5cdecebb4cc26025381673d/rootfs\\\" at \\\"/sys/fs/cgroup\\\" caused \\\"stat /sys/fs/cgroup/44a49d3dbe07bc2e36acafd22e025c10d670d67718ecba0fc7df7aa611e6971a: no such file or directory\\\"\"".

But if we don't do the mount cgroup during the hook, docker will run pretty good.

So I want to ask @rhatdan , why should we mount cgroup into container when start a systemd container?

@rhatdan
Copy link
Member

rhatdan commented Oct 10, 2017

@jshachm Is this on Fedora 27?

@jshachm
Copy link
Author

jshachm commented Oct 10, 2017

No . It's on CentOS 7.3. The problem lies on the codes which mount cgroup into container in oci-systemd-hook. So I get confused with the purpose to mount cgroup into container without umount cgroup which mounted by docker daemon. This will cause a wrong cgroup path when running docker in a systemd container .So can you explain the purpose to mount cgroup twice into a systemd container. Plz! @rhatdan

@rhatdan
Copy link
Member

rhatdan commented Oct 10, 2017

systemd needs to be able to write to /sys/fs/cgroup/systemd in order to launch processes inside of the container.

@jshachm
Copy link
Author

jshachm commented Dec 15, 2017

@rhatdan Long time after we discussed this problem... We need to remount cgroup because we need the rw of cgroupfs. However,why shouldn't we just remount the container's own cgroup path into the container?
If we mount the host cgroup tree into the container, we can have the whole view of the host cgroup sub path in the contianier even it's readonly.
Is there any other side I didn't find? What's the purpose of mount whole cgroup path into the container?
It confuses me a lot....

@hqhq
Copy link

hqhq commented Dec 20, 2017

If we mount the host cgroup tree into the container, we can have the whole view of the host cgroup sub path in the contianier even it's readonly.

I encountered this issue as well, it would be considered as a security issue. @rhatdan @mrunalp

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants