You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The fact that we initialize the store twice in rootless execution mode presumably leads into locking issues with the containers/storage implementation.
For example this works fine in parallel:
> sudo podman push ...
# takes some time
> sudo podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
Listing the running containers in parallel to a push works fine in root mode.
I'm currently playing around with containers/storage locking enhancements (containers/storage#473, containers/storage#420), where it is not possible for me to bring the enhancement into rootless podman without solving that issue first.
I don't see anything there that actually needs a store. We have the ability to make a libpod runtime without a store via WithNoStore() - if we can use that for the initial rootless GetRuntime() invocation, we can avoid the storage locks entirely.
This fixes a double-locking issue of the container storage when running
rootless podman.
Closescontainers#4591
Signed-off-by: Sascha Grunert <[email protected]>
The fact that we initialize the store twice in rootless execution mode presumably leads into locking issues with the containers/storage implementation.
For example this works fine in parallel:
Listing the running containers in parallel to a push works fine in root mode.
Now in rootless mode:
If we put a
debug.PrintStack()
here:https://github.com/containers/libpod/blob/aa95726c98385fb75bc70b6de7a86c09ed74abd5/libpod/runtime.go#L732-L736
then we see that we have two stack traces when doing the push:
I'm currently playing around with containers/storage locking enhancements (containers/storage#473, containers/storage#420), where it is not possible for me to bring the enhancement into rootless podman without solving that issue first.
Maybe we should retrieve the store not during runtime initialization, but later right before the command execution... 🤔 Might also be that the issue is somewhere in this logic:
https://github.com/containers/libpod/blob/aa95726c98385fb75bc70b6de7a86c09ed74abd5/libpod/runtime.go#L286-L306
The text was updated successfully, but these errors were encountered: