8000 Healthcheck `start_interval` is silently ignored when `start_period` is zero · Issue #49900 · moby/moby · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Healthcheck start_interval is silently ignored when start_period is zero #49900

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
tvardero opened this issue Apr 29, 2025 · 2 comments
Open

Healthcheck start_interval is silently ignored when start_period is zero #49900

tvardero opened this issue Apr 29, 2025 · 2 comments
Labels
docs/revisit kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. status/0-triage

Comments

@tvardero
Copy link
tvardero commented Apr 29, 2025 •
edited
Loading

Description

Redirected from docker/compose#12782 . See this issue for full information, reproduction and docker/docker compose versions.

Description:

start_interval is not working on container startup, interval is used instead for the first health check.

This creates a long wait time for containers startup with chained dependencies: where service B waits for service A to be healthy, then service C waits for services B to be healthy, and so on.

Using short interval instead of start_interval is a workaround, however this adds more stress to the container in runtime.

@ndeloof added:

Same applies if you run postgres using docker run:

$ docker run --health-start-interval 5s --health-cmd "pg_isready -U postgres" -e POSTGRES_PASSWORD=toto -d postgres

... rest is skipped

This bug is related to this feature request: #48874

Also worth mentioning findings by @MrQubo:

I had exactly the same scenario and it also took me some time to find out that the start-period is required for start-interval to work. Silently ignoring start-interval should be considered a bug.

Adding start_period together with start_interval works as expected.

Reproduce

See the linked issue.

Expected behavior

start_interval should be used for the first health check, instead of interval

docker version

Client:
 Version:           28.0.4
 API version:       1.48
 Go version:        go1.23.7
 Git commit:        b8034c0
 Built:             Tue Mar 25 15:07:48 2025
 OS/Arch:           windows/amd64
 Context:           desktop-linux

Server: Docker Desktop 4.40.0 (187762)
 Engine:
  Version:          28.0.4
  API version:      1.48 (minimum version 1.24)
  Go version:       go1.23.7
  Git commit:       6430e49
  Built:            Tue Mar 25 15:07:22 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.26
  GitCommit:        753481ec61c7c8955a23d6ff7bc8e4daed455734
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Version:    28.0.4
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.1.3
    Path:     C:\Program Files\Docker\cli-plugins\docker-ai.exe
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.22.0-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-buildx.exe
  cloud: Docker Cloud (Docker Inc.)
    Version:  0.2.20
    Path:     C:\Program Files\Docker\cli-plugins\docker-cloud.exe
  compose: Docker Compose (Docker Inc.)
    Version:  v2.34.0-desktop.1
    Path:     C:\Program Files\Docker\cli-plugins\docker-compose.exe
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.38
    Path:     C:\Program Files\Docker\cli-plugins\docker-debug.exe
  desktop: Docker Desktop commands (Beta) (Docker Inc.)
    Version:  v0.1.6
    Path:     C:\Program Files\Docker\cli-plugins\docker-desktop.exe
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
    Path:     C:\Program Files\Docker\cli-plugins\docker-dev.exe
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.27
    Path:     C:\Program Files\Docker\cli-plugins\docker-extension.exe
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-init.exe
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-sbom.exe
  scout: Docker Scout (Docker Inc.)
    Version:  v1.17.0
    Path:     C:\Program Files\Docker\cli-plugins\docker-scout.exe

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 9
 Server Version: 28.0.4
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 nvidia runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 753481ec61c7c8955a23d6ff7bc8e4daed455734
 runc version: v1.2.5-0-g59923ef
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
 Kernel Version: 5.15.167.4-microsoft-standard-WSL2
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 28
 Total Memory: 31.22GiB
 Name: docker-desktop
 ID: f020cabf-053e-4182-a2c0-42a3a5ab1677
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=npipe://\\.\pipe\docker_cli
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false

WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: DOCKER_INSECURE_NO_IPTABLES_RAW is set
WARNING: daemon is not using the default seccomp profile

Additional Info

No response
@tvardero tvardero added kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. status/0-triage labels Apr 29, 2025
@tvardero tvardero changed the title Healthcheck start_interval is not respected Healthcheck start_interval is not respected for the first check, interval is used instead Apr 29, 2025
@corhere corhere changed the title Healthcheck start_interval is not respected for the first check, interval is used instead Healthcheck start_interval is silently ignored when start_period is zero Apr 30, 2025
@corhere corhere added the kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. label Apr 30, 2025
@corhere
Copy link
Contributor
corhere commented Apr 30, 2025

Maybe it should be valid (in the next API version) to create a container with a nonzero start interval iff its start period is also nonzero. As I outlined in #48874 (comment) probing the container's health at the start interval rate outside the start period is a breaking change which affects how long the container's grace period is before it gets marked unhealthy.

@ArthurWuTW
Copy link
ArthurWuTW commented May 3, 2025 •
edited
Loading

Maybe it should be valid (in the next API version) to create a container with a nonzero start interval iff its start period is also nonzero.

There are two possible approaches to notify users start interval is invalid due to start period being set to 0.

Method1. Raise an error, and prevent the container from being created

root@e72b78477e0d:/go/src/github.com/docker/docker# docker run -d \
  --name web \
  -p 8080:80 \
  --health-cmd="curl -f http://localhost" \
  --health-interval=2s \
  --health-retries=2 \
  --health-start-interval=15s \
  nginx:latest
docker: Error response from daemon: StartInterval requires StartPeriod to be set in Healthcheck

Run 'docker run --help' for more information
root@e72b78477e0d:/go/src/github.com/docker/docker# docker container ls -a
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

Method2. Simply print a WARNING message

root@e72b78477e0d:/go/src/github.com/docker/docker# docker run -d \
  --name web \
  -p 8080:80 \
  --health-cmd="curl -f http://localhost" \
  --health-interval=2s \
  --health-retries=2 \
  --health-start-interval=15s \
  nginx:latest
WARNING: StartInterval is valid only if nonzero StartPeriod is set in HealthCheck
34c5a076d3560770e1917d0b7d912b307c2748025e85f28eb68281eac65fe9c0
root@e72b78477e0d:/go/src/github.com/docker/docker# docker container ls -a
CONTAINER ID   IMAGE          COMMAND                  CREATED         STATUS                   PORTS                  NAMES
34c5a076d356   nginx:latest   "/docker-entrypoint.…"   8 seconds ago   Up 8 seconds (healthy)   0.0.0.0:8080->80/tcp   web

Compose currently uses something like Method1, but I believe it may not be strictly necessary to fail to create container. Prefer Method2 personally.... What are your thoughts?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
docs/revisit kind/bug Bugs are bugs. The cause may or may not be known at triage time so debugging may be needed. kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. status/0-triage
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@corhere @ArthurWuTW @tvardero
0