Healthcheck interval command line options ignored if set in Containerfile

[travier]

Issue Description

The healthcheck interval related command line options (health-interval, health-startup-interval) are ignored when the same options are directly set in the container image / Containerfile.

Example in: https://github.com/filebrowser/filebrowser/blob/master/Dockerfile

Steps to reproduce the issue

Steps to reproduce the issue

1. Pull the following image: docker.io/filebrowser/filebrowser:latest
2. Pass --health-interval=30m --health-startup-interval=disable as arguments to podman run

Describe the results you received

The healthcheck command is run on startup and every 3 seconds.

Describe the results you expected

The healthcheck command is not run on startup and only every 30 minutes.

podman info output

host:
  arch: amd64
  buildahVersion: 1.31.2
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: conmon-2.1.7-2.fc38.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.1.7, commit: '
  cpuUtilization:
    idlePercent: 98.68
    systemPercent: 0.48
    userPercent: 0.83
  cpus: 4
  databaseBackend: boltdb
  distribution:
    distribution: fedora
    variant: coreos
    version: "38"
  eventLogger: journald
  freeLocks: 2044
  hostname: XXX
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 6.4.15-200.fc38.x86_64
  linkmode: dynamic
  logDriver: journald
  memFree: 6637842432
  memTotal: 8113111040
  networkBackend: cni
  networkBackendInfo:
    backend: cni
    dns:
      package: podman-plugins-4.6.2-1.fc38.x86_64
      path: /usr/libexec/cni/dnsname
      version: |-
        CNI dnsname plugin
        version: 1.3.1
        commit: unknown
    package: |-
      containernetworking-plugins-1.3.0-2.fc38.x86_64
      podman-plugins-4.6.2-1.fc38.x86_64
    path: /usr/libexec/cni
  ociRuntime:
    name: crun
    package: crun-1.8.7-1.fc38.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 1.8.7
      commit: 53a9996ce82d1ee818349bdcc64797a1fa0433c4
      rundir: /run/crun
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
  os: linux
  pasta:
    executable: /usr/bin/pasta
    package: passt-0^20230823.ga7e4bfb-1.fc38.x86_64
    version: |
      pasta 0^20230823.ga7e4bfb-1.fc38.x86_64
      Copyright Red Hat
      GNU Affero GPL version 3 or later <https://www.gnu.org/licenses/agpl-3.0.html>
      This is free software: you are free to change and redistribute it.
      There is NO WARRANTY, to the extent permitted by law.
  remoteSocket:
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.2.1-1.fc38.x86_64
    version: |-
      slirp4netns version 1.2.1
      commit: 09e31e92fa3d2a1d3ca261adaeb012c8d75a8194
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.3
  swapFree: 0
  swapTotal: 0
  uptime: 1h 30m 0.00s (Approximately 0.04 days)
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  - journald
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /usr/share/containers/storage.conf
  containerStore:
    number: 4
    paused: 0
    running: 4
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev,metacopy=on
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 171250266112
  graphRootUsed: 50330509312
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 5
  runRoot: /var/run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.6.2
  Built: 1693251588
  BuiltTime: Mon Aug 28 19:39:48 2023
  GitCommit: ""
  GoVersion: go1.20.7
  Os: linux
  OsArch: linux/amd64
  Version: 4.6.2

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

No

Additional environment details

N/A

Additional information

Always happen

[hlovdal]

This is really annoying. I have wasted a lot of time now attempting to stop the health check from failing while debugging a resolver problem, but regardless of what I do the container always restarts, rendering debugging impossible.

And because of similar experiences in the past I prefer to have the health check command encapsulated in a script on the root directory named /health.sh (that typically contains a curl -f http://... command). This then allows me to quickly overwrite this script to just a call to true instead at runtime, e.g. podman cp just_call_true.sh my_container:/health.sh, to disable health checking temporary.

But despite doing that, the container still failed the health check and restarted! Even though podman exec -ti my_container cat /health.sh shows my updated script that just calls true, after 30 seconds the container restarts...

$ podman image inspect 90... | tail -11
          "Healthcheck": {
               "Test": [
                    "CMD-SHELL",
                    "/health.sh || exit 1"
               ],
               "StartPeriod": 15000000000,
               "Interval": 30000000000,
               "Timeout": 3000000000
          }
     }
]
$

(This is was started using podman-compose and not the command line, however the shell script issue should be independent of that)

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[hlovdal]

Regardless of what constitutes "no activity" (just lack of comments to this issue?), the problem is clearly described and there is not anything left to figure out. The remaining work is just to have someone find the time to fix it.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.