Specifying a timeout option seems to be ignored by the runner

Describe the bug

Specifying a timeout option of 5 seconds doesn’t seem to be applied when initializing a service or a container in an Actions workflow.

To Reproduce Steps to reproduce the behavior:

• Create an Actions workflow that initializes either a service or a container with the following options for health check with a 5-second timeout. Here’s an example:

    services:
      redis:
        image: redis:alpine
        options: --health-cmd "redis-cli ping" --health-interval 10s --health-timeout 5s --health-retries 5
        ports:
          - 6379:6379

• Trigger a workflow.
• Observe the workflow run logs will show (see below) an incremental backoff, just not 5 seconds apart for timeout as evidence in logs below.

Expected behavior

A clear and concise description of what you expected to happen.

I expected to see the health check performed in 5 second increments rather than a lower count of 1-4 seconds.

Runner Version and Platform

• Latest in production as of May 20, 2020.
• OS of the machine running the runner? Linux

What’s not working?

Please include error messages and screenshots.

See below. ✌️

Job Log Output

https://github.com/francisfuzz/molecula/runs/694847523?check_suite_focus=true#step:2:39 logs_2.zip

/usr/bin/docker create --name 19f22998701d46b9948ff54476cadd73_redisalpine_f9b603 --label be76db --network github_network_1977d79f05bb41db9d15cb4ed4c9de5f --network-alias redis -p 6379:6379 --health-cmd "redis-cli ping" --health-interval 10s --health-timeout 5s --health-retries 5 -e GITHUB_ACTIONS=true -e CI=true redis:alpine
84c14711d4e97bf675dfb0555aff4d62864fd005d18059bc2e5132abdf83641c
/usr/bin/docker start 84c14711d4e97bf675dfb0555aff4d62864fd005d18059bc2e5132abdf83641c
84c14711d4e97bf675dfb0555aff4d62864fd005d18059bc2e5132abdf83641c
/usr/bin/docker ps --all --filter id=84c14711d4e97bf675dfb0555aff4d62864fd005d18059bc2e5132abdf83641c --filter status=running --no-trunc --format "{{.ID}} {{.Status}}"
84c14711d4e97bf675dfb0555aff4d62864fd005d18059bc2e5132abdf83641c Up Less than a second (health: starting)
/usr/bin/docker port 84c14711d4e97bf675dfb0555aff4d62864fd005d18059bc2e5132abdf83641c
6379/tcp -> 0.0.0.0:6379
/usr/bin/docker inspect --format="{{if .Config.Healthcheck}}{{print .State.Health.Status}}{{end}}" 84c14711d4e97bf675dfb0555aff4d62864fd005d18059bc2e5132abdf83641c
starting
redis service is starting, waiting 2 seconds before checking again.
/usr/bin/docker inspect --format="{{if .Config.Healthcheck}}{{print .State.Health.Status}}{{end}}" 84c14711d4e97bf675dfb0555aff4d62864fd005d18059bc2e5132abdf83641c

Runner and Worker’s Diagnostic Logs

logs_2.zip

---

👋 @actions/service-oncall for triage/prioritization

[thboop]

Hey @francisfuzz thanks for the report!

There are actually two different things going on here:

• Docker’s built in health check system
• The runner polling the docker container health via the docker inspect command

The --health-cmd "redis-cli ping" --health-interval 10s --health-timeout 5s --health-retries 5 applies to the docker container. Every 10 seconds it will run redis-cli ping to determine if the container is healthy or not.

The runner uses the docker inspect command to get the status of the container. Once all containers are started and healthy, it proceeds to then continue with the job, completing the setup job steps and moving forward into the actual job steps. We have an exponential backoff to power this, and do not use the docker container health values. The message you are seeing comes from here

The mainline scenario for the later is waiting for all container to have started before continuing the job. I don’t think we actually want to use the healthcheck values for this, as we aren’t doing a full healthcheck system, just querying the status.

That being said, is there something related to the healthcheck system causing issues with your job that we could help address? Or is this something you noticed and just wanted to make sure wasn’t an issue?

[vinayakkulkarni]

I am facing similar issue, I have,

options: >-
          --health-start-period 30s
          --health-interval 30s
          --health-timeout 10s
          --health-retries 5
          --expose 8080
          --publish 8080:8080

ideally, the start-period should be after 30s but actions runner dies after 2s (default backoff period)