-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Ensure correct propagation for cgroupsv1 systemd cgroup #7281
Ensure correct propagation for cgroupsv1 systemd cgroup #7281
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
May need a rebase to fetch the CI fixes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: giuseppe, mheon The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
On cgroups v1 systems, we need to mount /sys/fs/cgroup/systemd into the container. We were doing this with no explicit mount propagation tag, which means that, under some circumstances, the shared mount propagation could be chosen - which, combined with the fact that we need a mount to mask /sys/fs/cgroup/systemd/release_agent in the container, means we would leak a never-ending set of mounts under /sys/fs/cgroup/systemd/ on container restart. Fortunately, the fix is very simple - hardcode mount propagation to something that won't leak. Signed-off-by: Matthew Heon <[email protected]>
bece257
to
a064cfc
Compare
Rebased |
/lgtm |
/hold cancel |
On cgroups v1 systems, we need to mount /sys/fs/cgroup/systemd into the container. We were doing this with no explicit mount propagation tag, which means that, under some circumstances, the shared mount propagation could be chosen - which, combined with the fact that we need a mount to mask /sys/fs/cgroup/systemd/release_agent in the container, means we would leak a never-ending set of mounts under /sys/fs/cgroup/systemd/ on container restart.
Fortunately, the fix is very simple - hardcode mount propagation to something that won't leak.