"podman system reset" does not return #9075
Assignees
Labels
kind/bug
Categorizes issue or PR as related to a bug.
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
parkinglot
Not actively worked on, but should remain open
Comments
openshift-ci-robot
added
the
kind/bug
|
The SSH connection was lost because I had to close the lid of my laptop for a few hours. Okay, the same thing is happening as last time. The command does not return. I didn't mention it in the last GitHub comment but I saw a high CPU load previously. PID 177919 is the process Check open file handles |
|
Are the systemd units set to attempt to restart on failure? That could very well cause this.
|
|
Yes, I see a few I disabled all systemd user services and rebooted the computer and tested once more This time it worked! |
|
I'm going to go ahead and re-open - we really need to make the |
|
A friendly reminder that this issue had no activity for 30 days. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
@mheon, you seem to have a good idea of what needs to be done. Could you write a brain dump? |
|
Alright. There are two core issues with
As such, what needs to happen: the current method for resetting storage needs to be changed from a method on a Libpod |
|
Thanks a lot for the great summary, @mheon! |
|
A friendly reminder that this issue had no activity for 30 days. |
|
@vrothberg @eriksjolund @mheon What should we do with this issue now? |
|
Still needs to be worked on per my comment above. Might want to get a card written for it? |
|
A friendly reminder that this issue had no activity for 30 days. |
|
@mheon Did you ever produce a card? |
|
A friendly reminder that this issue had no activity for 30 days. |
|
@mheon Ping again. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
@cdoern since you are in this area now, could you look at this? |
|
sure, I can look at this @rhatdan |
|
A friendly reminder that this issue had no activity for 30 days. |
|
@mheon I think it is time you work on this one, since you understand it the best. |
|
Ack, sure. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
On this one now |
mheon
added a commit
to mheon/libpod
that referenced
this issue
Jun 3, 2022
Firstly, reset is now managed by the runtime itself as a part of initialization. This ensures that it can be used even with runtimes that would otherwise fail to be created - most notably, when the user has changed a core path (runroot/root/tmpdir/staticdir). Secondly, we now attempt a best-effort removal even if the store completely fails to be configured. Third, we now hold the alive lock for the entire reset operation. This ensures that no other Podman process can start while we are running a system reset, and removes any possibility of a race where a user tries to create containers or pull images while we are trying to perform a reset. [NO NEW TESTS NEEDED] we do not test reset last I checked. Fixes containers#9075 Signed-off-by: Matthew Heon <[email protected]>
github-actions
bot
added
the
locked - please file new issue/PR
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
podman system resetdoes not return. First there is some output, for instancebut soon nothing more is written to the terminal. At least 60 minutes have now passed since the last output was written to the terminal.
I also have some systemd user services running
podman run .... (Maybe those cause the problem?).This bug report might be a bit of a nightmare as there is no clear description of how to reproduce the bug. Feel free to close it.
Steps to reproduce the issue:
sudo apt-get update && sudo apt-get dist-upgrade -ychanges the podman version over time). Create and enable systemd user services that are using podman.sudo apt-get update && sudo apt-get dist-upgrade -y. (This happened yesterday)podman images --sort size. This command was successfully executed.Describe the results you received:
Nothing more is written to the terminal. At least 60 minutes have now passed since the last output was written to the terminal.
Describe the results you expected:
I would expect the command
podman system resetto return.Additional information you deem important (e.g. issue happens only occasionally):
Some disk space has been freed up
I checked that ~/.local/share/containers now consumes 45 Gb disk space. Before it was 154 Gb.
The network does not seem to be the problem
I'm logged in via
sshso theoretically the network connection could influence what is happening.It doesn't seem to be related to the network, though, as I tested pressing ctrl-z and then typed
fgThere is no special user config
ps axuw | grep podman
ps axuw | grep conmon
systemctl --user list-units
systemctl --user cat 'slurm-*'
Output of
podman version:Nothing, the command
podman versiondoes not returnThe command
sudo podman versiongivesOutput of
podman info --debug:Nothing, the command
podman versiondoes not returnThe command
sudo podman info --debug | grep -v hostname:givesPackage info (e.g. output of
rpm -q podmanorapt list podman):Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
The text was updated successfully, but these errors were encountered: