Unable to easily stop an interactive podman container (keyboard)

[ssbarnea]

When running an interactive process like podman run --systemd=always -it fauust/docker-systemd:debian-10 you endup with an app that seems to not be responsive to any standard stop/kill signals.

• Ctrl-C no effect
• Ctr-D no effect
• Ctrl-\ no effect
• Magic key combination that appears to work Ctrl-P Ctrl-Q, but clearly that magic combination is not advertised by the application when it starts.

Ideally Ctrl-D and Ctrl-C should just work but if there is a technical reason why this cannot be fixed we should at least assure that podman does advertise on stderr the magic key combinations needed.

Reproduced on:

• podman version 3.1.2 on macos (remoting)
• poadman version 3.1.2 on fedora 34

Related #4397

[fauust]

Indeed, I can confirm this. Another workaround is to stop/kill the container from another terminal (but this is clearly not very friendly).

Reproduced on:

• podman version 3.0.1 (Debian Bullseye);
• podman version 3.0.0 (Debian Buster).

[rhatdan]

Systemd always changes the Stop character to something only systemd understands, and you can not generate that at the keyboard.

[rhatdan]

man podman run
...
--systemd=true|false|always
...
It will also set the default stop signal to SIGRTMIN+3.

[rhatdan]

The issue is that systemd ignores all of these control chars.

[rhatdan]

@mheon Could we theoretically translate the ^c from the TTY to the stop signal of the container when Podman is attached. But even if we could this might not be what the user expects.

[mheon]

@rhatdan That seems dangerous. What if the user actually wanted to send SIGTERM?

I think this is a unique case, and needs to be treated as one. Systemd only wants to stop if given a very specific and very unusual signal - SIGINT and SIGTERM as you might get with kill/Control-C are not sufficient. I think we have to respect systemd's wishes here.

[ssbarnea]

While I can understand @mheon concerns about changing default behavior, I do not see why we should not improve the user experience and log something like below when running with --systemd=always -it options:

To stop current interactive systemd container press ^P^Q as normal keyboard signals are ignored.

Later we could even add another opt-in (configurable option) that translates a ^C, so users may be able to obtain the behavior they want, without risking affecting the default behavior.

[rhatdan]

What happens when the --systemd flag is enabled, because you are using systemd within the container? We envisioned --systemd=always as mainly a debugging tool.

[ssbarnea]

Is not so much about what am I using and more about what others are using podman with. I maintain ansible molecule testing framework and I cannot prevent people from starting containers with systemd or not. The default is not, but a significant number do try to use system as they want to test deployment of various services.

IMHO, I am yet to see the first user that starts a container in console interactive mode but he does not want to be able to use Ctrl-C to stop it after. What is the purpose of starting a console app the you cannot stop? I think that exposing the tricks needed for stopping such runs could help improve overall user experience.

If you want I can survey few others about expectations and tell the to comment as I do not want to impose my view of what the cli should do or not. After digging these days I am sure I will not forget about the ^P^Q trick any time soon.

[rhatdan]

There are lots of tools that ignore ^c, so this is not that unusual.

[rhatdan]

$ podman run --systemd=always alpine sleep 100
^C
$

So if I run an application that does not ignore ctrl^c. then it works. If I launch Bash, it the ^c is passed to processes within the shell. We don't kill the session.