Detached mode executes entrypoint twice

[Fedma123]

Describe the bug
podman-compose up -d executes the container entrypoint twice.

To Reproduce
Dockerfile

FROM docker.io/debian:bookworm

COPY ./init.sh /root/

compose.yaml

services:
  test:
    image: test-image:latest
    container_name: test
    build:
      context: .
      dockerfile: Dockerfile
    entrypoint: ["/bin/bash", "/root/init.sh"]

init.sh

#!/bin/bash
file="/root/store.txt"

if [ ! -f $file ]; then
  echo 1 > $file
  value=1
else
  value=$(cat $file)
  value=$((value + 1))
fi

echo "$value"

Expected behavior
podman logs test should output:

1

Actual behavior
podman logs test outputs:

1
2

Environment:

• OS: Fedora 41
• podman version: 5.4.1
• podman compose version: 1.3.0

Additional context

podman compose up behaves as expected:

podman logs test outputs:

1

[ninja-quokka]

Hi @Fedma123 I don't believe this is a bug, let me explain:

When you use the podman-compose up -d command, if needed it will create any resources needed like the pod, network and containers.

What you can see in the logs is podman-compose running your container with -d (which exits as there is nothing holding the container up) then podman-compose starting your container (because by now it has exited as there is nothing holding it up)

When you have a container that runs a command that completes like your init.sh, you shouldn't use the -d option.

To demonstrate, add sleep infinity to the last line in you init.sh file.

Build the container again with podman-compose build and then run again with podman-compose up -d, you will see the container only gets ran once because podman-compose skips the last step of starting the container as it's still running as the sleep process is holding the container alive.

Let me know what you think!

[Fedma123]

Hi @ninja-quokka, to investigate further, tried the following with the same files shown above.

First, I tried to execute docker compose (plugin) instead of podman-compose against podman version 5.4.1, and docker compose up -d does not run the entrypoint twice. This suggests that probably the intended behavior of the -d flag is to run the entrypoint once even if the entrypoint terminates.

Then, I tried to run podman-compose 1.3.0 against another podman version (4.3.1) to see if podman itself made any difference, and it didn't: podman-compose up -d still runs the entrypoint twice. This suggests that the unintended behavior is in podman-compose.

Finally, I run git bisect on the podman-compose repository, starting from version 1.0.3 which is a good revision that does not run the entrypoint twice. Outcome: commit c6a1c4c seems to have introduced the issue.

As a side note, this behavior does not play nicely with init-containers: if a container is meant to run a non-idempotent command, then this behavior prevents successful startup. So, I think this should be considered a bug.

[schnell18]

Hi @ninja-quokka and @Fedma123 ,

I believe this issue is ineed a bug which is hightlighted in the code snippet as follows:

2794 podman_command = "run" if args.detach and not args.no_start else "create"
2795
2796 await create_pods(compose, args)
2797 for cnt in compose.containers:
2798 if cnt["_service"] in excluded:
2799 log.debug("** skipping: %s", cnt["name"])
2800 continue
2801 podman_args = await container_to_args(
2802 compose, cnt, detached=args.detach, no_deps=args.no_deps
2803 )
2804 subproc = await compose.podman.run([], podman_command, podman_args)
2805 if podman_command == "run" and subproc is not None:
2806 await run_container(
2807 compose, cnt["name"], deps_from_container(args, cnt), ([], "start", [cnt["name"]])
2808 )

Line 2804 runs the entrypoint the first time when the podman_command is run, which creates the container and start it.
Line 2806 runs the entrypoint the second time when "-d" is specified.

There are a few integration test cases mentioning this bug:

• podman-compose/tests/integration/env-file-tests/test_podman_compose_env_file.py

  Line 129 in 342a39d

  # FIXME: gives a weird output, needs to be double checked

• podman-compose/tests/integration/ulimit/test_podman_compose_ulimit.py

  Line 37 in 342a39d

  # BUG: figure out why echo is called twice

The fix is to create container without starting it on line 2804. This is exactly what the PR #1184 does.
@Fedma123, I have tested your example ok with the fix in PR #1184. Could you please give it a try and get back to me?
Thanks!