Claude/kasm manager start period

[tigerblue77]

---

• I have read the contributing guideline and understand that I have made the correct modifications

---

Description:

The Dockerfile makes proxy wait for both kasm_manager and kasm_api to be healthy:

# Fix dependencies so containers start in the right order
yq -i '.services.proxy.depends_on = {"kasm_manager":{"condition": "service_healthy"},"kasm_api":{"condition": "service_healthy"}, ...}'

and then gives a healthcheck grace period to kasm_api so that gate is usable on a slow host:

yq -i '.services.kasm_api.healthcheck += {"start_period": "60s","start_interval": "30s"}'

kasm_manager is gated the same way but never got the same treatment. It keeps the stock healthcheck, which has no grace period suited to being used as a startup gate, so on a cold start it can exhaust its retries and report unhealthy before it is ready.

This change applies the same start_period and start_interval to kasm_manager, immediately after the kasm_api line. Same values, same mechanism, no new concept. Replicated in Dockerfile.aarch64 as per the contributing guidelines, and a changelog entry added to readme-vars.yml.

Benefits of this PR and context:

closes #103

Without a grace period, a slow cold start makes Compose abort the whole up, because Compose only gives up on a service_healthy wait when the dependency reports unhealthy — while it reports starting it waits indefinitely (pkg/compose/convergence.go):

case container.Healthy:    // continue
case container.Unhealthy:  return false, fmt.Errorf("container %s is unhealthy", name)
case container.Starting:   return false, nil   // keep waiting

So a start_period is exactly what turns this failure into a successful wait.

When it aborts, the result is:

 Container kasm_api Healthy
 Container kasm_manager Error dependency kasm_manager failed to start
dependency failed to start: container kasm_manager is unhealthy
s6-rc: warning: unable to start service svc-kasm: command exited 1

proxy is left in created and never started, and so is kasm_rdp_https_gateway, which the Dockerfile makes depend on proxy. kasm_manager becomes healthy moments later, but svc-kasm is a oneshot, so nothing runs /opt/kasm/bin/start again and the container stays half started indefinitely: the installation wizard on port 3000 answers, because it runs in the outer container, while KASM_PORT is dead until someone runs docker exec kasm /opt/kasm/bin/start by hand.

This is especially unpleasant behind a reverse proxy that uses Docker service discovery. Traefik's Docker provider skips any container whose health is not healthy (pkg/provider/docker/config.go) without logging anything, so Kasm silently never gets a route and nothing anywhere points at the real cause.

How Has This Been Tested?

Reported from a deployment on 1.19.0-ls139, Docker Engine 28.x, x86-64, on a host where kasm_manager is consistently slow to become healthy. Every recreation of the container reproduced the failure, and running /opt/kasm/bin/start by hand afterwards recovered it every time, which is what identified the dependency wait as the failing step. Full container log and docker ps -a output are in #103.

Please note this change itself has not been verified by rebuilding the image, since I could not reproduce the build pipeline locally — the reasoning rests on the existing kasm_api line doing exactly this and on the Compose behaviour quoted above. Happy to adjust the values or the approach if you would rather solve it differently, for instance by retrying /opt/kasm/bin/start in svc-kasm/run, which is a oneshot today and so makes any transient boot failure permanent.

Source / References:

• Issue [BUG] kasm_manager has no healthcheck start_period, so a cold start leaves kasm_proxy created but never started #103
• Docker Compose dependency wait logic: https://github.com/docker/compose/blob/main/pkg/compose/convergence.go
• Traefik Docker provider health filtering: https://github.com/traefik/traefik/blob/master/pkg/provider/docker/config.go

---

Generated by Claude Code and reviewed by @tigerblue77

[github-actions]

Thanks for opening this pull request! Be sure to follow the pull request template!