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)

Most upvoted comments

@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:

version: '3.7'

services:
  bash:
    stop_grace_period: 2m
    image: bash
    command: -c 'trap "sleep 62" TERM; sleep 61'

and run

docker stack deploy -c docker-compose.yml test

take the id from docker ps from the new container and issue a

docker stop <container id>

you’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.

jsecchiero on Jan 27, 2019

I’m affected, too

davepanarese on May 28, 2018