-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
podman-remote run -it: failed to resize TTY: container in wrong state "stopped|created" #9831
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.
remote
Problem is in podman-remote
Comments
edsantiago
added
kind/bug
Categorizes issue or PR as related to a bug.
remote
Problem is in podman-remote
labels
Mar 26, 2021
Forgot to mention: there's a simple workaround, just add a $ ./bin/podman-remote run --rm -it quay.io/libpod/alpine sh -c 'sleep 0.3;echo hello'
hello 0.2 is not quite good enough, and 0.1 is even less good. |
For reference: flake failure in CI |
rhatdan
added a commit
to rhatdan/podman
that referenced
this issue
Mar 26, 2021
Since podman-remote resize requests can come in at random times, this generates a real potential for race conditions. We should only be attempting to resize TTY on running containers, but the containers can go from running to stopped at any time, and returning an error to the caller is just causing noice. This change will basically ignore requests to resize terminals if the container is not running and return the caller to success. All other callers will still return failure. Fixes: containers#9831 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
mheon
pushed a commit
to mheon/libpod
that referenced
this issue
Mar 29, 2021
Since podman-remote resize requests can come in at random times, this generates a real potential for race conditions. We should only be attempting to resize TTY on running containers, but the containers can go from running to stopped at any time, and returning an error to the caller is just causing noice. This change will basically ignore requests to resize terminals if the container is not running and return the caller to success. All other callers will still return failure. Fixes: containers#9831 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com> <MH: Fixed cherry-pick conflicts> Signed-off-by: Matthew Heon <mheon@redhat.com>
jmguzik
pushed a commit
to jmguzik/podman
that referenced
this issue
Apr 26, 2021
Since podman-remote resize requests can come in at random times, this generates a real potential for race conditions. We should only be attempting to resize TTY on running containers, but the containers can go from running to stopped at any time, and returning an error to the caller is just causing noice. This change will basically ignore requests to resize terminals if the container is not running and return the caller to success. All other callers will still return failure. Fixes: containers#9831 Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
github-actions
bot
added
the
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
label
Sep 22, 2023
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
remote
Problem is in podman-remote
In window 1:
$ ./bin/podman system service --timeout=0
In window 2:
The errors are not deterministic. Sometimes the state is "created" instead of "stopped". Sometimes the second message is an error instead of warning:
(Even though it says ERROR, exit code is always 0).
Sometimes there's no second line at all, only the first.
master @ 9e23e0b
The text was updated successfully, but these errors were encountered: