`HEALTHCHECK` `--start-interval` parameter produces "not defined" error

[Paraphraser]

Issue #21701 reported a problem where the HEALTHCHECK --start-interval parameter was producing an error.

PR #5472 added support for --start-interval and closed #21701.

However, as of today (2025-03-03), a Dockerfile containing:

HEALTHCHECK --interval=60s --timeout=8s --retries=2 --start-period=60s --start-interval=3s \
  CMD ["/bin/sh", "/usr/sbin/healthcheck.sh"]

is producing this error:

[2/2] STEP 9/9: HEALTHCHECK --interval=60s --timeout=8s --retries=2 --start-period=60s --start-interval=3s   CMD ["/bin/sh", "/usr/sbin/healthcheck.sh"]
flag provided but not defined: -start-interval
Usage:
  -interval string
    	
  -retries string
    	
  -start-period string
    	
  -timeout string
    	
Error: building at STEP "HEALTHCHECK --interval=60s --timeout=8s --retries=2 --start-period=60s --start-interval=3s CMD /bin/sh /usr/sbin/healthcheck.sh": flag provided but not defined: -start-interval

Using either docker build or docker buildx build with the same Dockerfile does not produce this error.

At github.com/zyclonite/zerotier-docker PR38, this issue appears to be behind all these failures:

Has the PR #5472 fix fallen out?

For the record, this is from my local build system (where I can replicate the GitHub problem):

$ docker version
Client: Docker Engine - Community
 Version:           28.0.1
 API version:       1.48
 Go version:        go1.23.6
 Git commit:        068a01e
 Built:             Wed Feb 26 10:41:16 2025
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          28.0.1
  API version:      1.48 (minimum version 1.24)
  Go version:       go1.23.6
  Git commit:       bbd0a17
  Built:            Wed Feb 26 10:41:16 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.25
  GitCommit:        bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
 runc:
  Version:          1.2.4
  GitCommit:        v1.2.4-0-g6c52b3f
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

$ buildah --version
buildah version 1.28.2 (image-spec 1.1.0-rc2, runtime-spec 1.0.2-dev)

$ uname -a
Linux prx-deb 6.1.0-30-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 (2025-01-12) x86_64 GNU/Linux

I do not know which version of buildah is being used on GitHub.

[flouthoc]

Hi @Paraphraser , Your buildah version looks relatively old, the PR you have tagged got added to buildah in v1.37.0 I think. I would recommend moving to newer versions of podman/buildah and test this.

Thanks

[Paraphraser]

Hi @flouthoc - thanks for your reply.

According to buildah install.md:

• for Debian I need Bookworm plus a standard apt install buildah.
• for Ubuntu I need 20.10 or later, also with a standard apt install buildah.

I have:

• Debian Bookworm 12.9. The apt install gets me buildah version 1.28.2.
• Ubuntu 24.04.2 Noble Numbat. The apt install gets me buildah version 1.33.7.

Both of those are less than the v1.37.0 you mention and, as expected, both produce the same error about --start-interval.

You recommend that I move to newer versions.

I would be happy to do that but when I follow the buildah install.md instructions, I get obsolete versions.

All other things being equal, doesn't that mean either:

1. More recent versions of buildah aren't actually making it to the apt backing stores; or
2. Something about my Debian and Ubuntu systems is preventing apt from fetching the latest and greatest version of buildah

Do you have any thoughts on how can I fix that?

---

As a separate but related issue, the build failures occurring on GitHub would seem to have the same cause. I don't know how to confirm the version of buildah being used for those automated builds but it seems likely that whatever is stopping apt from getting a more-recent release on my own systems is also affecting the mechanism(s) by which GitHub comes to use buildah.

So, in that sense, isn't the error about --start-interval really telling us there's a serious supply-chain problem somewhere? Do you want to re-open this issue and rename it to something like apt repositories have obsolete releases of buildah, or should I open a new issue with that title?