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