stop_grace_period setting ignored

[the-antz]

podman-compose down stops the containers using podman stop -t=1 xxx, ignoring the stop_grace_period setting.

[HidingCherry]

push

This is still the case.

services:
  xxx:
    stop_grace_period: 1m30s

no difference with stop_grace_period: 90s

$ podman-compose restart xxx
using podman version: podman version 3.2.3
podman restart -t 10 xxx_xxx_1

[HidingCherry]

I guess I'll stop using podman-compose at the end. The timeout variable is important for any database or program, which still has to write data on disk.

[msugakov]

Interestingly, podman-compose down supports providing shutdown timeout as command-line argument.

$ podman-compose down --help
...
  -t TIMEOUT, --timeout TIMEOUT
                        Specify a shutdown timeout in seconds.

[s-rog]

Need this as well, manually specifying -t for all services when only 1 needs it is quite annoying.

[in-fke]

status?

[muayyad-alsadi]

I've just fixed this, please test

pip3 install https://github.com/containers/podman-compose/archive/devel.tar.gz

[in-fke]

I updated, but it makes no difference. I made sure that /usr/local/lib/python3.6/site-packages/podman_compose.py was actually up-to-date with your changes and it seems to. It is still using 10s.

I added log output, and "timeout" from this line already yields 10 (I am not a Python programmer and I don't know why):

timeout = getattr(args, "timeout", None)
log("timeout from args: " + str(timeout))

(renders "timeout from args: 10")

Output also with "args" logged shows me that timeout is already preset from "args" (don't know where this is coming from)

podman-compose down
podman-compose version: 1.0.4
['podman', '--version', '']
using podman version: 4.2.0
args: Namespace(command='down', dry_run=False, env_file='.env', file=['docker-compose.yml'], no_ansi=False, no_cleanup=False, no_pod=False, pod_args='--infra=false --share=', podman_args=[], podman_build_args=[], podman_inspect_args=[], podman_path='podman', podman_pull_args=[], podman_push_args=[], podman_rm_args=[], podman_run_args=[], podman_start_args=[], podman_stop_args=[], podman_volume_args=[], project_name=None, services=[], timeout=10, version=False, volumes=False)
** excluding:  set()
timeout from args: 10
podman stop -t 10 SERVICE

Also, I think that line evaluating args (which should yield None) needs to move in the for loop, otherwise you would get "timeout" initialized from the first container, and then it never gets re-initialized.

Consider this case, which would fail otherwise:

services:
  a:
    <no stop_grace_period, timeout gets initialized to 10>
  b:
    stop_grace_period: 90s (gets ignored, because timeout is already initialized to 10 from previous container)

[in-fke]

Also, the -t seems to get injected for the "start" command as well?

podman-compose start mysql
podman-compose version: 1.0.4
['podman', '--version', '']
using podman version: 4.2.0
podman start -t 10 sphinx-mysql
Error: unknown shorthand flag: 't' in -t
See 'podman start --help'
exit code: 125

And I found the reason why "args" already gives 10

    parser.add_argument(
        "-t",
        "--timeout",
        type=int,
        default=10,
        help="Use this timeout in seconds for container shutdown when attached or when containers are already running. (default: 10)",
    )

[muayyad-alsadi]

And I found the reason why "args" already gives 10

this is for up not start, and it's similar to that of docker-compose

$ docker-compose --version
docker-compose version 1.27.4, build unknown
$ docker-compose up --help
...
    -t, --timeout TIMEOUT      Use this timeout in seconds for container
                               shutdown when attached or when containers are
                               already running. (default: 10)

no worries, I've just fixed all this

please test again

[in-fke]

Thanks for the quick update. Yet the problem with not re-initing within the for loop.

services:
  a:
    stop_grace_period: 90s
  b:
    <no stop_grace_period specified, timeout stays at 90, but should default back to 10>

[muayyad-alsadi]

I've just fixed that

[in-fke]

Ok, great, everything seems to work now, at least for the cases I covered (certain docker-compose.yml).

[samweisgamdschie]

Hi!

I use debian 12 and I have this issue with stop_grace_period ignored as well. In which version can this be found?

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

[samweisgamdschie]

OK after upgrade to 1.0.6 it works now. => Thanks for that.