-
Notifications
You must be signed in to change notification settings - Fork 2.2k
cgroup2: exec: join the cgroup of the init process on EBUSY #2416
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
cgroup2: exec: join the cgroup of the init process on EBUSY #2416
Conversation
e93631c to
dc133ec
Compare
4ece281 to
9643a87
Compare
|
@kolyshkin @cyphar @giuseppe PTAL |
| // On cgroup v2 + nesting + domain controllers, EnterPid may fail with EBUSY. | ||
| // https://github.com/opencontainers/runc/issues/2356#issuecomment-621277643 | ||
| // Try to join the cgroup of InitProcessPid. | ||
| if cgroups.IsCgroup2UnifiedMode() { |
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.
should it not be done only with err == EBUSY?
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.
I guess it is worth trying to join pid1 even on other errors
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.
@AkihiroSuda this decision (try to join pid1 on every error) can be problematic.
I've seen case (in #4812 (comment)) in which the container init is moved to an entirely different cgroup (I'm not sure by whom, but suspect it's some GHA CI infra software). Once this happens, the container's limits, as configured in OCI spec, are no longer applied. Next, we call runc exec and it succeeds (thanks to the patch in this PR), but I'd rather have it failed, because something very bad has happened.
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.
I also somewhat question this idea in the first place -- administrative cgroup moves are generally not blocked by the cgroup infrastructure (this is an explicit design goal). I think you would only get this case with frozen cgroups, in which case an error is kind of reasonable IMHO?
|
@kolyshkin @mrunalp PTAL |
|
Added one comment about removing the warning otherwise looks ready to merge. Thanks! |
9643a87 to
5099176
Compare
|
updated |
|
Thanks, will tag once tests pass again. |
|
@kolyshkin @cyphar ptal |
5099176 to
b502a4b
Compare
mrunalp
left a comment
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
kolyshkin
left a comment
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.
a nit with whitespace, but LGTM overall
Signed-off-by: Akihiro Suda <[email protected]>
b502a4b to
c91fe9a
Compare
|
fixed |
kolyshkin
left a comment
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
mrunalp
left a comment
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
Fix #2356.
Contains #2418Note: this behavior is different from crun v0.13.
crun joins "crun-exec` group rather than the init group: containers/crun@af1080b
The next version of crun will switch to the init cgroup: containers/crun#365