CasaDrop 2.4.1 healthcheck bug

Insight & Feedback
1

The application starts and works normally.

Docker healthcheck:

wget --no-verbose --tries=1 --spider http://localhost:8080/api/auth/status

always fails with:

Remote file does not exist -- broken link!!!

However, the endpoint is valid:

wget -qO- http://localhost:8080/api/auth/status

returns:

{"authenticated":false,"setupRequired":false,"envPassword":true}

So the container is healthy, but BusyBox wget --spider incorrectly marks it as failed. The healthcheck should use a normal GET request instead of --spider.

2

Thanks for the precise report mate — you found a real bug, and the cause turned out to be one layer deeper than it looked.

It isn’t BusyBox wget. The error text Remote file does not exist -- broken link!!! is GNU wget’s wording. Our runtime image does apk add wget, and that GNU package shadows the BusyBox applet at /usr/bin/wget:

$ docker exec casadrop wget --version | head -1
GNU Wget 1.25.0 built on linux-musl

That matters because the two implementations behave differently: BusyBox’s --spider sends a GET, GNU’s --spider sends a HEAD. So the healthcheck was doing a HEAD request.

And the server answered HEAD with 404. The routes were registered as .Methods("GET"), and gorilla/mux does not imply HEAD from GET. A perfectly healthy instance therefore returned 404 to the probe — exactly the mismatch you observed between --spider and -qO-.

Reproduced inside the running container before the fix:

$ docker exec casadrop wget --no-verbose --tries=1 --spider http://localhost:8080/api/auth/status
Remote file does not exist -- broken link!!!   (exit 8)

Both halves are fixed on main:

  1. Every shipped healthcheck now does a plain GET against the purpose-built liveness endpoint — Dockerfile, docker-compose.yaml, docker-compose.zimaos.yaml and the docs examples:

    healthcheck:
  test: ["CMD-SHELL", "wget -qO- http://localhost:8080/healthz >/dev/null 2>&1 || exit 1"]

  2. /healthz, /readyz and /api/auth/status now match GET, HEAD, so HEAD-based probes — wget --spider, and some load balancers — work too. Covered by a regression test (TestHealthProbesAnswerHEAD).

Verified on a freshly built image: the container reports healthy with the new GET check, and the old --spider command now returns 200 OK / exit 0 as well.

One note on the released images: the HEALTHCHECK baked into the image already used wget -qO-, so containers started without an overriding compose healthcheck were never affected — a running 2.4.1 container reports healthy with FailingStreak: 0. If you took the healthcheck from docker-compose.yaml, you hit the bug; that file is what was wrong.

Thanks again — the report also led me to a second finding in the same entrypoint: grep -P (PCRE) isn’t supported by BusyBox grep either, so local-IP detection was printing a usage dump into the log on every start. That’s fixed as well.
Holger

1 Like