pressing CTRL+C shows confusing stack trace

[nitram509]

Describe the bug

I'm using podman-compose to run Zeebe locally (not relevant I guess, but full transparency here). See https://github.com/camunda-cloud/camunda-cloud-get-started/blob/master/docker-compose.yaml

Besides the known issues with mounting volumes on my MacOSX v10.15.7, I managed to make it run. To complete my work and shut down the container, I did pressed CTRL+C (as I'm used to from prior Docker Compose), and a large stack trace was plotted in my terminal.

From my other Python work, I guess this is Python's default behavior, and can safely be ignored. But from a tool like podman-compose I expect no such stack traces, since this is not exceptional behavior and rather a regular usage, yes?

To Reproduce Steps to reproduce the behavior:

1. start some docker-compose.yml
2. press CTRL+C

Expected behavior a simple and clean exit, no stack trace

Actual behavior I see a stack trace from python indicating an issue:

[....]
^CTraceback (most recent call last):
exit code: -2
  File "/Users/user/.pyenv/versions/3.8.12/bin/podman-compose", line 8, in <module>
    sys.exit(main())
  File "/Users/user/.pyenv/versions/3.8.12/lib/python3.8/site-packages/podman_compose.py", line 1775, in main
    podman_compose.run()
  File "/Users/user/.pyenv/versions/3.8.12/lib/python3.8/site-packages/podman_compose.py", line 1024, in run
    cmd(self, args)
  File "/Users/user/.pyenv/versions/3.8.12/lib/python3.8/site-packages/podman_compose.py", line 1248, in wrapped
    return func(*args, **kw)
  File "/Users/user/.pyenv/versions/3.8.12/lib/python3.8/site-packages/podman_compose.py", line 1442, in compose_up
    thread.join(timeout=1.0)
  File "/Users/user/.pyenv/versions/3.8.12/lib/python3.8/threading.py", line 1015, in join
    self._wait_for_tstate_lock(timeout=max(timeout, 0))
  File "/Users/user/.pyenv/versions/3.8.12/lib/python3.8/threading.py", line 1027, in _wait_for_tstate_lock
    elif lock.acquire(block, timeout):
KeyboardInterrupt

Output

$ podman-compose version
['podman', '--version', '']
using podman version: 3.4.4
podman-composer version  1.0.3
podman --version 
podman version 3.4.4
exit code: 0

^^^^ why is there "exit code: 0" written? It's not from my shell, AFAIK. 🤷

Environment:

• OS: Mac Cataline 10.15.7
• podman version: see above
• podman compose version: see above (used pip to install official release)

[muayyad-alsadi]

We had to log too much things because this project was in early stages and they help us debug

The project is now stable and we should make it default to non verbose and show traces only when --verbose is passed

[mrexodia]

Additionally podman-compose has different behavior from docker-compose here. It terminates with a KeyError, but it keeps the containers running. docker-compose down gracefully stops down the containers before actually closing.

[sambonbonne]

I confirm the above problem: when I hit Ctrl-C, I expect podman-compose will stop containers before leaving but apparently it's just terminating. So when I run podman-compose up again, it stays blocked at podman start -a XXX because the preceding container is still running.

[worldofgeese]

Does podman-compose up not have a graceful method of shutting down outside of running podman-compose down in a new terminal window?