Consistent TLS Timeout in build stage that uses golang:latest, only when cross-compiling to ARMv7

[proofrock]

Hi,
I am using buildx to cross-build a project of mine. The dockerfile is multistage, and uses the golang:latest image to build the application on an AMD64 box. Now, for targets AMD64 and ARM64 everything goes well, but for ARMv7 the build hangs and fails with many TLS Handshake Timeouts about halfway through downloading the dependencies.

I am pasting the error messages at the end of this report. Some notes:

• A similar first stage, that uses alpine:edge and imports golang via package manager, succeeds;
  • I would want to avoid Alpine/musl, though;
• I tried on WSL2 in my dev PC, on a "real" linux box, and on a F16s Azure machine with accelerated networking. It doesn't seem related to network speed nor to CPU power, it fails consistently;
• On the azure machine (16 cores) the CPU load was ~3.9 during compilation, before failing;
• The Makefile step that fails is CGO_ENABLED=0 go build -o ws4sqlite -trimpath
• I tried adding a go get download -x before the go build and it also fails.

Steps to reproduce

On an amd64 linux system:

git clone https://github.com/proofrock/ws4sqlite
cd ws4sqlite
sudo docker run --privileged --rm docker/binfmt:a7996909642ee92942dcd6cff44b9b95f08dad64
sudo docker buildx build --no-cache --platform linux/arm/v7 -t ws4sqlite:test-arm .

It seems the same issue as this one. I am filing it here because this project is the one suggested by the dockerhub page.

Please tell me if I missed something, or how I can be of further assistance. I hope this is solvable.

-- G.

#0 141.1 web_service.go:26:2: github.com/gofiber/fiber/v2@v2.44.0: Get "https://proxy.golang.org/github.com/gofiber/fiber/v2/@v/v2.44.0.zip": net/http: TLS handshake timeout
#0 141.1 ws4sqlite.go:24:2: github.com/gofiber/fiber/v2@v2.44.0: Get "https://proxy.golang.org/github.com/gofiber/fiber/v2/@v/v2.44.0.zip": net/http: TLS handshake timeout
#0 141.1 ws4sqlite.go:25:2: github.com/gofiber/fiber/v2@v2.44.0: Get "https://proxy.golang.org/github.com/gofiber/fiber/v2/@v/v2.44.0.zip": net/http: TLS handshake timeout
#0 141.1 ws4sqlite.go:34:2: github.com/gofiber/fiber/v2@v2.44.0: Get "https://proxy.golang.org/github.com/gofiber/fiber/v2/@v/v2.44.0.zip": net/http: TLS handshake timeout
#0 141.1 sched_tasks.go:32:2: github.com/lnquy/cron@v1.1.1: Get "https://proxy.golang.org/github.com/lnquy/cron/@v/v1.1.1.zip": net/http: TLS handshake timeout
#0 141.1 cli.go:25:2: github.com/mitchellh/go-homedir@v1.1.0: Get "https://proxy.golang.org/github.com/mitchellh/go-homedir/@v/v1.1.0.zip": net/http: TLS handshake timeout
#0 141.1 web_service.go:27:2: github.com/proofrock/crypgo@v1.2.1: Get "https://proxy.golang.org/github.com/proofrock/crypgo/@v/v1.2.1.zip": net/http: TLS handshake timeout
#0 141.1 authentication.go:29:2: github.com/proofrock/go-mylittlelogger@v0.4.0: Get "https://proxy.golang.org/github.com/proofrock/go-mylittlelogger/@v/v0.4.0.zip": net/http: TLS handshake timeout
#0 141.1 sched_tasks.go:33:2: github.com/robfig/cron/v3@v3.0.1: Get "https://proxy.golang.org/github.com/robfig/cron/v3/@v/v3.0.1.zip": net/http: TLS handshake timeout
#0 141.1 ws4sqlite.go:28:2: github.com/wI2L/jettison@v0.7.4: Get "https://proxy.golang.org/github.com/w%21i2%21l/jettison/@v/v0.7.4.zip": net/http: TLS handshake timeout
#0 141.1 cli.go:27:2: gopkg.in/yaml.v2@v2.4.0: Get "https://proxy.golang.org/gopkg.in/yaml.v2/@v/v2.4.0.zip": net/http: TLS handshake timeout
#0 141.1 ws4sqlite.go:35:2: modernc.org/sqlite@v1.21.2: Get "https://proxy.golang.org/modernc.org/sqlite/@v/v1.21.2.zip": net/http: TLS handshake timeout
#0 141.1 make: *** [Makefile:22: build-nostatic] Error 1

[proofrock]

A thing: I am in South Korea now, and I did all the tests from here, also the Azure VM was created here (Korea Central). I tried with a VM created in US Central, and it works.

So it seems a combined qemu/arm+distance thing? Is there a way to set the TLS Handshake Timeout somehow and/or to use a sort of CDN? It's still quite strange, the network speed on Azure is still very performant, it shouldn't timeout even from Korea IMHO.

[tianon]

Unfortunately, we do not have the bandwidth to provide in-depth integration/deployment/environment debugging or support here; these sorts of questions/requests would be more appropriately posted to a dedicated support forum, such as the Docker Community Slack, Server Fault, Unix & Linux, or Stack Overflow.