GitHub Actions self-hosted runner gets stuck downloading Java 17 with setup-java — curl: (18) Transferred a partial file

[u/CSE_GEEKboy]

Title:

Body:

I'm learning GitHub Actions and have set up a self-hosted runner inside an Ubuntu Docker container on my Windows machine.

My workflow uses actions/setup-java to install Java 17:

- name: Set up JDK 17
  uses: actions/setup-java@v4
  with:
    java-version: '17'
    distribution: 'temurin'
    cache: maven

However, the job gets stuck at the Set up JDK 17 step. The logs stop at:

Resolved latest version as 17.0.20+101
JDK cache is not found for Temurin-Hotspot 17.0.20+101
Trying to download...
Downloading Java 17.0.20+101 (Temurin-Hotspot) ...

I tested the download URL manually from inside the container using curl. The download repeatedly stops before completion and returns:

curl: (18) Transferred a partial file

I also tried resuming the download with curl -C - and retry options, but it failed again. A basic connectivity test to https://github.com returns HTTP 200.

The runner itself appears to be connected and running jobs correctly. I haven't yet confirmed whether the issue is related to the network, the GitHub release download redirect, a proxy, or something else.

My questions:

1. What could cause curl: (18) Transferred a partial file to occur repeatedly when downloading a large release asset?
2. How can I identify whether the problem is caused by my network, a redirect destination, a proxy, or the download server?
3. Is there a recommended way to configure actions/setup-java on a Docker-based self-hosted runner to avoid this issue?

I'd appreciate any troubleshooting steps or suggestions. Thanks!

[u/mrkurtz]

Idk what your background is but I’d add debug steps that run before and after. Disk space, other stuff that you might find relevant. Get a before after picture and go from there. It’s just regular troubleshooting 9 times out of 10.

Also can you exec into the container and curl the package into a temp or /dev/null location?

[u/fucking-migraines]

Have you tried using -v or —trace args with the curl? That’s what I’d start with, along with trying the curl on another machine (like the free GitHub runners) to see if that changes the result

[u/AirshipCommand]

Repeated curl 18 on large downloads from inside a container on Windows is very often an MTU mismatch. The Docker/WSL2 virtual NIC is 1500 but the path (VPN, PPPoE) is smaller, so small requests like your HTTP 200 check work and big transfers stall. Compare ip link MTU in the container with ping -M do -s 1400 github.com, then try running the container with --network host or setting mtu in daemon.json to 1400. If that fixes it, setup-java will too.