-
Bug
-
Resolution: Unresolved
-
Major
-
None
When trying to install a new AdoptOpenJDK version we run into the following exception
Caused by: java.io.IOException: Failed to unpack file:/var/lib/jenkins/caches/adoptopenjdk/LINUX/amd64/jdk8u292-b10.zip (103,891,868 bytes read) at io.jenkins.plugins.adoptopenjdk.AdoptOpenJDKInstaller.performInstallation(AdoptOpenJDKInstaller.java:132) at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:69) at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:109) at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:217) at hudson.model.JDK.forNode(JDK.java:148) at org.jenkinsci.plugins.pipeline.maven.WithMavenStepExecution2.setupJDK(WithMavenStepExecution2.java:290) at org.jenkinsci.plugins.pipeline.maven.WithMavenStepExecution2.doStart(WithMavenStepExecution2.java:194) at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77) ... 5 more Caused by: java.nio.file.AccessDeniedException: /var/lib/jenkins/tools/hudson.model.JDK/JDK8AdoptOpenJdk/THIRD_PARTY_README at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214) at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434) at java.nio.file.Files.newOutputStream(Files.java:216) at hudson.util.IOUtils.copy(IOUtils.java:42) at hudson.FilePath.unzip(FilePath.java:710) at hudson.FilePath.unzip(FilePath.java:682) at hudson.FilePath.access$200(FilePath.java:214) at hudson.FilePath$UnzipFrom.invoke(FilePath.java:671) at hudson.FilePath$UnzipFrom.invoke(FilePath.java:664) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3314) at hudson.remoting.UserRequest.perform(UserRequest.java:211) at hudson.remoting.UserRequest.perform(UserRequest.java:54) at hudson.remoting.Request$2.run(Request.java:376) at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78) ... 4 more Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to ci-slave-01 at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1800) at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356) at hudson.remoting.Channel.call(Channel.java:1001) at hudson.FilePath.act(FilePath.java:1158) at hudson.FilePath.act(FilePath.java:1147) at hudson.FilePath.unzipFrom(FilePath.java:662) at io.jenkins.plugins.adoptopenjdk.AdoptOpenJDKInstaller.performInstallation(AdoptOpenJDKInstaller.java:130) at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:69) at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:109) at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:217) at hudson.model.JDK.forNode(JDK.java:148) at org.jenkinsci.plugins.pipeline.maven.WithMavenStepExecution2.setupJDK(WithMavenStepExecution2.java:290) at org.jenkinsci.plugins.pipeline.maven.WithMavenStepExecution2.doStart(WithMavenStepExecution2.java:194) at org.jenkinsci.plugins.workflow.steps.GeneralNonBlockingStepExecution.lambda$run$0(GeneralNonBlockingStepExecution.java:77) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ... 4 more
Seems that for some reason the slave cannot retrieve the file from master.
[JENKINS-66457] java.io.IOException: Failed to unpack
Hello mmchr ,
the problem is around the zip file name (here: jdk8u292-b10.zip) and that zip file contents (here: JDK8AdoptOpenJdk/...).
Possible STR:
- define two different JDK installation in Jenkins' Global Tool Configuration, pointing to the same AdoptOpenJDK version
- e.g. JAVA 11 and JDK 11 for tool name
- e.g. jdk-11.0.11+9 for JDK version
- clear $JENKINS_HOME/caches/adoptopenjdk on controller
- create an agent with persisting /var/lib/jenkins/tools/hudson.model.JDK path
- create jobs for each tools, running on the newly created agent
- run the job which uses one of the configured JDK's, e.g. JDK 11
- see the plugin work as intended
- check the contents of the newly zipped AdoptOpenJDK version: unzip -l
- the original JDK content is packed in a tool related folder: JDK_11 for the JDK 11 tool
- run the other job which uses the other JDK tool: JAVA 11
- see the plugin fail
- clear again $JENKINS_HOME/caches/adoptopenjdk on controller
- run again the failing job
- see the plugin work as intended
- check the contents of the newly zipped AdoptOpenJDK version: unzip -l
- the original JDK content is packed in a tool related folder: JAVA_11 for the JAVA 11 tool
- which is different from JDK_11 seen previously
kwin, thanks for reporting!
I experienced the same issue with adoptopenjdk-plugin 1.5 after adding a second tool setup with a different name but with the same version from adoptium. One tool name was "AdoptiumJDK17" and i added another one called "JDK17".
To fix it I deleted the directory $JENKINS_HOME/caches/adoptopenjdk/LINUX/amd64/ on the jenkins machine and also the .../workspace/tools/hudson.model.JDK/ directory on the node.
Sven Jost
added a comment - - edited I experienced the same issue with adoptopenjdk-plugin 1.5 after adding a second tool setup with a different name but with the same version from adoptium. One tool name was "AdoptiumJDK17" and i added another one called "JDK17".
To fix it I deleted the directory $JENKINS_HOME/caches/adoptopenjdk/LINUX/amd64/ on the jenkins machine and also the .../workspace/tools/hudson.model.JDK/ directory on the node. 
Thank you for reporting this.
I've not been able to reproduce the result so perhaps you could supply some additional information?
Could this perhaps be a case of a disk that's out of storage and that the error message is not precise? Or SELinux or other security related systems?