compose: docker-compose up --timeout does not appear to work
Version
Docker version 17.09.0-ce, build afdb6d4 docker-compose version 1.17.0-rc1, build a0f95af
Problem
Setting timeout on docker-compose up
does not affect the shutdown timeout
docker-compose.yml
file
version: "3.3"
services:
test2:
image: debian:9
command: nohup sleep 1000
(Also tried with version 2.0, and 2.3)
$ docker-compose up -d --timeout 123 test2
$ docker inspect issue_test2_1 # Shows no StopTimeout set at all
$ time docker-compose stop
Stopping issue_test2_1 ... done
real 0m11.473s
user 0m0.908s
sys 0m0.144s
(Also tried down
)
Expected behavior
$ docker run -it --rm --stop-timeout=121 --name test1 debian:9 nohup sleep 1000
$ docker inspect test1 # Show a StopTimeout of 121 set in the "Config" section
$ docker stop test1 # takes the ~121 seconds
Other
Using stop_grace_period
does work when using docker-compose commands, but not docker commands, as it appears that docker-compose stop
or down
just re-reads the docker-compose.yml
file at stop time, and has nothing to do with how the container was started
Objective
I am trying to set the StopTimeout in the actual container, so the daemon knows what to respect when it is shutdown (for example during a full system shutdown). Something like stop_grace_period
doesn’t help me, as that only tells docker-compose
how long to wait, not the docker daemon.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 19
I understand that “Docker” is made of multiple pieces and that you can update/install those independently. That’s a great design and I’m grateful for that, but to most people (especially those on Mac and Windows) they go to docker.com and download the installer and that’s “Docker”, so a serious regression like this really needs to be fixed in a point release. Basically, just because you’re doing things right in one area (separation of responsibility) doesn’t excuse you from doing the right thing in another area (proper release management), because most users of “Docker” have no idea how to manually upgrade/downgrade a single component, and even if they did do it, they’ll be cursing your name the entire time. 😉
Oh, I see what you mean now. We should probably revert the changes in #5435 . As a workaround in the meantime, you can use
docker-compose stop --timeout X && docker-compose up -d
Just Restart your docker Desktop!
Our use case is pulling an updated image and then calling
docker-compose up
to restart with the new container, but here’s a simpler example that demonstrates why--timeout
is needed and my question is what’s the correct way to specify a timeout since--timeout
is no longer available.test_timeout.py
Dockerfile
test_timeout.yml
Then run the following:
And in a separate terminal run the following after it prints
Processed
:@shin- Since this is a regression that removes functionality that had existed for quite some time, can we please get some guidance on the proper way to set the timeout using docker-compose?
@shin- I see now that I misunderstood what the
--timeout
was for, its for when you rundocker-compose up
and it has to shutdown the container first to start a new one, that’s the timeout associated with that shutdown only (if I read the code correctly). I can see how the help message is saying that now, but yes, it could use a little clarifying.I think a better solution to my problem is… Can we make it so that when
docker-compose
creates a new container, ifstop_grace_period
is specified, then it addsStopTimeout
to theConfig
? Just to clarify, that’s the ONLY small change I’m suggesting. You already have the use ofstop_grace_period
when you rundocker-compose stop
, and I’m not suggesting changing how any of that already works. Simply adding that attribute to theConfig
of the container. This way other docker apis (such as thedocker
cli anddockerd
) know and respect this timeout too.