crun: setrlimit RLIMIT_NPROC: Operation not permitted: OCI permission denied (was: toolbox not working with existing containers after upgrade to 38.20230422.1) #460
Comments
|
Hm I can't reproduce in either of my Silverblue 37 and 38 VMs fwiw. |
|
Interesting. Perhaps a problem with my machine. |
|
I tried to start the container with podman directly and got the following error message: "Error: unable to start container 8a48d59ee3223c8240d7a6dfd14e3af0cd4506ef394968cbf8307f40fe6c936a: crun: setrlimit tom@fedora38-sb:~$ podman inspect --format '{{ printf "%+v" .HostConfig.Ulimits }}' 8a48d59ee322 ulimit -u yields in the working deployment 30726 and 30725 in the not working one. The described solution to set nproc for my user to 30726 worked: I can now start the container in both deployments. Has anyone an idea how and why the limit changed for my user from 38.20230421.0 to 38.20230422.1? |
|
Have you tried containers/podman#6389 (comment) ? |
|
Yes, creating a backup and restore it works also. The new container gets the new limits of my user account (30725). |
travier
added
f38
|
Same issue here. But with distrobox. Backup/restore did not work as in the comments above (looks like I need to do something different for distrobox). Shredded the container and re-created it. |
|
I've had this happen twice, both distrobox and toolbox have same problems, hope this helps to find the issue I've gone from silverblue Now it broke again after i've upgraded to The command from before, the limit is not as low as i thought it would be Full rpm-ostree status |
|
I may have found a solution without having to recreate the containers, if someone else could confirm if this works for them too I have booted back into kinoite For some reason hard limit for |
|
Got the same on fedora silverblue 38 and a toolbox from a fedora 38 image. I didn't have any extra time to debug but would be happy to supply more info |
|
@rgolangh could you check if ulimits changed you between updates? |
|
Upstream issue: containers/podman#18714 |
|
Upstream fix got merged containers/podman#18714 |
|
Thanks a lot @Cydox ! |
travier
changed the title
|
I overrode podman to 4.6.0-1.fc38 - all my (old) fedora toolbox containers seemed to have survived... |
|
@juhp What matters is the podman version that the container was created with. If your f39 distrobox was created with a podman version without the fix, it will still break if the |
|
Thanks @Cydox for clarifying, much appreciated - was afraid that might be the case. |
|
I also am having the same problem on ublue + distrobox. None of my containers would start, followed by the same errors. I used @sandorex's Changing my /etc/security/limits.conf nproc to 127404 fixed it for me. |
|
Duplicate of containers/toolbox#1312 |
|
This makes it work differently, it leads to this: |
|
This is another issue. Please file another issue here or upstream toolbox for investigation and tracking. |
|
This is fixed for new containers with podman 4.6 which landed in F37+. The workarounds for existing containers are in the first comment at the top. Closing. |
|
Problem returned with last version, same messsage. Have to recreate all pods to fix after kernel install |
|
Please file a new issue referencing this one |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Workarounds
The issue is fixed in podman 4.6 but containers created before this release can not be fixed without being re-created or raising the
nproclimit.Save and restore containers
You can export and import your existing containers. See for example:
RLIMIT_NPROC: Operation not permitted: OCI permission denied containers/toolbox#1312 (comment)Set a higher ulimit for your user
Write the following file, replacing
usernameby your user and150000by a value larger thanulimut -u:Reboot to apply the configuration change.
Original issue text
Describe the bug
After upgrading to 38.20230422.1 I can no longer enter existing containers
When I roll back to version 38.20230421.0 toolbox works as expected.
Newly created containers in 38.20230422.1 work fine, only existing containers are not working
To Reproduce
Please describe the steps needed to reproduce the bug:
Expected behavior
"toolbox enter test" brings me into the container
OS version:
The text was updated successfully, but these errors were encountered: