Support handling SIGINT when running any "up" command

[criess]

It should be trapped the same way docker-compose does:

When up command was invoked and podman-compose process receives SIGINT (e.g. from keyboard by Ctrl+C'ing) it should trap this signal and bring all containers down in a controlled manner and then end itself as decribed here:

• https://github.com/docker/compose/blob/v2/docs/reference/compose_up.md

I am open for discussion, whether this makes sense or not but it can be considered a usability feature for developers using the shell builtin keyboard shortcuts (or any other means) to send signals to a process (the Ctrl+C'ing is my usecase basically)

[ztane]

it is most annoying when pressing ctrl+c that I've got a container that is still spamming to the terminal

[universam1]

Is there any workaround possible?
Especially when compose is used for test setups, being unable to shut it down is a show stopper

[typekpb]

@universam1 workaround? Sure. Just run: podman-compose down

[yogo1212]

This would also be incredibly useful for systemd units.
The commonly used method to start {podman,docker}-compose systemd is with oneshot and RemainAfterExit (and -d in ExecStart).
When the service is launched that way, systemd won't know when and how it terminates.
I could even stop or bring down the container myself and systemd would still think it's running.
Because of that, it is currently difficult to make sure a service is up.

I'm struggling every time to make these systemd units resilient because Type=simple and ExecStop don't appear to go along well.

With podman handling SIGTERM/SIGINT, it would be possible to use Type=simple directly (without having to do anything extra).
Maybe an additional parameter --down-on-exit prevents it from interfering with existing setups.

Just to illustrate what it could look like:

Type=simple
ExecStart=/usr/bin/podman-compose up --down-on-exit --remove-orphans
Restart=always
RestartSec=10

[akhiljalagam]

The current behavior of podman-compose up appears to be similar to podman-compose logs -f, as it does not handle container shutdown.

A temporary solution is, create run-podman-compose.sh

#!/bin/bash

# Function to clean up containers on Ctrl+C
cleanup() {
    echo "Cleaning up containers..."
    podman-compose down
}

# Trap Ctrl+C and call the cleanup function
trap cleanup SIGINT

# Run podman-compose in the foreground
podman-compose up

and use run-podman-compose.sh instead of podman-compose up

[mschwager]

As someone moving from Docker + Docker Compose -> Podman + Podman Compose, this really caught me off guard. IMO this is a small UX feature that should really be replicated from Docker Compose. I'm not sure how representative my workflow is, but it's a constant stream of docker compose up -> Ctrl+C -> docker compose up -> Ctrl+C -> ...

[mschwager]

Upon closer inspection, it looks like perhaps SIGINT is expected to work:

podman-compose/podman_compose.py

Lines 2283 to 2303 in d704622

	tasks = set()
	loop = asyncio.get_event_loop()
	loop.add_signal_handler(signal.SIGINT, lambda: [t.cancel("User exit") for t in tasks])
	for i, cnt in enumerate(compose.containers):
	# Add colored service prefix to output by piping output through sed
	color_idx = i % len(compose.console_colors)
	color = compose.console_colors[color_idx]
	space_suffix = " " * (max_service_length - len(cnt["_service"]) + 1)
	log_formatter = "{}[{}]{}|\x1b[0m".format(color, cnt["_service"], space_suffix)
	if cnt["_service"] in excluded:
	log.debug("** skipping: %s", cnt["name"])
	continue
	tasks.add(
	asyncio.create_task(
	compose.podman.run([], "start", ["-a", cnt["name"]], log_formatter=log_formatter),
	name=cnt["_service"],
	)
	)

Is there some weird interaction with the scoping of tasks here? In other words, when the lambda is created, tasks is empty. It is then populated, and SIGINT is likely (but not always) handled after the containers are started.

[mschwager]

It appears the SIGINT handling code hasn't been released yet. It was committed in Feb 2024: 38b13a3. Looks like the current Podman Compose version is 1.0.6, and the start of version 1.0.7 was committed in Apr 2023: 7f5ce26.

Looks like this project may be lacking support: #825.

[frbrno]

simple workaround for me to stop running containers on crtl+c
podman-compose up && podman-compose down

[mokibit]

Support for handling SIGINT was implemented by #1148.

Copying the reproduction trial #112 (comment) for convenience:

1. Versions:

podman-compose version 1.5.0
podman version 5.4.2

2. compose.yml File (keeps services running indefinitely):

services:
  test1:
    image: busybox
    command: tail -F test
  test2:
    image: busybox
    command: tail -F test

Commands executed:
podman-compose up (running up in the foreground)
CTRL+C

Partial output of CTRL+C command:

<...>
^CCaught SIGINT or Ctrl+C, shutting down...
Shutting down gracefully, please wait...
podman stop -t 10 podman-compose_test2_1
podman stop -t 10 podman-compose_test1_1
WARN[0010] StopSignal SIGTERM failed to stop container podman-compose_test1_1 in 10 seconds, resorting to SIGKILL 
exit code: 137
WARN[0010] StopSignal SIGTERM failed to stop container podman-compose_test2_1 in 10 seconds, resorting to SIGKILL 
exit code: 137
Sending termination signal
podman-compose_test1_1
exit code: 1
podman-compose_test2_1
exit code: 1

podman ps -a shows that all running containers have exited.
It is evident that podman-compose now works like docker-compose and forcefully stops all running containers when CTRL+C is pressed.

Please update podman-compose to its latest version, and it should work as expected.
If you encounter any other similar issues, please open a new bug report.

@p12tic this issue can be closed.

[p12tic]

Thanks, closing.