Description
If I attach to a container the terminal is still empty until:
I could not find any other issue with that problem.
/kind bug
Steps to reproduce the issue:
podman run --name test -it debian bashpodman attach testDescribe the results you expected:
I would expect that there is an output without modify the screen size or the content.
docker handles this case better.
Output of podman version:
Version: 1.9.1
RemoteAPI Version: 1
Go Version: go1.11.6
OS/Arch: linux/amd64
A friendly reminder that this issue had no activity for 30 days.
@mheon PTAL
I got a message ERRO[0000] normal attach now.
But there is still no content until screen resizing.
I think we must have changed something about how resize is handled that broke this. We used to unconditionally resize the screen, which would trigger terminal prompts to re-display. It looks like this was disabled at some point, though...
Alright, this is not as simple as I assumed. We are actually sending a resize event, but it's not forcing a redraw of the terminal.
Further, I'm seeing that detaching from an attach session is actively killing the container, which is definitely not good.
Also, very confusing: I have no idea where the "normal attach" error message is coming from. That string exists nowhere in Podman or Conmon, nor do I see any obvious string composition of error messages.
Ah, found it - looks like leftover debug from a c/image update from @vrothberg that slipped into the v2.0 branch and nowhere else.
I tested it again. Something else that I found: podman leaves the container with unclean output.
podman run -it debian bash
apt update, apt install htop
htop
press ctrl+p, then ctrl+q
I got my old prompt from the host system. But the output of htop is still hanging around until I override it with some other content.
Ah, think I have it. We need to send a SIGWINCH to the container to force redraw after attach completes.
I came across this bug as well. Is it possible to also print a newline when detaching? Docker prints read escape sequence to stderr which adds a newline, avoiding this: root@d6d95918c007:/# [user@host ~]$.
Can you open a fresh bug about that? But sure, that should be doable.
Most helpful comment
7592 to fix