Docker Swarm healthcheck.test property does not validate for CMD/CMD-SHELL/NONE, results in strange behavior when invalid. #49034
Labels
area/api
area/cli
area/stack
kind/bug
Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed.
version/27.3
Description
healthcheck.test takes an array where the first element needs to be CMD, CMD-SHELL, or NONE. And in docker compose at least, if you try to compose up with an invalid value, it gives you a nice error message:
healthcheck.test must start either by "CMD", "CMD-SHELL" or "NONE"
HOWEVER, if you try to deploy an invalid value with the docker stack command, it does NOT give any sort of error message. Not only is that the case, but it also results in some unusual behavior.
Since it successfully creates the containers asked for (and always considers them healthy, regardless of what you put in the health test), but fails to properly start/create the service completely (presumably the service defaults to considering it unhealthy), resulting in it showing 0 replicas when using docker service ls, and also failing to make the service available to other services networked to it as a result as well. This odd contradictory behavior made things very confusing to debug.
Reproduce
1.5.) Try running
docker compose up
, notice how it gives an error message.2.) Initialize a swarm if you don't already have one with
docker swarm init
.3.) Use
docker stack up -c docker-compose.yml healthtest --detach=false
, notice how it gives no error message, and hangs when trying to create the service.4.) Exit out from the attached log to view what got created.
5.) Docker Desktop (or other methods) should show a container for the postgres image has been created, and is not being restarted or recreated.
6.) Use
docker service ls
, and note how it has 0/1 replicas started for the service, despite the clearly running container.7.) (clean up) Use
docker stack down healthtest
when finished.Expected behavior
When deploying to the swarm it should ideally validate the first healthcheck.test parameter like docker compose already does. If this is not viable for whatever reason, then it should AT LEAST give more consistent behavior for the invalid test condition, such as having the container fail its (invalid) health tests and see constant restarts (a clearer sign that something is wrong).
docker version
Client: Version: 27.3.1 API version: 1.47 Go version: go1.22.7 Git commit: ce12230 Built: Fri Sep 20 11:38:18 2024 OS/Arch: darwin/arm64 Context: desktop-linux Server: Docker Desktop 4.36.0 (175267) Engine: Version: 27.3.1 API version: 1.47 (minimum version 1.24) Go version: go1.22.7 Git commit: 41ca978 Built: Fri Sep 20 11:41:19 2024 OS/Arch: linux/arm64 Experimental: false containerd: Version: 1.7.21 GitCommit: 472731909fa34bd7bc9c087e4c27943f9835f111 runc: Version: 1.1.13 GitCommit: v1.1.13-0-g58aa920 docker-init: Version: 0.19.0 GitCommit: de40ad0
docker info
Additional Info
The text was updated successfully, but these errors were encountered: