Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building gradle itself fails during toolchain download: permission denied copying a file within .gradle/jdks #22796

Closed
smowton opened this issue Nov 18, 2022 · 4 comments · Fixed by #23024
Assignees
Labels
a:bug has:reproducer Indicates the issue has a confirmed reproducer in:toolchains Java Toolchains
Milestone

Comments

@smowton
Copy link

smowton commented Nov 18, 2022

Expected Behavior

Able to build Gradle

Current Behavior

Building Gradle fails as of roughly September 30th if a JDK11 toolchain needs to be downloaded, failing during unpacking the downloaded JDK with a permission error while copying .gradle/jdks/OpenJDK11U-jdk_x64_mac_hotspot_11/...some-read-only-file to .gradle/jdks/eclipse_adoptium-11-x86_64-os_x/...some-read-only-file

Build works as expected if the needed JDK is found through detection on your local system, or was in .gradle/jdks already, including because of a previous failure building this project.

Context

Steps to Reproduce

  1. git clone https://github.com/gradle/gradle; cd gradle; git checkout 4595851c30a4dc95a68c460e9b95259ca60b8060 (current master as of time of writing)
  2. Clear $HOME/.gradle/jdks to ensure the build will try to download a toolchain
  3. ./gradlew -Dorg.gradle.java.home=/some/jdk11/home/ -Porg.gradle.java.installations.auto-detect=false (using auto-detect=false to ensure a local JDK isn't picked up)

Result:

A problem occurred configuring root project 'gradle'.
> Could not determine the dependencies of null.
   > Could not resolve all dependencies for configuration ':classpath'.
      > Failed to calculate the value of task ':build-logic:lifecycle:compileJava' property 'javaCompiler'.
         > Unable to download toolchain matching the requirements ({languageVersion=11, vendor=ADOPTIUM, implementation=vendor-specific}) from 'https://api.adoptium.net/v3/binary/latest/11/ga/mac/x64/jdk/hotspot/normal/eclipse'.
            > Could not copy file '/Users/myusername/.gradle/jdks/OpenJDK11U-jdk_x64_mac_hotspot_11/jdk-11.0.17+8/Contents/Home/legal/java.management.rmi/LICENSE' to '/Users/myusername/.gradle/jdks/eclipse_adoptium-11-x86_64-os_x/jdk-11.0.17+8/Contents/Home/legal/java.management.rmi/LICENSE'.
               > /Users/myusername/.gradle/jdks/eclipse_adoptium-11-x86_64-os_x/jdk-11.0.17+8/Contents/Home/legal/java.management.rmi/LICENSE (Permission denied)

The specific file varies, and can be any file in the JDK tarball with a read-only mode, e.g. the LICENSE or README files, or various .md files in the legal subdirectory. The failure results because we're trying to truncate and overwrite a read-only file. Given the simplicity of provisionFromArchive (https://github.com/gradle/gradle/blob/master/subprojects/platform-jvm/src/main/java/org/gradle/jvm/toolchain/internal/install/JdkCacheDirectory.java#L120), I suspect this is a case of mistakenly calling that routine twice without cleaning up the install directory, so the first unpack goes as expected, then the second tries to overwrite the first and fails due to these read-only files.

I first noticed this because lgtm.com started failing to build gradle/gradle on September 30th; the times of its regular builds allow us to isolate the problem to this commit range: 764ed77...5eb9596

Your Environment

This is reproducible on many platforms: lgtm.com's workers as mentioned above are based on Ubuntu 20.04, but I can also reproduce the problem on MacOS Ventura with the same symptoms. Reproducibility can vary based on the JDKs available locally, but clearing .gradle/jdks and using -Porg.gradle.java.installations.auto-detect=false to insist on a downloaded toolchain seems to reliably reproduce the problem.

@joel-jeremy
Copy link

joel-jeremy commented Nov 25, 2022

I am encountering a similar issue in one of my projects. Although my project workflow is using JDK 19 instead of JDK 11.

See Build with Gradle error here: https://github.com/joel-jeremy/externalized-properties/actions/runs/3545156602/jobs/5953063148

@shakuzen
Copy link

If another data point helps, we're seeing what I think is the same issue in the Micrometer build (see, for example, https://ge.micrometer.io/s/vxhaweu5wfjhm) which we're tracking with micrometer-metrics/micrometer#3549.

@jbartok jbartok removed the to-triage label Nov 29, 2022
@ljacomet ljacomet added this to the 7.6.1 milestone Dec 1, 2022
@markslater
Copy link

markslater commented Dec 5, 2022

I also see this on my own project with Adoptium 16.0.2+7 and 17.0.5+8 on Linux.

Gradle 7.6 successfully downloads the JDK, but encounters a permission denied at some point while unpacking it. If I manually delete the partly unpacked directory and then unpack the JDK myself with tar -xvf, everything subsequently works fine, so it seems that the tar is valid (at least in the tar command's opinion), but Gradle's untar chokes on it.

@jbartok
Copy link
Member

jbartok commented Dec 6, 2022

Thank you all for the information and reproducers. We now understand what is causing the problems and are working on a fix.

@jbartok jbartok modified the milestones: 7.6.1, 8.0 RC1 Dec 6, 2022
TheMrMilchmann added a commit to Osmerion/Quitte that referenced this issue Dec 13, 2022
Gradle 7.6 causes the CI to fail because of gradle/gradle#22796.

This reverts commit 4d00b4e.
TheMrMilchmann added a commit to Osmerion/Quitte that referenced this issue Jan 28, 2023
This should effectively get rid of gradle/gradle#22796 for now
fbarthelery added a commit to fbarthelery/geekttrss that referenced this issue Jan 30, 2023
gradle/gradle#22796 happens on CI.
Maybe this will fix it
mloitm added a commit to nordic-institute/X-Road that referenced this issue Oct 31, 2023
Previous version had issues with java toolchain download.
gradle/gradle#22796
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:bug has:reproducer Indicates the issue has a confirmed reproducer in:toolchains Java Toolchains
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants