moby: stop_grace_period also must set StopTimeout on docker stack deploy
Hi there,
Description
as already asked for docker compose it would be nice to have that feature also for docker stack deploy
.
stop_grace_period is nice for consistently shutdown containers during rolling updates but this not work during swarm node maintenance (service, container and host shutdown).
Steps to reproduce the issue:
- docker stack deploy -c docker-compose.yml test
version: '3.6'
services:
nginx:
stop_grace_period: 2m
image: nginx:alpine
docker inspect <container id> | grep StopTimeout
Describe the results you received: I expect to find 2m also for the StopTimeout
Describe the results you expected: with docker-compose i have this:
$ docker inspect <container id> | grep StopTimeout
"StopTimeout": 120
Output of docker version
:
Client:
Version: 18.03.1-ce
API version: 1.37
Go version: go1.9.5
Git commit: 9ee9f40
Built: Thu Apr 26 07:17:20 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm
Server:
Engine:
Version: 18.03.1-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.5
Git commit: 9ee9f40
Built: Thu Apr 26 07:15:30 2018
OS/Arch: linux/amd64
Experimental: false
Output of docker info
:
Containers: 10
Running: 4
Paused: 0
Stopped: 6
Images: 29
Server Version: 18.03.1-ce
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
NodeID: y8jr5aturl6z8uv8jtdqezdfy
Is Manager: true
ClusterID: 5vw3klw72dzidcslo4a9ungai
Managers: 1
Nodes: 1
Orchestration:
Task History Retention Limit: 5
Raft:
Snapshot Interval: 10000
Number of Old Snapshots to Retain: 0
Heartbeat Tick: 1
Election Tick: 10
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Force Rotate: 0
Autolock Managers: false
Root Rotation In Progress: false
Node Address: 172.16.111.5
Manager Addresses:
172.16.111.5:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.13.0-37-generic
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.44GiB
Name: master
ID: 7ZB6:IG3J:2EXA:VEEA:KLNX:FGFI:43KQ:DERQ:XBVU:37P7:LRGN:SZ55
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No swap limit support
Thanks for any advice. Jacopo
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 12
- Comments: 15 (2 by maintainers)
@crwenner thanks for your help!
StopGracePeriod at swarm level and at docker level have different behavior. For example the first, that actually works, permit to do a rolling upgrade using StopGracePeriod time. The second, that is not inherited from the stack deploy command, allow at docker service to shutdown the container gracefully, in respect to StopGracePeriod, during a maintenance (service, container and host shutdown).
I’ll show you a practical example to replicate the issue: write this docker-compose file:
and run
take the id from
docker ps
from the new container and issue ayou’ll see that the stop take just 10 sec and not 2m as specified in stop_grace_period time, because the container have not the StopGracePeriod properly configured.
If you do the same step above with docker-compose alone that setting is correctly configured and works fine.
I have upgraded to the latest docker-ce version 18.09.1 but the problem persists.
I’m affected, too