-
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 ulimit issue #18721
fix ulimit issue #18721
Conversation
Looks like the test is "failing successfully" |
63f2459
to
b282074
Compare
For 2. ( Is there a simple way to get the VM image used in the CI to test locally? The script in |
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.
@giuseppe PTAL
@@ -135,38 +133,6 @@ func (s *SpecGenerator) Validate() error { | |||
// default: | |||
// return errors.New("unrecognized option for cgroups; supported are 'default', 'disabled', 'no-conmon'") | |||
// } | |||
invalidUlimitFormatError := errors.New("invalid default ulimit definition must be form of type=soft:hard") | |||
// set ulimits if not rootless | |||
if len(s.ContainerResourceConfig.Rlimits) < 1 && !rootless.IsRootless() { |
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.
Why did you remove this? This sets the limit based on containers.conf defaults so we need to keep it. Although doing this in Validate() looks wrong.
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'm under the impression that it's already set by
podman/pkg/specgenutil/specgen.go
Line 771 in 77bd041
s.Rlimits, err = GenRlimits(c.Ulimit) |
Doing a quick test it looks like a ulimit from containers.conf still makes it into a container, so this was redundant. However it's in there twice right now. So I think the containers.conf defaults also make it to:
rlimits, err := specgenutil.GenRlimits(rtc.Ulimits()) |
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.
The issue with the limits being in the list twice is fixed.
// If not explicitly overridden by the user, default number of open | ||
// files and number of processes to the maximum they can be set to | ||
// (without overriding a sysctl) | ||
if !nofileSet { |
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 am pretty sure we actually want this. The problem is that we only set it once on create instead of for each start.
So I think this must be moved into func (c *Container) generateSpec()
instead
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.
Is there a problem with leaving the ulimits in the spec file empty? The container process should inherit the limits, right?
Is that generateSpec invoked on each run and the spec passed to crun, or is it also saved on disk for the next time the container is started?
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.
Ok, so func (c *Container) generateSpec()
from container_internal_common.go gets executed each time the container is started if it's in ContainerStateConfigured
or ContainerStateExited
. I'll put setting the max ulimits in there and see if that fixes the CI issues for rootless.
I'll also disable the new test for rootfull, as this issue is not really applicable to rootfull.
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.
Looks like this approach works on my end.
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.
Incorporated into latest version of this PR
Yes, the goal is to have a VM that matches the CI environment to 100%. It is only intended for us (RedHat maintainers) as it requires special GCE permission, however I can create a VM for you and add your public ssh key if you really need access. |
0df1936
to
ba4776c
Compare
2d52c4b
to
16a9720
Compare
Alright, ulimits are now set to the maximum possible value (if not overriden) in the Also added a test under Assuming all tests pass, this PR is ready from my perspective (except for the matching in the system test). |
Signed-off-by: Jan Hendrik Farr <[email protected]>
/retest Only changed the assert in the new system test. Unrelated stuff failed. Looks like a flake to me. |
@Cydox: Cannot trigger testing until a trusted user reviews the PR and leaves an In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
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
@giuseppe @umohnani8 PTAL
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Cydox, Luap99 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 |
/lgtm |
Fixes #18714
Does this PR introduce a user-facing change?
This touches a lot of code I'm not familiar with, so I'm playing it slow. Starting by adding tests that are supposed to fail on current main.