-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
fix container cgroup lookup #8422
Conversation
When running on cgroups v1, `/proc/{PID}/cgroup` has multiple entries, each pointing potentially to a different cgroup. Some may be empty, some may point to parents. The one we really need is the libpod-specific one, which always is the longest path. So instead of looking at the first entry, look at all and select the longest one. Fixes: containers#8397 Signed-off-by: Valentin Rothberg <[email protected]>
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, vrothberg 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 |
// path which works both on v1 and v2. | ||
// Read /proc/[PID]/cgroup and find the *longest* cgroup entry. That's | ||
// needed to account for hacks in cgroups v1, where each line in the | ||
// file could potentially point to a cgroup. The longest one, however, |
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.
This seems pretty arbitrary, but if it fixes our Flake,
LGTM
/lgtm |
When running on cgroups v1,
/proc/{PID}/cgroup
has multiple entries,each pointing potentially to a different cgroup. Some may be empty,
some may point to parents.
The one we really need is the libpod-specific one, which always is the
longest path. So instead of looking at the first entry, look at all and
select the longest one.
Fixes: #8397
Signed-off-by: Valentin Rothberg [email protected]