Failure when testing the version 4.0.0 of sonarqube-scan-action on GitHub self-hosted runners
Using SonarQube Enterprise Edition v10.6
NoSuchFileException: /home/runner/.sonar/cache/bcb1b7b8ad68c93093f09b591b7cb17161d39891f7d29d33a586f5a328603707/jre6284578682694846135/jdk-17.0.11+9-jre/lib/server/classes.jsa
16:59:06.658 INFO SonarScanner CLI 6.2.1.4610
16:59:06.663 INFO Java 17.0.12 Eclipse Adoptium (64-bit)
16:59:06.664 INFO Linux 5.15.0-1068-azure amd64
16:59:06.792 INFO User cache: /home/runner/.sonar/cache
16:59:08.887 INFO JRE provisioning: os[linux], arch[x86_64]
16:59:12.623 INFO EXECUTION FAILURE
16:59:12.631 INFO Total time: 6.042s
16:59:12.631 ERROR Error during SonarScanner CLI execution
java.lang.IllegalStateException: Failed to extract archive
at org.sonarsource.scanner.lib.internal.JavaRunnerFactory.extractArchive(JavaRunnerFactory.java:200)
at org.sonarsource.scanner.lib.internal.JavaRunnerFactory.getJreFromServer(JavaRunnerFactory.java:145)
at org.sonarsource.scanner.lib.internal.JavaRunnerFactory.createRunner(JavaRunnerFactory.java:85)
at org.sonarsource.scanner.lib.internal.ScannerEngineLauncherFactory.createLauncher(ScannerEngineLauncherFactory.java:53)
at org.sonarsource.scanner.lib.ScannerEngineBootstrapper.bootstrap(ScannerEngineBootstrapper.java:123)
at org.sonarsource.scanner.cli.Main.analyze(Main.java:75)
at org.sonarsource.scanner.cli.Main.main(Main.java:63)
Caused by: java.nio.file.NoSuchFileException: /home/runner/.sonar/cache/bcb1b7b8ad68c93093f09b591b7cb17161d39891f7d29d33a586f5a328603707/jre6284578682694846135/jdk-17.0.11+9-jre/lib/server/classes.jsa
at java.base/sun.nio.fs.UnixException.translateToIOException(Unknown Source)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(Unknown Source)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(Unknown Source)
at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(Unknown Source)
at java.base/java.nio.file.spi.FileSystemProvider.newOutputStream(Unknown Source)
at java.base/java.nio.file.Files.newOutputStream(Unknown Source)
at java.base/java.nio.file.Files.copy(Unknown Source)
at org.sonarsource.scanner.lib.internal.util.CompressionUtils.extractTarGz(CompressionUtils.java:146)
at org.sonarsource.scanner.lib.internal.JavaRunnerFactory.extract(JavaRunnerFactory.java:234)
at org.sonarsource.scanner.lib.internal.JavaRunnerFactory.extractArchive(JavaRunnerFactory.java:193)
... 6 common frames omitted
Hi, this looks to be the same issue as reported here and here
The problem is we are not able to reproduce and understand the issue.
@philithethrill99 Is there anything special with your self-hosted runner? Do you have an anti-virus or any anti-malware software that would wrongly detect jdk-17.0.11+9-jre/lib/server/classes.jsa and quarantine it? From experience, most issues happening when unzipping archives are caused by third-party security tools.
I created a ticket to track the investigation’s progress, but any information or reproducer is welcome since I have no idea of the root cause for now.
@philithethrill99 any chance you could connect to your self-hosted runner, and verify the checksum of the downloaded JRE:
$ sha256sum /home/runner/.sonar/cache/bcb1b7b8ad68c93093f09b591b7cb17161d39891f7d29d33a586f5a328603707/OpenJDK17U-jre_x64_linux_hotspot_17.0.11_9.tar.gz
bcb1b7b8ad68c93093f09b591b7cb17161d39891f7d29d33a586f5a328603707 /home/julien.henry/.sonar/cache/bcb1b7b8ad68c93093f09b591b7cb17161d39891f7d29d33a586f5a328603707/OpenJDK17U-jre_x64_linux_hotspot_17.0.11_9.tar.gz
We are using Dynatrace OneAgent on our self-hosted runners, I’m suspecting this causing the issue.
$ ls -l
total 34096
-rw-r--r-- 1 runner runner 0 Nov 27 14:35 classes.jsa
-r--r--r-- 1 runner runner 10899456 Nov 27 14:35 classes_nocoops.jsa
-rw-r--r-- 1 runner runner 16560 Nov 27 14:35 libjsig.so
-rw-r--r-- 1 runner runner 23992808 Nov 27 14:35 libjvm.so
$ cat classes.jsa
$ pwd
/home/runner/.sonar/cache/bcb1b7b8ad68c93093f09b591b7cb17161d39891f7d29d33a586f5a328603707/jre11373730550266553454/jdk-17.0.11+9-jre/lib/server
$ cd /home/runner/.sonar/cache/bcb1b7b8ad68c93093f09b591b7cb17161d39891f7d29d33a586f5a328603707
$ ls -l
total 45304
-rw-r--r-- 1 runner runner 46382823 Nov 27 14:35 OpenJDK17U-jre_x64_linux_hotspot_17.0.11_9.tar.gz
drwx------ 3 runner runner 4096 Nov 27 14:35 jre11373730550266553454
$ sha256sum OpenJDK17U-jre_x64_linux_hotspot_17.0.11_9.tar.gz
bcb1b7b8ad68c93093f09b591b7cb17161d39891f7d29d33a586f5a328603707 OpenJDK17U-jre_x64_linux_hotspot_17.0.11_9.tar.gz
I extracted the tar.gz file that was downloaded from the action and the classes.jsa file is NOT 0k
-rw-r--r-- 1 runner runner 46382823 Nov 27 18:38 OpenJDK17U-jre_x64_linux_hotspot_17.0.11_9.tar.gz
drwxr-xr-x 6 runner runner 4096 Apr 17 2024 jdk-17.0.11+9-jre
$ cd jdk-17.0.11+9-jre/lib/server
$ ls -l
total 45784
-r--r--r-- 1 runner runner 11968512 Apr 17 2024 classes.jsa
-r--r--r-- 1 runner runner 10899456 Apr 17 2024 classes_nocoops.jsa
-rw-r--r-- 1 runner runner 16560 Apr 17 2024 libjsig.so
-rw-r--r-- 1 runner runner 23992808 Apr 17 2024 libjvm.so
Indeed, it seems to be a common issue with Dynatrace (for example reported here). They mention the following workaround:
If the Dynatrace OneAgent is not required on the PAM client host, uninstall it.
If it is required, turning off ProcessAgent injection should resolve the problem:
If you need the Dynatrace OneAgent and cannot turn off ProcessAgent injection, or turning it off does not resolve the problem for you, contact Dyntrace OneAgent Support to find a solution that works for you.
Would you be able to ask Dyntrace OneAgent Support? If there is anything we can change in our software to make things work out of the box, we would be happy to consider it, but for now, I assume this is a false positive created by this security tool.
