-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
systemd-cgroup uses incorrect subsystem path in recent systemd versions #931
Comments
I'm fairly sure this is related to some of the discussion we had in #895. Essentially we aren't treating subsystem paths separately when creating the implicit |
cc @derekwaynecarr I believe RHEL uses the systemd driver.. Do you guys somehow avoid encountering this issue? Do you have a patch floating around somewhere (I didn't see it glancing through the list of docker patches Redhat carries, but worth asking), or is it on an older systemd version / one without pid 1 in init.scope? |
@mrunalp was going to look at this. systemd on fedora 24 is the first On Thursday, June 30, 2016, Euan Kemp notifications@github.com wrote:
|
@euank The approach of using dbus to query the root slice sounds good to me. |
This issue was discussed in a comment a while ago: moby/moby#16256 (comment)
Now that systemd 226+ is more common, this issue has further ramifications.
Under systemd versions of at least 226,
systemd
is underinit.scope
. The code here behaves incorrectly in this configuration.The following is an example of what goes wrong in this configuration:
Essentially, the problem is as described in the above comment: runc thinks some cgroup subsystems should be under
init.scope
under the mistaken assumption that the cgroup of pid 1 is always the root of the cgroup tree. In reality, everything should just be under the real root,/
.I've begun putting together a patch (currently WIP), but wanted an issue to point at.
This impacts projects, such as cadvisor, which read container's cgroups.
cc @vishh @marineam
The text was updated successfully, but these errors were encountered: